Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VP2430|Bios Lock causes insta-restart and further tries cause kernel panic when trying to boot into ubuntu #1160

Open
wiktormowinski opened this issue Dec 9, 2024 · 5 comments

Comments

@wiktormowinski
Copy link

Component

Dasharo firmware

Device

Protectli VP2430

Dasharo version

v0.9.0rc-1

Dasharo Tools Suite version

Test case ID

BLS001.001, BLS002.001

Brief summary

when the Bios Lock is turned on it prevents Ubuntu from booting

How reproducible

happens every time to me, though the test sample is too little to claim it is 100%

How to reproduce

  1. enter UEFI setup menu -> Dasharo System Features -> Dasharo Security Options and turn Lock the BIOS boot medium ON, then save and restart.
  2. In boot menu select ubuntu

Expected behavior

ubuntu should boot as usual

Actual behavior

  1. first instance (of turning bios lock on) causes the platform to reboot whenever trying to boot ubuntu
  2. turning Lock the BIOS boot medium back off, and booting ubuntu causes no problem
  3. second instance generates kernel panic error
  4. fortunately turning Lock the BIOS boot medium back off, and booting ubuntu is an easy fix to get rid of kernel panic
error: image not loaded.

error: image not loaded.

error: you need to load the kernel first.

error: you need to load the kernel first.

Press any key to continue...Press any key to continue...

�[    2.067944] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

[    2.076249] fbcon: Taking over console

[    2.080049] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.8.0-49-generic #49-Ubuntu

[    2.087572] Hardware name: Protectli VP2430/VP2430, BIOS Dasharo (coreboot+UEFI) v0.9.0-rc1 11/13/2024

[    2.096895] Call Trace:

[    2.099386]  <TASK>

[    2.101516]  dump_stack_lvl+0x27/0xa0

[    2.105230]  dump_stack+0x10/0x20

[    2.108578]  panic+0x366/0x3c0

[    2.111691]  mount_root_generic+0x1a5/0x360

[    2.115923]  mount_root+0x98/0x100

[    2.119359]  ? __pfx_kernel_init+0x10/0x10

[    2.123501]  prepare_namespace+0x6c/0x2f0

[    2.127548]  kernel_init_freeable+0x1c6/0x210

[    2.131936]  kernel_init+0x1b/0x200

[    2.135458]  ret_from_fork+0x44/0x70

[    2.139083]  ? __pfx_kernel_init+0x10/0x10

[    2.143211]  ret_from_fork_asm+0x1b/0x30

[    2.147183]  </TASK>

[    2.149431] Kernel Offset: 0x12000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)

[    2.160246] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

log above shows kernel panic in action.

Screenshots

No response

Additional context

No response

Solutions you've tried

No response

@miczyg1
Copy link
Contributor

miczyg1 commented Dec 12, 2024

Couldn't reproduce it.

@miczyg1
Copy link
Contributor

miczyg1 commented Dec 12, 2024

Or actually I could... But only on the lab unit. And it happens in the random moments (didn't get Unable to mount root fs panic even once).

@miczyg1
Copy link
Contributor

miczyg1 commented Dec 17, 2024

Maybe it is related to the lab or the fact that the Ubuntu is installed on eMMC.

I would try:

  1. Check if the platform behaves the same when outside of the rack.
  2. Try installing Ubuntu on SSD disk and check if the issue persists. Maybe it is some eMMC issue.

@SebastianCzapla
Copy link
Contributor

SebastianCzapla commented Dec 18, 2024

Still present on on rc2, but here it also seems to crash with bios lock disabled.
Flashed rc1, and I could log into the machine, on rc2 variety of crashes occurred, logs in the attachment.

rc2-panic-log.zip

@miczyg1
Copy link
Contributor

miczyg1 commented Dec 18, 2024

In the first panic it seems to occur in SHMEM. SHMEM according to Linux Kconfig:

	  The shmem is an internal filesystem used to manage shared memory.
	  It is backed by swap and manages resource limits. It is also exported
	  to userspace as tmpfs if TMPFS is enabled. Disabling this
	  option replaces shmem and tmpfs with the much simpler ramfs code,
	  which may be appropriate on small systems without swap.

Seconds panic is a page fault (non existing page) in during __kmalloc_node.
Third is a page fault in mas_spanning_rebalance.isra (maple tree).

It looks really random. I strongly recommend to do things I mentioned here: #1160 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants