rust-osdev / bootloader

An experimental pure-Rust x86 bootloader
Apache License 2.0
1.39k stars 212 forks source link

Triple fault on Dell Inspiron 15 5330 #406

Closed debater-coder closed 10 months ago

debater-coder commented 11 months ago

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

debater-coder commented 11 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 😕?

phil-opp commented 10 months ago

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.

debater-coder commented 10 months ago

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!

debater-coder commented 10 months ago

Added a loop {} on this line, and it still triple faults. In QEMU it hangs after "UEFI bootloader started" as expected.

phil-opp commented 10 months ago

Added a loop {} on this line, and it still triple faults. In QEMU it hangs after "UEFI bootloader started" as expected.

Thanks, this is quite useful already! Could you check whether the load_kernel call here is successful (try with a loop {} before and then a loop {} after)?

debater-coder commented 10 months ago

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.

bjorn3 commented 10 months ago

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.)

debater-coder commented 10 months ago

It hangs successfully with no triple faults now, I'll try with a loop {} after load_kernel next.

debater-coder commented 10 months ago

loop {} after does work, so load_kernel is successful.

debater-coder commented 10 months ago

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.

debater-coder commented 10 months ago

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!