Closed debater-coder closed 10 months ago
I've tested using both Rufus on Windows and dd
on Ubuntu to try to format the USB drive with the image to no avail (still get a SupportAssist screen show up presumably due to triple fault). I've tried flashing an Ubuntu live-CD image to the USB and successfully booted it, so I assume this means that the drive is not corrupted. My scans of the drives also seem to suggest the same.
If you have a sample repository that uses bootloader I could try building and imaging that, and if that works then I can compare to my repo to see what I did wrong.
Otherwise maybe there is a bug somewhere in the uefi
or bootloader
crates that makes it incompatible with my hardware. Or it could be a hardware bug 😕?
Thanks for reporting! I don't see any issues with your code, so I suspect that it's a bug in our bootloader. To be sure, could you try to add a loop {}
at the beginning of your kernel_main
? If it still triple-faults, the issue is likely on the bootloader side.
In that case, it would be great if you could help us with debugging, as the issue seems specific to your system. A simple way to pinpoint the problem could be to clone the bootloader
repo and use it with your kernel through a path dependency. Then you can insert loop {}
statements in the bootloader source at different stages of the boot process and try it again on your hardware. If it hangs, the error happens later in the boot process; if it triple-faults, the error happens earlier. I'm happy to help with the details if you're willing to do this debugging.
I tested with a loop {}
at the start of kernel_main
and it still enters a triple fault. Like before, I see a boot entry like 'UEFI USB...' but whenever I try and boot into it, it goes into Dell SupportAssist thing almost immediately. I assume this is because it is triple faulting.
If you could give me some guidance on debugging this, I would appreciate it greatly. Thanks!
Added a loop {}
on this line, and it still triple faults. In QEMU it hangs after "UEFI bootloader started" as expected.
I tried with a loop {}
before the load_kernel
call and I got a message saying:
Operating System Loader has no signature. Incompatible with SecureBoot. All bootable devices failed Secure Boot verification.
I can continue to boot Windows, and this message never showed on any of the previous boots of the kernel. I tried again and got the same message. If you think it would help, I could try disabling secure boot and try again.
You will definitively need to disable secure boot. Stopping you from booting any kernels not trusted by Microsoft (including the kernel you compiled) is the purpose of secure boot. (Technically you can replace the microsoft signing key with your own, but few people do.)
It hangs successfully with no triple faults now, I'll try with a loop {}
after load_kernel
next.
loop {}
after does work, so load_kernel
is successful.
After disabling secure boot, I realised that the triple fault could be because of it. That would be strange, because I recall it faulting even with triple fault disabled. One thing that I did differently is I used Windows' Advanced Startup Options to boot from the media instead of using the UEFI menu. I'll do a final test with the path dependency removed completely, and if that works I'll close the issue.
I've tested it without the path dependency and it works. What changed was that I used the Windows Startup Menu and disabled Secure Boot. Thank you for the help!
When I try to boot using with this bootloader on my Dell Inspiron 15 5330, I always get a triple fault. It only supports UEFI and this persists even when Secure Boot is disabled (not that I think it applies since
bootloader
doesn't look like it modifies any UEFI drivers). I have followed this information to set this up and it works fine in QEMU with OVMF.For reference here is my repo: https://github.com/debater-coder/bench2