You are not logged in.
I just installed arch on a laptop (Dell precision M4800) previously running Ubuntu. So far everything works but the efi firmware doesn't seem to start grub properly. When starting up the laptop the screen flickers once and then goes on to the bootloader of the remaining windows install.
However, when I am using the live cd and run the uefi shell I can execute the grubx64.efi and am greeted with a perfectly fine grub menu and can boot my system properly. Didn't have this problem with the previous ubuntu install. Sadly, I removed the grub install of Ubuntu and now can't analyse the differences or reconfigure the old grub to load arch.
I followed the steps and suggestions described in the arch wiki regarding grub and uefi. Since the system has secure boot enabled I added grubs efi file hash with the hash tool to be trusted. I did not try the grub standalone install as grub seems grub itself works fine but seems to not be called properly.
I also tried this proposed fix but the behavoir still remains the same.
I don't even know how to troubleshoot the problem effectively as the problem seems to be caused by the firmware.
relevant output of efibootmgr -v
BootOrder: 0006,0003,0004,0000,0001,0002,0005,000A
...
Boot0006* Arch HD(1,GPT,494b1c9f-9dc6-4054-80e6-662b82b9545c,0x800,0x96000)/File(\bootx64.efi)
(it's on the filesystems root following the proposed fix mentioned above)
Any help is greatly appreciated.
Last edited by Habbedah (2015-10-07 06:44:37)
Offline
Does your GRUB menu show if you rename the folder at $ESP/EFI/Microsoft?
See https://bbs.archlinux.org/viewtopic.php … 2#p1514912
You could also try systemd-boot instead of GRUB:
https://wiki.archlinux.org/index.php/Systemd-boot
Jin, Jîyan, Azadî
Offline
You put me on the right direction and I found the solution.
Renaming the MS bootloader rendered my system unbootable and showed me 2x an error message above the text that my system is unbootable and what keys to press to do what.
Both error messages (before installing systemd-boot it was only one) stated
Operation system loader failed signature verification. Warning! The file may have been tempered with.
So, I guessed it's an issue with secure boot not trusting my boot loaders. I was under the impression that adding the hashes with HashTool.efi would do the trick (at least afterwards I wouldn't get 'permission denied' when trying to boot through the efi shell) but apparently it does only for the efi shell.
At least now I knew where to look for additional information. While at first I only scanned over the part for Secure Boot on the UEFI wiki page I now looked further into the Rodsbooks' Secure Boot, especially the part about the preloader.
I only had to drop the signed preloader as bootx64.efi (the one used in the iso is the same as the one from the Linux Foundation) into the $efi/EFI/Boot folder, add the HashTool and my grubx64.efi as loader.efi and everything worked fine.
I gotta say, I kinda feel bad as this was pretty much caused by my wrong assumptions about how secure boot actually works. The fix was rather easy and I should have come to the conclusion that secure boot is the issue earlier. However, I did learn a fair share about efi and secure boot and fixed my own mistake. And that always that feels great.
Thanks for the help which pointed me into the right direction. Maybe someone else might learn from my mistakes. It might be a good Idea to add these small steps to the wiki, even though they can be found in the referenced 'Rodsbooks' Secure Boot' source.
Last edited by Habbedah (2015-10-06 19:15:05)
Offline