-
Notifications
You must be signed in to change notification settings - Fork 99
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
ASSERT error when running linuxboot.rom in QEMU #46
Comments
@synackd I am also experiencing this issue with the same lineup you are using. I've tried running qemu-linuxboot make run rule from the Heads cloned repo, and also by building the linuxboot cloned repo and pointing it to use the bzImage and initrd images from my Heads build. Both result in the same assert you referenced, where it just hangs:
Have you been able to get past this? |
The way I'm working around this now is to use an older commit that requires a patched kernel. Currently, I'm using f0ea0af. |
Thanks for the pointer @synackd. I am using the kernel + initrd built out of HEADS, did you have to further patch the 4.14.62 kernel in HEADS to make it work with this older Linuxboot commit? I got past the ASSERT error, the kernel starts booting but I ran into a panic (Unable to mount root fs on unknown-block(0,0)). I have to dig deeper I suspect a qemu issue on my end. |
The patch is essentially for allowing the kernel to act as a UEFI bootloader so that doesn't seem to be the issue for you here. Check your kernel config and make sure the path to your initramfs is correct. |
Did a little more testing commit-by-commit and the problem starts at 03a592c: commit 03a592cf14bb41abc91158993b42c32184ff99a7
Author: Trammell Hudson <hudson@trmm.net>
Date: Thu Aug 9 10:21:13 2018 -0400
Linux should be an application, not a DXE driver, with the BDS patch
diff --git a/Makefile.uefi b/Makefile.uefi
index 4df5e0f..337b2df 100644
--- a/Makefile.uefi
+++ b/Makefile.uefi
@@ -22,7 +22,7 @@ IntelCrystalRidgeGuid := 626967C7-071B-4D9A-9D0C-F112CF0836E9
LpcSomethingGuid := 64021DFE-A62C-42A7-BF46-15078CDF9F89
Linux-guid := DECAFBAD-6548-6461-732d-2f2d4e455246
-Linux-depex := $(RuntimeArchProtocolGuid)
+Linux-type := APPLICATION
Initrd-type := FREEFORM
Initrd-guid := 74696e69-6472-632e-7069-6f2f62696f73 though the actual issue might be somewhere in |
Good sleuthing work. I'm still getting that kernel panic regarding it being unable to mount root fs on unknown-block(0,0). I have checked the kernel config to make sure it's pointing to the correct initramfs blob:
And yet I still get the kernel panic:
I've even tried booting the bzImage + initrd straight in QEMU without involving Linuxboot and I get the same issue. I thought if a kernel has been built to include an initramfs it mounts that instead and ignores any 'root=' kernel parameter. |
You have |
Yes I questioned that as well, but I never explicitly set CONFIG_INITRAMFS_COMPRESSION=".xz" myself in linux-linuxboot.config. I'm not sure how it is inheriting that option. I will try recompiling with it turned off. |
That config option is in Linux itself. Go to the Linux source dir, Seeing as your mount issue is unrelated to this ASSERT issue, I would suggest asking on the OSFW Slack in the #linuxboot channel if you have further questions on it. |
This no longer occurs since #51 was merged. |
Transfering control to BDS 7B44408
|
When running
linuxboot.rom
in QEMU using Linux 4.14.62 (also tried with 5.10.3 and 5.4.69), the following error occurs despite a successful build, no matter the kernel config or initramfs contents:<workpath>
is the absolute path to where Linuxboot is cloned.It occurs when running
make BOARD=qemu-linuxboot
in HEADS, and even when using amake tinyconfig
kernel so the kernel config and initramfs don't seem to be the issue.It looks like the assertion is made during the call to
gBS->ConnectController()
inefi_connect_controllers()
on line 170 ofdxe/linuxboot.c
The text was updated successfully, but these errors were encountered: