Description of problem: When trying to boot Fedora 20 in secure mode enabled in BIOS setup, I get: Secure boot failed. Operating system is invalid. Version-Release number of selected component (if applicable): shim-0.7-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. Do a fresh F20 install in insecure mode and install all updates (yum update). 2. Enable secure boot option in BIOS 3. reboot Actual results: "Secure boot failed. Operating system is invalid." Expected results: System boots in secure mode. Additional info: Fedora is the only operating system installed. Disk was repartitioned by anaconda during installation. Output from efibootmgr after "insecure mode" boot: # efibootmgr -v BootNext: 0000 BootCurrent: 0006 Timeout: 5 seconds BootOrder: 0000,0006,0005 Boot0000* Fedora ACPI(a0341d0,0)PCI(1c,4)PCI(0,0)03120a000000ffff0000HD(1,800,64000,125c716d-03f5-4dd5-b736-9bcf53d38690)File(\EFI\FEDORA\shim.efi).. Boot0005* Windows Boot Manager HD(1,800,64000,125c716d-03f5-4dd5-b736-9bcf53d38690)File(\EFI\Microsoft\Boot\bootmgfw.efi) Boot0006* Windows Boot Manager HD(1,800,64000,125c716d-03f5-4dd5-b736-9bcf53d38690)File(\EFI\Boot\bootx64.efi) The machine is Sony Vaio Pro 13 (SVP1322C5E). UEFI BIOS version: R2080V7 (21 December 2013)
The following is displayed on screen before grub2 menu shows up: Booting in insecure mode System BootOrder not found. Initializing defaults. device path: "Acpi(PNP0A03,0)/Pci(1C|4)/Pci(0|0)/?/HD(Part1,Sig125C716D-03F5-4DD5-B736-9BCF53D38690)/\EFI\FEDORA\shim.efi" Creating boot entry "Boot0000" with label "Fedora" for file "\EFI\FEDORA\shim.efi" Booting in insecure mode
Can you attach the contents of /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f ?
Created attachment 882939 [details] /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f contents attached
I had exactly the same problem on a Toshiba Satellite P50 laptop. Eventually traced the problem to the fact that this firmware was NOT USING the boot order specified in the BootOrder UEFI variable, but was instead using the order specified in a separate variable called FAKEOrder. (Buggy firmware, or some weird UEFI special case behaviour?) Symptoms: - Secure boot failed (because it never got to the signed Fedora bootloader, since that was only in BootOrder not FAKEOrder) - Insecure boot worked but fell back to a generic boot from what it could find on the hard disk, which was the shim code in fallback.c (I think) - Shim then tried to add itself to the boot order for next time, but this just resulted in a duplicate entry in BootOrder and none in FAKEOrder. - Over successive boots, there were more and more Bootxxxx variables created, and BootOrder got clogged up with a longer and longer list of them. This would probably have eventually cause the machine to lock up and fail to boot at all. Solution: cat /sys/firmware/efi/efivars/BootOrder-... > /sys/firmware/efi/efivars/FAKEOrder-... and a reboot solved all the problems and I could re-enable secure boot. Original poster: If you do an ls /sys/firmware/efi/efivars, do you see a variable with a name like "FAKEOrder" or something similar? If so, does "hexdump -C /sys/firmware/efi/efivars/that_variable" show you something similar to BootOrder but with the Fedora entries missing? If so, try saving it somewhere else (preferably to a removable device that you can boot from to recover if something goes wrong ... verify you can book from the removable device first before messing with this!) and try copying BootOrder over to FAKEOrder as above. If this is the case, then maybe this quirk (bug?) is present in multiple models of laptop and shim should probably work around it. At the very least, the fallback code in shim should check to see if an entry is already present in BootOrder before adding it again. If it is already present, then it should display an alert to the user that the hardware is not respecting the UEFI BootOrder variable so that people know what's happening. And perhaps, if FAKEOrder is found, copy BootOrder over onto it ... is FAKEOrder a documented UEFI variable somewhere? If so, its documentation should probably be consulted rather than just blindly copying what I did, and a bug report should probably be filed against efibootmgr so it can look at FAKEOrder as well as BootOrder. If FAKEOrder is just some weird manufacturer's special case, then I'm not sure what the right behaviour is, but some sort of alert should at least be issued and shim should still be fixed so that it doesn't create duplicate entries in this case.
Philip, here's what I found: $ hexdump -C /sys/firmware/efi/efivars/SonyBootNext-f4019732-066e-4e12-8273-346c5641494f 00000000 07 00 00 00 00 00 00 00 |........| 00000008 $ hexdump -C /sys/firmware/efi/efivars/BootNext-8be4df61-93ca-11d2-aa0d-00e098032b8c 00000000 07 00 00 00 00 00 |......| 00000006 $ hexdump -C /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c 00000000 07 00 00 00 00 00 06 00 07 00 05 00 |............| 0000000c Any idea what I can do?
That's strange. I've also got a Sony Vaio Pro 13 (2014 model) and I don't have BootNext or SonyBootNext in /sys/firmware/efi/efivars/ I do, however, have about 70 entries in the efibootmgr for Fedora, so maybe it is a similar issue to Philip's.
Dominik, That's odd, as it seems your system is using a different BootNext variable, rather than a different BootOrder variable -- but both it and the regular BootOrder variable seem to have 0000 as the first entry, and I believe you said 0000 was your Fedora entry which is what you want to be booting? Also, BootNext is supposed to only persist for one boot, not to be persistent; it should just hold "07 00 00 00" after a regular boot. Bizarre. So I've no suggestions specific to your setup. But it does seem as though all these firmwares are using their own mechanism to determine the boot order, bypassing the standard variables. So shim should definitely be patched so as NOT to insert itself into the boot order if it's already present, as this will cause an eventual overflow with too many entries. And, if it does see itself already present, it should give a message to the user saying something like "WARNING: UEFI Firmware is not respecting the boot order set by the BootOrder variable". And, someone who knows something about EFI/UEFI should investigate and prepare a list of mechanisms that firmware might use to determine boot order, and empower shim with the ability to use all these mechanisms rather than just the standard one which, apparently, is not being respected.
Similar problem with HP ZBook, bug 1136679.
Looks like Sony UEFI firmware ignores boot Timeout, BootOrder and BootNext settings, and does this, unconditionally: Look in /EFI/Microsoft/Boot/bootmgfw.efi; if present, boot it. Look in all sub-directories of /EFI/ for grubx64.efi. If present, boot it. Boot /EFI/Boot/bootx64.efi My workaround is, for now: cp /boot/efi/EFI/fedora/shim.efi /boot/efi/EFI/BOOT/grubx64.efi
I can confirm that this workaround appears to solve the issue on my Sony Vaio Pro 13 running Fedora 20.
Just for the record, credit for figuring out the hardwired boot order goes to fraublucher on Sony Community forum: http://community.sony.com/t5/VAIO-Software-Other-Operating/Can-t-get-running-dual-boot-Win8-1-and-Fedora-Linux-in-UEFI-amp/m-p/264729#M18024
The firmware actually looks for "Windows Boot Manager" label in the boot entries list and if it doesn't find it, it adds the two default ones: Boot0005* Windows Boot Manager HD(1,800,64000,125c716d-03f5-4dd5-b736-9bcf53d38690)File(\EFI\Microsoft\Boot\bootmgfw.efi) Boot0006* Windows Boot Manager HD(1,800,64000,125c716d-03f5-4dd5-b736-9bcf53d38690)File(\EFI\Boot\bootx64.efi) So, a better workaround is to delete all entries: efibootmgr -v -b 0000 -B efibootmgr -v -b 0005 -B efibootmgr -v -b 0006 -B and recreate the Fedora shim entry with "Windows Boot Manager" label: efibootmgr -v -c -L "Windows Boot Manager" -d /dev/sda -p 1 -l '\EFI\fedora\shim.efi' And now the firmware boots the Fedora shim only and no new entries appear: # efibootmgr -v BootNext: 0000 BootCurrent: 0000 Timeout: 5 seconds BootOrder: 0000 Boot0000* Windows Boot Manager HD(1,800,64000,125c716d-03f5-4dd5-b736-9bcf53d38690)File(\EFI\fedora\shim.efi This is courtesy of Ubuntu forums: http://ubuntuforums.org/showthread.php?t=2196415&p=12886568#post12886568 Jon, could you check if this works for you as well?
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.