I had Windows 10 and Fedora dual booting nicely on a i5 laptop but then the HD died.
I replaced it with a 1TB SSD (Yay!) and restored windows first per the recommended method. I then booting Fedora 29 Live and performed an install and all seemed to go well except it won't boot to fedora!
When I try to get to a boot menu I only see Windows Bootloader and Fedora (the latter doesn't work). When I boot to Fedora Live I see multiple entries with efibootmgr including two Fedora entries.
I assume one is for the old system and one for the new.
When I try to go into advanced settings in Win10 to change UEFI settings it reboots me but there is a password on the BIOS. I can't remember if I set a password of maybe the kids did somehow but I have tried every password I have ever used and it won't let me in.
Anyone got any ideas?
Thanks, Richard
On Tue, 23 Apr 2019 at 15:54, Richard Shaw hobbes1069@gmail.com wrote:
I had Windows 10 and Fedora dual booting nicely on a i5 laptop but then the HD died.
I replaced it with a 1TB SSD (Yay!) and restored windows first per the recommended method. I then booting Fedora 29 Live and performed an install and all seemed to go well except it won't boot to fedora!
When I try to get to a boot menu I only see Windows Bootloader and Fedora (the latter doesn't work). When I boot to Fedora Live I see multiple entries with efibootmgr including two Fedora entries.
I assume one is for the old system and one for the new.
When I try to go into advanced settings in Win10 to change UEFI settings it reboots me but there is a password on the BIOS. I can't remember if I set a password of maybe the kids did somehow but I have tried every password I have ever used and it won't let me in.
Anyone got any ideas?
This is vendor-specific. https://www.wikihow.com/Reset-a-BIOS-Password has some examples, but it is probably best to go directly to the vendor's support site.
While I had to run it through the shredder I finally sat down and went through all the passwords I've ever used and figured it out :)
I turned off Secure Boot but it still won't boot Fedora.
I finally figured out I had to use -v to get what I wanted from efibootmgr:
BootCurrent: 0001 Timeout: 0 seconds BootOrder: 000E,0001,0003,2001,2002,2003 Boot0000* Fedora HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shimx64.efi) Boot0001* Linpus lite HD(1,MBR,0x7c3f77cf,0x1c7e4,0x4df8)/File(\EFI\Boot\grubx64.efi)RC Boot0002* Unknown Device: HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC Boot0003* Fedora PciRoot(0x0)/Pci(0x17,0x0)/Sata(0,0,0)/HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\grubx64.efi)A01 .. Boot0004* Unknown Device: HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC Boot000E* Windows Boot Manager HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}................... Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC
I'm thinking the 0000 is the old Fedora installation from the bad HD and 0003 is the new entry but I've never seen "PciRoot" before. And still none of this is intuitive, there's like 6-10 efi files and I don't know which one I should use of it it even matters...
Or maybe it's the opposite. I'm at work so I can't check but I believe b2fa98e2-c3c8-4798-8faa-1e424d313bb1 is the PARTUUID of the new drive, and there's other entries with the same UUID with RC at the end which I assume are "detected" entries.
Thanks, Richard
On Wed, Apr 24, 2019 at 8:02 AM Richard Shaw hobbes1069@gmail.com wrote:
While I had to run it through the shredder I finally sat down and went through all the passwords I've ever used and figured it out :)
I turned off Secure Boot but it still won't boot Fedora.
I finally figured out I had to use -v to get what I wanted from efibootmgr:
BootCurrent: 0001 Timeout: 0 seconds BootOrder: 000E,0001,0003,2001,2002,2003
Offhand, this looks like the problem. 000E points to Windows. You need to use `efibootmgr --bootorder 0,E,1` so it boots Fedora first. It's not strictly necessary to list everything in bootorder, you can just have one. The idea of populating it fully is to have exactly the predictable fallback boot behavior the user wants, whatever that is. e.g. if something with the Fedora bootloader gets nerfed then it'd boot Windows.
Boot0000* Fedora HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shimx64.efi)
Offhand, looks valid but I can't vouch for either the partition number or its GUID.
Boot0001* Linpus lite HD(1,MBR,0x7c3f77cf,0x1c7e4,0x4df8)/File(\EFI\Boot\grubx64.efi)RC Boot0002* Unknown Device: HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC Boot0003* Fedora PciRoot(0x0)/Pci(0x17,0x0)/Sata(0,0,0)/HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\grubx64.efi)A01 .. Boot0004* Unknown Device: HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC
I would use efibootmgr to delete these, they look either suboptimal (unknown device) or use old paths to grub rather than shim.
If you're not sure you can delete them all, and then do:
# grep efibootmgr /var/log/anaconda/program.log
And you'll see the longest command there is what's used to add the menu entry. You can just use the same command, although you'll need to escape the backslashes with backslashes, so the path becomes \efi\fedora\shimx64.efi
Also, firmware password and UEFI Secure Boot are two different things. Secure Boot I don't recommend disabling, it's a feature that cryptographically verifies the bootloaders, the kernel and kernel modules. If you're building out of tree kernel modules, then it's understandable to run without Secure Boot but I would still go through the effort to create your own signing cert, register it in the firmware, and then use it to sign your modules so that you can enable secure boot.
On Wed, Apr 24, 2019 at 5:35 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Apr 24, 2019 at 8:02 AM Richard Shaw hobbes1069@gmail.com wrote:
While I had to run it through the shredder I finally sat down and went
through all the passwords I've ever used and figured it out :)
I turned off Secure Boot but it still won't boot Fedora.
I finally figured out I had to use -v to get what I wanted from
efibootmgr:
BootCurrent: 0001 Timeout: 0 seconds BootOrder: 000E,0001,0003,2001,2002,2003
Offhand, this looks like the problem. 000E points to Windows. You need to use `efibootmgr --bootorder 0,E,1` so it boots Fedora first. It's not strictly necessary to list everything in bootorder, you can just have one. The idea of populating it fully is to have exactly the predictable fallback boot behavior the user wants, whatever that is. e.g. if something with the Fedora bootloader gets nerfed then it'd boot Windows.
I'm pressing F12 and manually selecting Fedora, but I did later try to change the boot order, both with efibootmgr and in the BIOS to no avail.
Boot0000* Fedora
HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shimx64.efi)
Offhand, looks valid but I can't vouch for either the partition number or its GUID.
I can confirm it's the correct UUID for the EFI partition. I have also reinstalled Fedora after deleting all the superfluous entries... Looks the same, still doesn't boot.
Boot0001* Linpus lite
HD(1,MBR,0x7c3f77cf,0x1c7e4,0x4df8)/File(\EFI\Boot\grubx64.efi)RC
Boot0002* Unknown Device:
HD(1,GPT,b2fa98e2-c3c8-4798-8faa-1e424d313bb1,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC
Boot0003* Fedora
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0,0,0)/HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\grubx64.efi)A01 ..
Boot0004* Unknown Device:
HD(1,GPT,0d7acc81-f083-490b-b47f-a8cce7c591be,0x800,0x32000)/File(\EFI\fedora\shim.efi)RC
I would use efibootmgr to delete these, they look either suboptimal (unknown device) or use old paths to grub rather than shim.
As far as I can tell, these are auto entries from the BIOS boot order. When I press F12 only Fedora and Windows Boot Manager are listed as available (Or Linpus Lite for the F29 Live USB).
If you're not sure you can delete them all, and then do:
# grep efibootmgr /var/log/anaconda/program.log
And you'll see the longest command there is what's used to add the menu entry. You can just use the same command, although you'll need to escape the backslashes with backslashes, so the path becomes \efi\fedora\shimx64.efi
Tried this too, although I used "" instead of escaping, no luck.
Also, firmware password and UEFI Secure Boot are two different things. Secure Boot I don't recommend disabling, it's a feature that cryptographically verifies the bootloaders, the kernel and kernel modules. If you're building out of tree kernel modules, then it's understandable to run without Secure Boot but I would still go through the effort to create your own signing cert, register it in the firmware, and then use it to sign your modules so that you can enable secure boot.
I disabled it to remove it as the problem, still won't boot Fedora. Once I get it working I can mark the efi file (presumably shimx64.efi) as trusted and re-enable.
Thanks, Richard
On Wed, Apr 24, 2019 at 5:24 PM Richard Shaw hobbes1069@gmail.com wrote:
On Wed, Apr 24, 2019 at 5:35 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Apr 24, 2019 at 8:02 AM Richard Shaw hobbes1069@gmail.com wrote:
While I had to run it through the shredder I finally sat down and went through all the passwords I've ever used and figured it out :)
I turned off Secure Boot but it still won't boot Fedora.
I finally figured out I had to use -v to get what I wanted from efibootmgr:
BootCurrent: 0001 Timeout: 0 seconds BootOrder: 000E,0001,0003,2001,2002,2003
Offhand, this looks like the problem. 000E points to Windows. You need to use `efibootmgr --bootorder 0,E,1` so it boots Fedora first. It's not strictly necessary to list everything in bootorder, you can just have one. The idea of populating it fully is to have exactly the predictable fallback boot behavior the user wants, whatever that is. e.g. if something with the Fedora bootloader gets nerfed then it'd boot Windows.
I'm pressing F12 and manually selecting Fedora, but I did later try to change the boot order, both with efibootmgr and in the BIOS to no avail.
OK you changed the bootorder using 'efibootmgr --bootorder' and you got what result from that command? Whether it works or doesn't, it returns a result that might be useful. And then you can confirm it with 'efibootmgr -v' and that also would be useful. And whenever there are unexplained results, I like to look at dmesg right before and after running efibootmgr (or use journalctl -f in another shell) to see if there are any kernel messages at the time. Ultimately the NVRAM is modified by the kernel, and efibootmgr is just the user interface to those kernel ioctls that do the actual modification of NVRAM.
Also, there's a bunch of bugs in this area, so I suggest making sure the firmware is up to date. I've seen all kinds of weird garbage collection issues where entries don't get deleted, or even bootorder not sticking, or bootnext not getting set.
I can confirm it's the correct UUID for the EFI partition. I have also reinstalled Fedora after deleting all the superfluous entries... Looks the same, still doesn't boot.
Sounds like a bug. Question is figuring out whose bug and how to work around it. Anyway, in addition to making sure the firmware is up to date, I'd go into the firmware setup, and choose the 'load defaults' or 'reset configs' option, and then exit (which will involve saving the defaults).
Also, firmware password and UEFI Secure Boot are two different things. Secure Boot I don't recommend disabling, it's a feature that cryptographically verifies the bootloaders, the kernel and kernel modules. If you're building out of tree kernel modules, then it's understandable to run without Secure Boot but I would still go through the effort to create your own signing cert, register it in the firmware, and then use it to sign your modules so that you can enable secure boot.
I disabled it to remove it as the problem, still won't boot Fedora. Once I get it working I can mark the efi file (presumably shimx64.efi) as trusted and re-enable.
There should be no need to mark any of the Fedora bootloaders, shimx64.efi or grubx64.efi, as trusted. The shimx64.efi file is signed by both Microsoft and Fedora, the computer firmware should have in its database the Microsoft UEFI X.509 cert, and therefore will trust shimx64.efi. And shimx64.efi provides the firmware with the Fedora X.509 cert so that the firmware will trust grubx64.efi and the kernel and kernel modules, all of which are signed by Fedora's signing key. If you have to do something special to get the firmware to trust any of these things, and you're not compiling your own binaries somewhere somehow, then something's wrong - and that needs to be figured out.
-- Chris Murphy
On Sat, Apr 27, 2019 at 5:46 PM Chris Murphy lists@colorremedies.com wrote:
On Wed, Apr 24, 2019 at 5:24 PM Richard Shaw hobbes1069@gmail.com wrote:
On Wed, Apr 24, 2019 at 5:35 PM Chris Murphy lists@colorremedies.com
wrote:
On Wed, Apr 24, 2019 at 8:02 AM Richard Shaw hobbes1069@gmail.com
wrote:
While I had to run it through the shredder I finally sat down and
went through all the passwords I've ever used and figured it out :)
I turned off Secure Boot but it still won't boot Fedora.
I finally figured out I had to use -v to get what I wanted from
efibootmgr:
BootCurrent: 0001 Timeout: 0 seconds BootOrder: 000E,0001,0003,2001,2002,2003
Offhand, this looks like the problem. 000E points to Windows. You need to use `efibootmgr --bootorder 0,E,1` so it boots Fedora first. It's not strictly necessary to list everything in bootorder, you can just have one. The idea of populating it fully is to have exactly the predictable fallback boot behavior the user wants, whatever that is. e.g. if something with the Fedora bootloader gets nerfed then it'd boot Windows.
I'm pressing F12 and manually selecting Fedora, but I did later try to
change the boot order, both with efibootmgr and in the BIOS to no avail.
OK you changed the bootorder using 'efibootmgr --bootorder' and you got what result from that command? Whether it works or doesn't, it returns a result that might be useful. And then you can confirm it with 'efibootmgr -v' and that also would be useful. And whenever there are unexplained results, I like to look at dmesg right before and after running efibootmgr (or use journalctl -f in another shell) to see if there are any kernel messages at the time. Ultimately the NVRAM is modified by the kernel, and efibootmgr is just the user interface to those kernel ioctls that do the actual modification of NVRAM.
The boot order showed as changed (no error) and as far as I know it remained after rebooting. It was just not working right and moved on to the Windows Boot Manager
Also, there's a bunch of bugs in this area, so I suggest making sure the firmware is up to date. I've seen all kinds of weird garbage collection issues where entries don't get deleted, or even bootorder not sticking, or bootnext not getting set.
What's weird is that the exact same laptop was working fine dual booting before the HD crash. I restored using the same Window (factory USB) restore stick. The only difference I can think of is that I MIGHT have installed Fedora 28 on it.
Also, firmware password and UEFI Secure Boot are two different things. Secure Boot I don't recommend disabling, it's a feature that cryptographically verifies the bootloaders, the kernel and kernel modules. If you're building out of tree kernel modules, then it's understandable to run without Secure Boot but I would still go through the effort to create your own signing cert, register it in the firmware, and then use it to sign your modules so that you can enable secure boot.
I disabled it to remove it as the problem, still won't boot Fedora. Once
I get it working I can mark the efi file (presumably shimx64.efi) as trusted and re-enable.
There should be no need to mark any of the Fedora bootloaders, shimx64.efi or grubx64.efi, as trusted. The shimx64.efi file is signed by both Microsoft and Fedora, the computer firmware should have in its database the Microsoft UEFI X.509 cert, and therefore will trust shimx64.efi. And shimx64.efi provides the firmware with the Fedora X.509 cert so that the firmware will trust grubx64.efi and the kernel and kernel modules, all of which are signed by Fedora's signing key. If you have to do something special to get the firmware to trust any of these things, and you're not compiling your own binaries somewhere somehow, then something's wrong - and that needs to be figured out.
Well, I "fixed" it but I can't say exactly why it works...
On a whim I re-enabled Secure Boot and then set shimx64.efi as trusted, which actually created a new EFI entry (Fedora2) and it works!
The only difference I can see is that the entry I setup through the BIOS uses the PciRoot(...) method instead of HD(...).
Thanks, Richard
-
Chris Murphy -
George N. White III -
Richard Shaw