Created attachment 1351442 [details] photo of screen Description of problem: Fedora 27 fails booting on Acer Swift 3 Version-Release number of selected component (if applicable): Fedora27 x64 How reproducible: Steps to Reproduce: 1. Upgrade Fedora26 x64to Fedora27 x64 via dnf Actual results: On boot time, getting the following message: System BootOrder not fond. Initialising defaults. Creating boot entry "Boot0000" with label Fedora for file "\EFI\fedora\shimx64.efi" Reset System Expected results: The laptop will power cycle and the message will show up again and again Additional info:
Same here on acer aspire v nitro tried many installs - update from working f26 (UEFI 1 Win10 disk and a separate f26 disk) -> BootOrder not found - clean install with the 2 disks, format + repartition fedo disk -> BootOrder not found - clean install with only fedo disk format + repartition -> BootOrder not found I'm so sad f27 looks so slick ;p I want it so bad !! :)))
here are some logs ________________________ [root@nitro ~]# lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT loop0 squashfs loop1 ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e ├─live-rw ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e / └─live-base ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e loop2 DM_snapshot_cow └─live-rw ext4 Anaconda ecca4143-2913-455c-852d-d66c32f4f25e / sda ├─sda1 vfat 0533-6B5A /mnt/sysimage/boot/efi ├─sda2 ext4 ee196870-6159-4b59-aeb9-7240a2562308 /mnt/sysimage/boot ├─sda3 swap 4100cf9c-48b2-4df9-be48-3aae85b5728a [SWAP] └─sda4 ext4 73311e2f-5f3f-46ac-a707-9c8cc368d367 /mnt/sysimage sdb iso9660 Fedora-WS-Live-27-1-6 2017-11-05-07-38-39-00 ├─sdb1 iso9660 Fedora-WS-Live-27-1-6 2017-11-05-07-38-39-00 /run/initramfs/live ├─sdb2 vfat ANACONDA FF9B-8FE5 └─sdb3 hfsplus ANACONDA 095b3e54-6722-3663-9355-20c7d4e06c4b [root@nitro ~]# efibootmgr -v BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0000,0003,0002,0001,2001,2002,2003 Boot0000* Fedora HD(1,GPT,6b132d67-567c-40fb-8e3c-c65fc1a85bd1,0x800,0x64000)/File(\EFI\fedora\shimx64.efi) Boot0001* Linpus lite HD(1,MBR,0x2563bf1a,0x1b9d0,0x4664)/File(\EFI\Boot\grubx64.efi)RC Boot0002* Command Linpus lite HD(1,MBR,0x2563bf1a,0x1b9d0,0x4664)/File(\EFI\Boot\bootx64.efi)RC Boot0003* Command Linpus lite HD(1,GPT,92b9be91-2ada-4c0e-a558-f94cb5dbbab2,0x800,0x64000)/File(\EFI\Boot\bootx64.efi)RC Boot0004* Unknown Device: HD(1,GPT,92b9be91-2ada-4c0e-a558-f94cb5dbbab2,0x800,0x64000)/File(\EFI\fedora\shim.efi)RC Boot0005* Unknown Device: HD(1,GPT,92b9be91-2ada-4c0e-a558-f94cb5dbbab2,0x800,0x64000)/File(\EFI\fedora\shim.efi)RC Boot2001* EFI USB Device RC Boot2002* EFI DVD/CDROM RC Boot2003* EFI Network RC
Same problem with a clean install on an EliteBook 8470p I think the 'Component:' value of this ticket must be changed to grub2 instead of 0ad.
Changed the component to grub2. Thanks.
maybe adjust the title too ? -> Fedora 27 fails to boot with EFI : BootOrder not found
Adjusted the title... Thank you for the suggestion.
I have the same problem on a Sony VAIO Pro laptop. After a dnf upgrade from Fedora 26 to 27 the system keeps power-cycling and producing the same error message as in the photo posted by Bogdan Bartos. Booting with a Fedora 25 live usb, I tried manually adding a boot entry with efibootmgr. This has no result, and if I boot from the usb again the boot entry has disappeared - I think this part (not the bug) may be a Sony thing. Any suggestions are highly appreciated.
I found a workaround to get Fedora 27 running but I would not call it a solution. First of all my observations about efibootmgr are besides the point - the efi boot is not the problem, the problem starts when efi passes on the responsibility to the bootloader in the efi partition. What I did was the following transplant: Step 1: I took the contents of the 'EFI' directory from a healthy booting Fedora 25 machine. The 'EFI' directory is the one that contains a 'BOOT' and a 'fedora' directory - just to clarify as this 'EFI' lives some levels down in another 'efi' directory. Step 2: On the affected machine, I renamed the 'EFI' directory to 'EFI-original' just to not loose the content. Step 3: I then copied the entire 'EFI' from the Fedora 25 machine to the affected machine. Step 4: I overwrote the files 'grub.cfg' and 'grubenv' to ensure the bootloader actually knows what to look for. Then a restart and the machine now shows the much desired normal grub menu with the option to boot Fedora 27. Booting now proceeds fine. Running dnf update yields some complaints as it tries to update grub-related things and cannot find certain things in expected locations. It seems to overcome these issues. The system now boots fine, the issue seems to have gone. As I mentioned, this is more of a dirty hack than a solution but perhaps it puts someone on the right track for a real solution or at least helps people out who were stuck on this.
@Fjalar cool move ;p can you give us detail about step 4 plz ?
(In reply to David Berlioz from comment #9) > @Fjalar cool move ;p can you give us detail about step 4 plz ? No problems. When you copy the entire 'EFI' directory (including subdirs) to the affected machine, it will contain a 'grub.cfg' and 'grubenv' that have bootentries pointing to kernels on the working machine - and which therefore won't work on the affected machine. Simply overwriting those two files with the versions you kept in the renamed old 'EFI' directory (I called it 'EFI-original') gives it the bootentry for Fedora 27. But now the system will actually reach the point where it hands control over to the grub bootloader so you can actually see the grub bootmenu. Hope this helps. Let me know if any further clarification or details are necessary.
(In reply to Fjalar from comment #8) > I found a workaround to get Fedora 27 running but I would not call it a > solution. First of all my observations about efibootmgr are besides the > point - the efi boot is not the problem, the problem starts when efi passes > on the responsibility to the bootloader in the efi partition. > > What I did was the following transplant: > > Step 1: I took the contents of the 'EFI' directory from a healthy booting > Fedora 25 machine. The 'EFI' directory is the one that contains a 'BOOT' and > a 'fedora' directory - just to clarify as this 'EFI' lives some levels down > in another 'efi' directory. > > Step 2: On the affected machine, I renamed the 'EFI' directory to > 'EFI-original' just to not loose the content. > > Step 3: I then copied the entire 'EFI' from the Fedora 25 machine to the > affected machine. > > Step 4: I overwrote the files 'grub.cfg' and 'grubenv' to ensure the > bootloader actually knows what to look for. > > Then a restart and the machine now shows the much desired normal grub menu > with the option to boot Fedora 27. Booting now proceeds fine. Running dnf > update yields some complaints as it tries to update grub-related things and > cannot find certain things in expected locations. It seems to overcome these > issues. The system now boots fine, the issue seems to have gone. > > As I mentioned, this is more of a dirty hack than a solution but perhaps it > puts someone on the right track for a real solution or at least helps people > out who were stuck on this. Same issue for my Thinkpad-t450s. With that workaround i can boot correctly. I had the same issue when i made a clean f27 install or a f26 to f27 upgrade. Maybe an error in installation procedure?
Same issue on my acer travelmate. @Fjalar How do I get the contents of the 'EFI' directory if I don't have a healthy booting Fedora machine anymore? :D
The problem lied in the bios of my Acer laptop. Maybe this workaround is helpful for some of you too: https://www.reddit.com/r/Fedora/comments/7d38pb/f27_systembootorder_not_found_after_update_does/
(In reply to spamemichzu from comment #14) > The problem lied in the bios of my Acer laptop. Maybe this workaround is > helpful for some of you too: > > https://www.reddit.com/r/Fedora/comments/7d38pb/ > f27_systembootorder_not_found_after_update_does/ In my case the secure boot is already disabled. I resolved coping EFI folder from F26 to F27 skipping grub.cfg and grubenv
Don't get me wrong. The problem lied in the bios although my specific workaround is a bit different: 1) Change Boot Mode from Legacy to UEFI 2) Enable Secure Boot 3) Go to Security -> Secure Boot Mode -> Select an UEFI file as trusted for executing 4) Find and select grubx64.efi
Maybe you guys got lucky. If I select secure boot, I get no option on my Acer to select the file. There should not be a workaround, there should be a fix.
Same here. Did the upgrade today. There seems to be an issue with the shim package shim-x64-13-0.7.x86_64. I uninstalled the package and installed the previous version shim-0.8-10.x86_64 and that resolved the issue. HP folio 9470m
(In reply to feeble from comment #18) > Same here. Did the upgrade today. There seems to be an issue with the shim > package shim-x64-13-0.7.x86_64. I uninstalled the package and installed the > previous version shim-0.8-10.x86_64 and that resolved the issue. > > > HP folio 9470m Just wanted to add that this occurs when trying to load bootx64.efi and the failback efi. Not sure what is wrong with the binaries.
In reply to comment 17: > If I select secure boot, I get no option on my Acer to select the file. @Bogdan: in the Acer Nitro BIOS, you must have the supervisor password set and the secure boot enabled to be able to enter a new UEFI trusted file. You may remove the password after operations at your convenience. Maybe this also applies to the Acer Swift. I have better results if I move the new UEFI entry at position 1 in boot order (autoboot ok).
I managed to make it work like Patrick suggested. I changed the supervisor password in the BIOS, rebooted, got back in the BIOS, changed the secure boot to UEFI and selected grub as the trusted boot source and named it Fedora and it autoboots properly. I am not sure if this is a fix or a workaround, but it sure makes it work with not much hassle. Thank you guys!
(In reply to spamemichzu from comment #16) > Don't get me wrong. The problem lied in the bios although my specific > workaround is a bit different: > > 1) Change Boot Mode from Legacy to UEFI > 2) Enable Secure Boot > 3) Go to Security -> Secure Boot Mode -> Select an UEFI file as trusted for > executing > 4) Find and select grubx64.efi I have upgraded to Fedora 27 on an HP EliteBook 8740w, and I got the same problem than all people complaining here. So I have to boot manually, by choosing any *.efi file under /EFI/fedora/ from my HP UEFI monitor. But it's really boring to do so Each time I powerup my laptop, so I dont found this as a final workaround solution, but just a debug solution, untils a real solution is found ! And apparently some people here have a very simplistic EFI monitor, WITH NO OPTION to navigate in EFI directory to choose an *.efi file !!!!! So I'm going to try the suggested solution by: feeble 2017-11-23 13:48:22 EST described above, if secure boot shim.efi is the blocking point! Does this new SHIM system check some AUTHORYTY certificate somewhere ? And because they are not installed, the shim.efi cannot be used in an other mode than "forced manually" ????
I am in dualboot Windows 2012 and Fedora 27, so disable secure boot in UEFI mode is not an option, otherwise I don't boot in windows mode And unlike spamemichzu with his Acer laptop, I have no option like: Security -> Secure Boot Mode -> Select an UEFI file as trusted On Some more modern laptop (less than 3 years), like ASUS we can find some certificate on the laptop, provide by Asus , some of them identifies uniquely a given laptop.This is used by Microsoft to detect if you can reinstall a laptop with a given version of windows 8, 10? without reentering activation key. Is new SHIM implementation using something quite similar ? Building a kernel key signature with the private key of one of these LAPTOP certificate, and put it under a directory something like : f66bdc3dfcc84e2fbd5cd4469e75ffb8/4.13.13-300.fc27.x86_64 (this is my situation after installation on 25 Nov 2017, on my disk) Because under my laptop, this directory created by the installation remains empty !
The situation, before trying any solution suggested above : ================================= since Fedora 27 is installed on my EliteBook 8740w : Each time you boot automatically, it goes into continuous boot loop, and a new entry is added in UEFI monitor, visible with efibootmanager. So I had to write a script to remove all these unuseful entries , when there is too many ones! And yes, the only way to boot is to choose the EFI boot manager manually, by navigating in the EFI File system: any shim.efi, shimx64.efi, grubx64.efi, under EFI/fedora/ is usable to perform that/ But no solution to fix this manual choice for the next reboots !
Ok , I followed the suggested turnaround suggested above by: feeble 2017-11-23 13:48:22 EST And all is working now. The step: I first boot manually grop HP EliteBook UEFI monitor, by navigating in EFI file system, to EFI/fedora/shimx64.efi NOTE ===== I chose this one because with others, I cannot remove extra "fedora" entries listed by efibootmanager (one added automatically each time i boot the PC !), getting an error: " ..no space left on device .." (You must understand in UEFI EEPROM !) If I choose EFI/BOOT/BOOTX64.EFI It doesn't boot either, while this file is a copy (I checked it with diff) of EFI/fedora/shimx64.efi. So this efi prog check itself its PATH, before geving hand to grub2 boot loader first stage ! =================== Once system booted, and I'am logged in, all the command are in a shell terminal, where you are root: $ su - root password: # 1) # dnf remove shim-x64 2) dowload shim-0.8-10.x86_64.rpm package from any mirror of Fedora 26 package for example # wget http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/26/Everything/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm 3) install it dnf install shim-0.8-10.x86_64.rpm Then reboot, and after reboot, it works and I have something like: # efibootmgr BootCurrent: 0000 Timeout: 10 seconds BootOrder: 0004,0000,0001,0002 Boot0000* Notebook Upgrade Bay Boot0001* Notebook Hard Drive Boot0002* Notebook Ethernet Boot0003* Fedora Boot0004* Fedora Boot0031* Windows Boot Manager Subsequent boot, letting on my hp 8740W booting by default with "System upgrade Bay", will work, but UEFI monitor (?) adds a new Boot000X* Fedora entry, and this entry becomes automatically the first entry (like in this example : 0004)in the boot order. On the reverse with the new shim-x64 package of Fedora 27, this default entry is not added by UEFI monitor BootOrder, while extra entry Boot000X* Fedora continue to be added ! Of cause I can add this extra entry with efibootmgr -o 4,0,1,2 but at rebbot, this fisrt boot entry : 4 in boot order is removed by UEFI monitor !!!!!! ========= So what's the problem ? Was the shim.efi program was signed by Microsoft certificate until Fedora 26 ? Ans now its self signed ? And that the reason why yhe HP EliteBook 8740w, refuse to add this entry in UEFI boot order ??? I tried to read this: https://docs-old.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html but its not obvoius to me how exactly its works !!!
Before accepting as only current usable solution: install shim-0.8-10.x86_64.rpm from Fedora 26, I tried to install shim-unsigned-x64.x86_64, letting standard package shim-x64 installed too. and Then after renaming all *.efi file under: /boot/efi/EFI/fedora/ in *.efi.ref Then I made a copy of *.efi files provided under /usr/share/shim/13-3.fc27/x64/ by shim-unsigned-x64, in the standard directory: /boot/efi/EFI/fedora/ And at the end, always under /boot/efi/EFI/fedora/ make a copy of shimx64.efi in shim.efi, because the standard shimx64.efi and shim.efi, provided by shim-x64 are also identical! And i did not get any better result than with original efi programm, provided by shim-x64!
(In reply to Yves L'ECUYER from comment #25) > Ok , I followed the suggested turnaround suggested above by: > feeble 2017-11-23 13:48:22 EST > And all is working now. > The step: > I first boot manually grop HP EliteBook UEFI monitor, by navigating in EFI > file system, to EFI/fedora/shimx64.efi > NOTE > ===== > I chose this one because with others, I cannot remove extra "fedora" entries > listed by efibootmanager (one added automatically each time i boot the PC > !), getting an error: > " ..no space left on device .." (You must understand in UEFI EEPROM !) > > If I choose EFI/BOOT/BOOTX64.EFI > It doesn't boot either, while this file is a copy (I checked it with diff) > of EFI/fedora/shimx64.efi. So this efi prog check itself its PATH, before > geving hand to grub2 boot loader first stage ! > =================== > Once system booted, and I'am logged in, > > all the command are in a shell terminal, where you are root: > $ su - root > password: > # > 1) > # dnf remove shim-x64 > > 2) > dowload shim-0.8-10.x86_64.rpm package from any mirror of Fedora 26 package > for example > # wget > http://ftp.free.fr/mirrors/fedora.redhat.com/fedora/linux/releases/26/ > Everything/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm > > 3) install it > dnf install shim-0.8-10.x86_64.rpm > > Then reboot, > and after reboot, it works and I have something like: > # efibootmgr > BootCurrent: 0000 > Timeout: 10 seconds > BootOrder: 0004,0000,0001,0002 > Boot0000* Notebook Upgrade Bay > Boot0001* Notebook Hard Drive > Boot0002* Notebook Ethernet > Boot0003* Fedora > Boot0004* Fedora > Boot0031* Windows Boot Manager > > Subsequent boot, letting on my hp 8740W booting by default with "System > upgrade Bay", will work, but UEFI monitor (?) adds a new > Boot000X* Fedora > entry, and this entry becomes automatically the first entry > (like in this example : 0004)in the boot order. > > On the reverse with the new shim-x64 package of Fedora 27, this default > entry is not added by UEFI monitor BootOrder, > while extra entry > Boot000X* Fedora > continue to be added ! > Of cause I can add this extra entry with > efibootmgr -o 4,0,1,2 > but at rebbot, this fisrt boot entry : 4 > in boot order is removed by UEFI monitor !!!!!! > ========= > So what's the problem ? > Was the shim.efi program was signed by Microsoft certificate until Fedora 26 > ? > Ans now its self signed ? And that the reason why yhe HP EliteBook 8740w, > refuse to add this entry in UEFI boot order ??? > I tried to read this: > https://docs-old.fedoraproject.org/en-US/Fedora/18/html/ > UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide- > Implementation_of_UEFI_Secure_Boot-Shim.html > but its not obvoius to me how exactly its works !!! @Yves You have peaked my interest in this. At this point I was just happy to not have to select the efi each time I was booting. I don't think it's the signature. From my limited knowledge, the signature only applies if you have secureboot on. After the upgrade I thought maybe I had inadvertently turned secureboot on. I have seen a similar issue on EL7 servers. You can manually load the EFI prog, but grub will never load. There is definitely something wrong with new shim package. I assume most people are not using the EFI bios and therefore not seeing this issue.
Just read the release notes for the newest shim package. Please refer to rhbz#1497854. Refer to this comment on that bz. shim-signed-13-0.7 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e2325fb83d
(In reply to spamemichzu from comment #12) > Same issue on my acer travelmate. > > @Fjalar How do I get the contents of the 'EFI' directory if I don't have a > healthy booting Fedora machine anymore? :D I suppose I could send you the files? Let me know if it is still necessary, I haven't been online for a couple of days and it seems there are other suggestions available now. Cheers, F.
(In reply to Fjalar from comment #29) > (In reply to spamemichzu from comment #12) > > Same issue on my acer travelmate. > > > > @Fjalar How do I get the contents of the 'EFI' directory if I don't have a > > healthy booting Fedora machine anymore? :D > > I suppose I could send you the files? Let me know if it is still necessary, > I haven't been online for a couple of days and it seems there are other > suggestions available now. Cheers, F. I found a solution (comment #16), but thanks anyway.
(In reply to feeble from comment #27) > (In reply to Yves L'ECUYER from comment #25) > > Ok , I followed the suggested turnaround suggested above by: > > feeble 2017-11-23 13:48:22 EST > > And all is working now. ... > > ========= > > So what's the problem ? > > Was the shim.efi program was signed by Microsoft certificate until Fedora 26 > > ? > > Ans now its self signed ? And that the reason why yhe HP EliteBook 8740w, > > refuse to add this entry in UEFI boot order ??? > > I tried to read this: > > https://docs-old.fedoraproject.org/en-US/Fedora/18/html/ > > UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide- > > Implementation_of_UEFI_Secure_Boot-Shim.html > > but its not obvoius to me how exactly its works !!! > > @Yves You have peaked my interest in this. At this point I was just happy to > not have to select the efi each time I was booting. I don't think it's the > signature. From my limited knowledge, the signature only applies if you have > secureboot on. After the upgrade I thought maybe I had inadvertently turned > secureboot on. I have seen a similar issue on EL7 servers. You can manually > load the EFI prog, but grub will never load. There is definitely something > wrong with new shim package. I assume most people are not using the EFI bios > and therefore not seeing this issue. =================================== IN MY CASE, secure boot IS ENABLED =================================== because my HP EliteBook is installed in dual mode, with Windows 2012R2 so disabling secureboot is not an option. I take time to do more investigation: first the link I give in my previous comment 25: https://docs-old.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guide/sect-UEFI_Secure_Boot_Guide-Implementation_of_UEFI_Secure_Boot-Shim.html There you can read at the beginning: ===================== 3.2. Shim Fedora uses a first-stage boot loader called shim which embeds a self-signed CA certificate. This CA is then used to verify the GRUB 2 boot loader (UEFI version, a PE/COFF program signed with AuthentiCode). Before booting a kernel, GRUB 2 calls back into shim to verify the AuthentiCode signature of the kernel." . . . ==================== So its clear, in shim*.efi, there is a CA certificate, whith at least its public-key, to allow: 1) grub to check it's own signature 2) then grub chek kernel signature with the same public key. That's mean, Fedora Development or packaging team, get the private key corresponding to that embedded CA certificate with its public key. OK SO as long as , you allow any shim*.efi to be loaded through EFI monitor: 1) either navigating manually in EFI filesystem (allowed by HP EliteBokk UEFI monitor) 2) or declaring a specific PATH to a given *.efi file, marked manually as trusted in monitor( NOT allowed by HP EliteBokk UEFI monitor, but YES on others Manufacturers, as mentioned in others comments in this buzilla report) The boot process is not stopped. The presence of self-signed CA certificate, can be checked easily in any file *.efi, brought by package shim.x86_64, shim-x64.x86_64 , or shim-unsigned-x64.x86_64, whith : # cd /boot/efi/EFI # find . | xargs fgrep "Fedora Secure Boot CA" *.efi 2> /dev/null Binary file ./BOOT/BOOTX64.EFI matches Binary file ./BOOT/fallback.efi matches Binary file ./fedora/grubx64.efi matches Binary file ./fedora/MokManager.efi matches Binary file ./fedora/shim-fedora.efi matches Binary file ./fedora/shim.efi matches BUT THE DIFFERENCE is about the program SIGNATURE of shimx64.efi itself. shim.x86_64, shim-x64.x86_64 ==> shimx64.efi is SIGNED shim-unsigned-x64.x86_64 ==> shimx64.efi is NOT SIGNED BUT SIGNED WITH WHAT ???? EXPLANATION FOLLOWS ..... ============ As i mentioned previously, when HP EliteBook monitor start in SECURE MODE, the UEFI monitor programm, recheck all what it found as "SECURE" EFI program, in EFI file system, and add them with an order number, X, Y, in the boot order, before the standard ones 0,1,2, corresponding to the physical peripherals. This order is re-checked each time you reboot. So whatever you are setting with efibootmgr , all this is reset by the UEFI monitor secure policy , as soon as securebot it enabled. ======= HOW HP UEFI EliteBook monitor considers that an *.efi program is secure ? ONLY when signed by a Microsoft CA certificate. Here are some links corroborating this process: https://unix.stackexchange.com/questions/93787/how-do-i-use-custom-signed-shim-for-secure-boot-fedora ======== related text ============== How do I use custom-signed shim for secure boot (Fedora)? I'm not sure whether there's a guide for this but I'd like to know the detailed steps (step-by-step guide perhaps?) involved in achieving the following: Re-sign shim with a custom CA private key, but still let shim to use Fedora boot CA public key to verify the kernel components for Secure Boot. Replace Microsoft's key stored in the firmware with the corresponding custom CA public key whose private key was used to sign shim. The main goal that I want to achieve is to replace the built-in Microsoft's CA certificate stored in the firmware, in order to forbid Microsoft-signed OS bootloaders from being executed, and still use the UEFI's secure boot functionality to boot ... ===================================== In this one, the question is clearly asked, in the little comment at the end of this HTML page : https://askubuntu.com/questions/342365/what-is-the-difference-between-grubx64-and-shimx64 ======== related text ============== Did MS sign shimx64.efi then? – Mâtt Frëëman Mar 8 '15 at 8:28 Yes, Microsoft signed shimx64.efi -- at least, the version that Ubuntu installs on Secure Boot computers. (There are also unsigned Shim binaries available; or you can install your own Secure Boot keys and sign shimx64.efi yourself to take full control of your computer's Secure Boot process. – Rod Smith Mar 8 '15 at 15:04 ==================================== So in Fedora, the requirement is the same for shimx64.efi, otherwise UEFI Monitor has no mean to check the validity of this *.efi programm (EXCEPT in UEFI monitor, like the ASUS ones, where you can install extra CA certificate !) ===========CONCLUSION======================= Something goes wrong in current stable shim.x86_64 package preparation for Fedora 27, and that the reason of this bug ! The signon process of shimx64.efi, was performed by a private key in an expired Microsoft certificate belonging to Fedora development team ? ONLY DEVELOPPER CAN ANSWER TO THIS !
(In reply to feeble from comment #28) > Just read the release notes for the newest shim package. Please refer to > rhbz#1497854. Refer to this comment on that bz. > > shim-signed-13-0.7 has been pushed to the Fedora 27 testing repository. If > problems still persist, please make note of it in this bug report. > See https://fedoraproject.org/wiki/QA:Updates_Testing for > instructions on how to install test updates. > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2017-e2325fb83d YES I read that for ARM 64 architecture. But the context of this bug report is not the same as bug1512410 Paul Whalen was just complaining about the lacking of shim.efi in EFI file system. This is no more the case in new package on line shim-x64-13-0.7, because for architecture x86_64 shim.efi and shimx64.efi, exist and have the same content: # ll /boot/efi/EFI/fedora/shim* -rwx------. 1 root root 1293304 Oct 4 17:39 /boot/efi/EFI/fedora/shim.efi -rwx------. 1 root root 1293304 Oct 4 17:39 /boot/efi/EFI/fedora/shimx64.efi -rwx------. 1 root root 1206896 Oct 4 17:39 /boot/efi/EFI/fedora/shimx64-fedora.efi [root@encelade utils]# diff /boot/efi/EFI/fedora/shim.efi /boot/efi/EFI/fedora/shimx64.efi [root@encelade utils]# (so their content are identical) =========== And I suppose that Paul is not working in a secure boot UEFI environment, so he did not notice the problem with the signature of shim.efi itself ? To show the listing above I re-installed shim-x64-13-0.7 package after the working bug turnaround solution with Fedora 26 shim package was tested succesfully: ==================proof===================== # dnf info shim-x64 Failed to synchronize cache for repo 'local', disabling. Last metadata expiration check: 0:03:41 ago on Mon 04 Dec 2017 06:03:10 PM CET. Installed Packages Name : shim-x64 Version : 13 Release : 0.7 Arch : x86_64 Size : 7.2 M Source : shim-signed-13-0.7.src.rpm Repo : @System From repo : fedora Summary : First-stage UEFI bootloader URL : http://github.com/rhboot/shim/ License : BSD Description : Initial UEFI bootloader that handles chaining to a trusted full : bootloader under secure boot environments. This package contains : the version signed by the UEFI signing service. =========================================== AND THIS DOES NOT WORK !!!!!!!!!!!!!!!!!!! As you can notice, for the moment this bugzilla report is like a forum between users NOBODY in fedora packaging team has reacted to that submit ! In bug reported for ARM 64 architecture,in https://bugzilla.redhat.com/show_bug.cgi?id=1497854 made an answer, and now in every architecture we benefit of the updated package: shim-x64-13-0.7 But the bug with EFI monitor in secure mode STILL REMAINS ======== NOTE ============== for information about ARM 64 architecture in Linux developpement, see: https://stackoverflow.com/questions/31851611/differences-between-arm64-and-aarch64 =============================
To understand what is lacking with shim-x64-13.0-7 to have a correct shim.efi (working in UEFI monitor secure boot environment) I tried to rebuild it from src file: shim-signed-13-0.7.src.rpm Once installed, look at /root/rpmbuild/SPEC/shim-signed.spec Then , to build with :# rpmbuild -bb shim-signed.spec you will have to install first the required package to build (as described in *.spec file above) # rpmbuild -bb shim-signed.spec error: Failed build dependencies: pesign >= 0.112-20.fc27 is needed by shim-signed-13-0.7.x86_64 shim-unsigned = 0.8-1.fc22 is needed by shim-signed-13-0.7.x86_64 shim-unsigned-ia32 = 13-3.fc27 is needed by shim-signed-13-0.7.x86_64 shim-unsigned-x64 = 13-3.fc27 is needed by shim-signed-13-0.7.x86_64 Ok I just installed pesign hoping to find some information about the signature tied with shimx64.efi , shim.efi because , if you look at *.specfile, you can see: ======= SPEC file ================= .... Source12: shimx64.efi Source13: shimx64-signed.efi ... %ifarch x86_64 %do_install -a x64 -A X64 -b %{SOURCE0} %do_install -a ia32 -A IA32 -b %{SOURCE2} install -m 0644 %{SOURCE2} $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/BOOT.CSV install -m 0644 $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/mmx64.efi $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/MokManager.efi install -m 0644 %{SOURCE13} $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/shim.efi install -m 0644 %{SOURCE13} $RPM_BUILD_ROOT/boot/efi/EFI/%{efidir}/shimx64.efi install -m 0644 %{SOURCE13} $RPM_BUILD_ROOT/boot/efi/EFI/BOOT/BOOTX64.EFI install -m 0644 $RPM_BUILD_ROOT/boot/efi/EFI/BOOT/fbx64.efi $RPM_BUILD_ROOT/boot/efi/EFI/BOOT/fallback.efi %endif ... ======================================== So shim.efi, shimx64.efi and BOOTX64.EFI are simple copy of Source13, brought by shim-signed-13-0.7.src.rpm NORMAL: that binary must be signed normally by private key associated to a Microsoft certificate, having also his public key AND only Linux distribution development team have that ! ===============NOTE==================== after shim-x64-13.0-7 installation we have: [root@encelade fedora]# pwd /boot/efi/EFI/fedora [root@encelade fedora]# pesign --show-signature -i shim.efi --------------------------------------------- certificate address is 0x7fe91fcdaa18 Content was not encrypted. Content is detached; signature cannot be verified. The signer's common name is Microsoft Windows UEFI Driver Publisher No signer email address. No signing time included. There were certs or crls included. --------------------------------------------- [root@encelade fedora]# ===============END NOTE==================== If you look in *.spec file all the modification performed on this package, since the one : shim-0.8-10 , used in Fedora 26 we see: ======= SPEC file ================= %changelog * Wed Oct 04 2017 Peter Jones <pjones> - 13-0.7 - Make /boot/efi/EFI/fedora/shim.efi still exist on aarch64 as well. Resolves: rhbz#1497854 * Tue Sep 19 2017 Peter Jones <pjones> - 13-0.6 - Fix binary format issue on Aarch64 Resolves: rhbz#1489604 * Tue Sep 05 2017 Peter Jones <pjones> - 13-0.5 - Make /boot/efi/EFI/fedora/shim.efi still exist on x86_64, since some machines have boot entries that point to it. * Tue Aug 29 2017 Peter Jones <pjones> - 13-0.4 - Make our provides not get silently ignore by rpmbuild... * Fri Aug 25 2017 Peter Jones <pjones> - 13-0.3 - x64: use the new fbx64.efi and mm64.efi as fallback.efi and MokManager.efi - Provide: "shim" in x64 and aa64 builds * Thu Aug 24 2017 Peter Jones <pjones> - 13-0.2 - Obsolete old shim builds. * Tue Aug 22 2017 Peter Jones <pjones> - 13-0.1 - Initial (partially unsigned) build for multi-arch support on x64/ia32. * Thu Mar 23 2017 Petr �| abata <contyk> - 0.8-9 - Re-enable dist tag for module builds ===================================== SO IN 13-0.5 release, shim.efi is re-introduced. But nothing about signature of file: shimx64-signed.efi +++++++++++++++++++++++++++++++++++ IS THERE A DIFFERENCE between : this file brought by shim-x64.13-0.7 and the one brought by shim-0.8-10.x86_64 from Fedora 26 ???? +++++++++++++++++++++++++++++++++++ To answer this I de-installed the first and re-installed the second check: # rpm -q --whatprovides /boot/efi/EFI/fedora/shim.efi shim-0.8-10.x86_64 # ll /boot/efi/EFI/fedora/shim.efi -rwx------. 1 root root 1293304 Aug 15 2016 /boot/efi/EFI/fedora/shim.efi Now I go in /root/rpmbuild/SOURCES, where we find the famous file : brought by shim-signed-13-0.7.src.rpm installation: [root@encelade SOURCES]# pwd /root/rpmbuild/SOURCES [root@encelade SOURCES]# ll *.efi -rw-rw-r--. 1 root root 868376 Sep 19 21:54 shimaa64.efi -rw-rw-r--. 1 root root 967681 Sep 19 21:54 shimia32.efi -rw-rw-r--. 1 root root 1204515 Sep 19 21:54 shimx64.efi -rw-rw-r--. 1 root root 1293304 Aug 21 23:46 shimx64-signed.efi [root@encelade SOURCES]# AND NOW THE COMPARISON: [root@encelade SOURCES]# diff /boot/efi/EFI/fedora/shim.efi shimx64-signed.efi [root@encelade SOURCES]# ++++++++++++++++++++++++++ So the answer is NO, it's not a problem with shim.efi signature ++++++++++++++++++++++++++ BUT when I switched several time between shim-0.8-10.x86_64 and shim-x64-13-0.7 I noticed with the last one, installation of dependencies, not required by the first. And this dependencies are removed if you remove shim-x64-13-0.7 --------------- Here is the process: ++++++++++++++++++++= # dnf install shim-x64 Failed to synchronize cache for repo 'local', disabling. Last metadata expiration check: 2:32:45 ago on Mon 04 Dec 2017 06:03:10 PM CET. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: shim-x64 x86_64 13-0.7 fedora 1.3 M Installing dependencies: dbxtool x86_64 8-3.fc27 fedora 35 k efivar x86_64 32-2.fc27 updates 30 k Transaction Summary ================================================================================ Install 3 Packages Total download size: 1.4 M Installed size: 7.3 M Is this ok [y/N]:y ++++++++++++++++++++++++++++++++ SO THE PROBLEM Could come from dbxtool or efivar, note used until now in stable Fedora release. About this extra package: ================= [root@encelade RHF27_i686_x86_64_addons]# dnf info efivar Failed to synchronize cache for repo 'local', disabling. Last metadata expiration check: 2:37:13 ago on Mon 04 Dec 2017 06:03:10 PM CET. Installed Packages Name : efivar Version : 32 Release : 2.fc27 Arch : x86_64 Size : 46 k Source : efivar-32-2.fc27.src.rpm Repo : @System From repo : updates Summary : Tools to manage UEFI variables URL : https://github.com/rhboot/efivar License : LGPLv2.1 Description : efivar provides a simple command line interface to the UEFI : variable facility. [root@encelade RHF27_i686_x86_64_addons]# dnf info dbxtool Failed to synchronize cache for repo 'local', disabling. Last metadata expiration check: 2:37:39 ago on Mon 04 Dec 2017 06:03:10 PM CET. Installed Packages Name : dbxtool Version : 8 Release : 3.fc27 Arch : x86_64 Size : 53 k Source : dbxtool-8-3.fc27.src.rpm Repo : @System From repo : fedora Summary : Secure Boot DBX updater URL : https://github.com/vathpela/dbxtool License : GPLv2 Description : This package contains DBX updates for UEFI Secure Boot. [root@encelade RHF27_i686_x86_64_addons]# ================= This package are quite simple, mainly they provide: efivar-32-2.fc27 --> /usr/bin/efivar dbxtool-8-3.fc27 --> /usr/bin/dbxtool --> /usr/lib/systemd/system/dbxtool.service So most probably the matter is from dbxtool ??? Just after installation: ========= # systemctl status dbxtool.service * dbxtool.service - Secure Boot DBX (blacklist) updater Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; enabled; vendor preset: enabled) Active: inactive (dead) Dec 04 18:56:28 encelade systemd[1]: Started Secure Boot DBX (blacklist) updater. Dec 04 19:08:09 encelade systemd[1]: Stopped Secure Boot DBX (blacklist) updater. # so the service was started once, and stopped apparently without any errors Does this tries, to write something in UEFI eeprom monitor ???? I tried to disable this service: # systemctl disable dbxtool.service Removed /etc/systemd/system/multi-user.target.wants/dbxtool.service. And reboot and nothing change. I had again to boot by navigating in EFI file system from HP UEFI monitor, by default only: DBXUpdate-2016-08-09-13-16-00.bin Anyway this service launched only once at shim-x64 installation, seems only to apply any *.bin file in /usr/share/dbxtool/ And normally when I deinstall shim-x64-13-0.7, to fallback to fedora 26 package, the UEFI database remain the same ?? OR I'm wrong the data base is not the one, in UEFI monitor, but somewhere else in EFI file system, and shim --> grub boot process abort because of this database ?? I CANNOT SOLVE THIS PROBLEM BY MYSELF. we require help from someone understanding well, how boot EFI process use EFI variables !!!!
Hello all, I was able to solve it by using the suggestion from Comment #18. What I did: - wget ftp://mirror.switch.ch/pool/4/mirror/fedora/linux/releases/26/Workstation/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm - rpm -e --justdb --nodeps shim-x64-13-0.7.x86_64 - rpm -ivh shim-0.8-10.x86_64.rpm After a reboot the system started without any problem. Nevertheless I would be interested to know what is the source problem of shim-x64-13-0.7.x86_64. Thank you all for the helpful comments.
Acer Aspire V Nitro, same problem. Adding the grubx64.efi file didn't work, but downgrading to the F26 shim package did.
@josh I have the same laptop (it's my spare and game laptop) : can you post a step by step to downgrade the packet please ?
@David Berlioz - it's pretty simple. Boot to a F27 Live DVD Download the shim RPM from a F26 repository using firefox (or use wget as in comment #34) mount <root partition> /mnt mount </boot partition> /mnt/boot mount </boot/efi partition> /mnt/boot/efi mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys copy the downloaded RPM to /mnt/tmp chroot /mnt yum remove shim-x64 yum install /tmp/shim*.rpm exit reboot THe hardest part is getting the F27 Live DVD burned if you can't boot the machine...
Hello, I ran into the same problem on my Lenovo Thinkpad T430 (Model 2349GCG) after upgrading F26 to F27: > System BootOrder not fond. Initializing defaults. > Creating boot entry "Boot0000" with label Fedora for file "\EFI\fedora\shimx64.efi" > Reset System Did the upgrade to F27 today. Nothing really useful to add for the developer (beside the fact that it is still broken with shim-x64-13-0.7.x86_64 as it is available on 2018-Jan-06). Relevant firmware settings: * "UEFI only" was and still is enabled * "Secure Boot" was and still is disabled Side note: These reboots also filled up the EFI space, therefore I got a warning when entering the Laptop's Firmware Setup: > Error: The non-volatile system UEFI variable storage is nearly full I do not go into details on the latter as the space was cleaned up automatically after having a working setup again. But https://superuser.com/questions/1081537/ might be useful if somebody is not that lucky.
Hello again, First thing I tried: update UEFI (did not solve anything but I wanted to update UEFI anyways because of security fixes). I updated to newest T430 Firmware Release to make sure it is not only caused by outdated firmware: Package (ID) UEFI BIOS (BIOS ID) ECP (ECP ID) Rev. Issue Date ---------------- -------------------- ---------------- ---- ----------- 2.74 (G1UJ41UC) 2.74 (G1ETB4WW) 1.13 (G1HT35WW) 01 2017/09/29 Links for reference: - README for UEFI Firmware Release 2.74: https://download.lenovo.com/pccbbs/mobiles/g1uj41uc.txt - Software Center, UEFI Download T430: https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t430/2349/2349gcg/downloads Workaround (not a fix): I booted F27 netinstall live USB key in rescue mode, removed "shim-x64" and installed the older "shim" package from F26 (as suggested above). I have a cryptsetup/LUKS encrypted system. Creating a chrooted environment from the graphical Live system in combination with DNF is a bit more sophisticated (so not only cryptsetup luksOpen '/dev/sdaX' 'encrypted-sdaX', create mountpoints and chroot into, ...). As I was lazy and my laptop has a working Ethernet Port: Rescue Mode... to the rescue. Using the Fedora Netinstaller on USB key with rescue mode is the easiest way, as it setups the disk properly and enables you to simply install packages on your local disk without hassle. For the record: 1) Created the USB Key with the following command (cf. https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB): su -c 'dd if=/path/to/Fedora-WS27-netinstall.iso of=/dev/sdX bs=8M oflag=direct' 2) Booted USB key -> Troubleshooting -> Rescue a Fedora-System -> Option "1) Continue" 3) chroot /mnt/sysimage [ You are now on the system installed on your machine, not some kind of live media ] 4) dnf remove shim-x64 [ have a glimpse on the dependencies, this might remove e.g. "gnome-software". Just run "dnf install gnome-software" later if needed ] 5) curl -o /tmp/shim-0.8-10.x86_64.rpm -L https://bitly.com/2CJ0ohV [ https://bitly.com/2CJ0ohV points to a free.fr F26 mirror ] sha256sum /tmp/shim-0.8-10.x86_64.rpm b72a623455d513c3f05eb9520a126f9bf8dfce677d8e3710098dd4b7b22ea890 /tmp/shim-0.8-10.x86_64.rpm sha1sum /tmp/shim-0.8-10.x86_64.rpm 6802df2fb75831e0d75d54c4b3b3c4ecf66fc60b /tmp/shim-0.8-10.x86_64.rpm dnf install /tmp/shim-0.8-10.x86_64.rpm [ optional: "dnf install gnome-software" ] rm /tmp/shim-0.8-10.x86_64.rpm exit systemctl reboot The System should come up correctly again. Resetting SELinux context happens on first boot because you bootet up in rescue mode. This takes some time but is not harmful in any way. If you have to adapt the commands above for your setup, the following might be useful: - https://unix.stackexchange.com/questions/267155/ - https://ask.fedoraproject.org/en/question/53127/ - https://ask.fedoraproject.org/en/question/115228/ - https://unix.stackexchange.com/questions/72592/ - https://wiki.sabayon.org/index.php?title=HOWTO:_chroot_from_a_LiveCD - https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_LVM - https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_Encrypted_Partition Regards, Andreas
Big Up @josh worked like a charm Had no pb booting on a live image have a nice usb stick that works good !
Could be convenient to add this in /etc/dnf/dnf.conf exclude=shim-x64
(In reply to Andreas Haerter from comment #39) > Hello again, > > First thing I tried: update UEFI (did not solve anything but I wanted to > update UEFI anyways because of security fixes). I updated to newest T430 > Firmware Release to make sure it is not only caused by outdated firmware: > > Package (ID) UEFI BIOS (BIOS ID) ECP (ECP ID) Rev. Issue > Date > ---------------- -------------------- ---------------- ---- > ----------- > 2.74 (G1UJ41UC) 2.74 (G1ETB4WW) 1.13 (G1HT35WW) 01 > 2017/09/29 > > Links for reference: > - README for UEFI Firmware Release 2.74: > https://download.lenovo.com/pccbbs/mobiles/g1uj41uc.txt > - Software Center, UEFI Download T430: > https://pcsupport.lenovo.com/de/en/products/laptops-and-netbooks/thinkpad-t- > series-laptops/thinkpad-t430/2349/2349gcg/downloads > > > > Workaround (not a fix): I booted F27 netinstall live USB key in rescue mode, > removed "shim-x64" and installed the older "shim" package from F26 (as > suggested above). > > I have a cryptsetup/LUKS encrypted system. Creating a chrooted environment > from the graphical Live system in combination with DNF is a bit more > sophisticated (so not only cryptsetup luksOpen '/dev/sdaX' 'encrypted-sdaX', > create mountpoints and chroot into, ...). As I was lazy and my laptop has a > working Ethernet Port: Rescue Mode... to the rescue. > > Using the Fedora Netinstaller on USB key with rescue mode is the easiest > way, as it setups the disk properly and enables you to simply install > packages on your local disk without hassle. For the record: > > 1) Created the USB Key with the following command (cf. > https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB): > su -c 'dd if=/path/to/Fedora-WS27-netinstall.iso of=/dev/sdX bs=8M > oflag=direct' > > 2) Booted USB key -> Troubleshooting -> Rescue a Fedora-System -> Option "1) > Continue" > > 3) chroot /mnt/sysimage > [ You are now on the system installed on your machine, not some kind of > live media ] > > 4) dnf remove shim-x64 > [ have a glimpse on the dependencies, this might remove e.g. > "gnome-software". > Just run "dnf install gnome-software" later if needed ] > > 5) curl -o /tmp/shim-0.8-10.x86_64.rpm -L https://bitly.com/2CJ0ohV > [ https://bitly.com/2CJ0ohV points to a free.fr F26 mirror ] > sha256sum /tmp/shim-0.8-10.x86_64.rpm > b72a623455d513c3f05eb9520a126f9bf8dfce677d8e3710098dd4b7b22ea890 > /tmp/shim-0.8-10.x86_64.rpm > sha1sum /tmp/shim-0.8-10.x86_64.rpm > 6802df2fb75831e0d75d54c4b3b3c4ecf66fc60b /tmp/shim-0.8-10.x86_64.rpm > dnf install /tmp/shim-0.8-10.x86_64.rpm > [ optional: "dnf install gnome-software" ] > rm /tmp/shim-0.8-10.x86_64.rpm > exit > systemctl reboot > > The System should come up correctly again. Resetting SELinux context happens > on first boot because you bootet up in rescue mode. This takes some time but > is not harmful in any way. > > If you have to adapt the commands above for your setup, the following might > be useful: > - https://unix.stackexchange.com/questions/267155/ > - https://ask.fedoraproject.org/en/question/53127/ > - https://ask.fedoraproject.org/en/question/115228/ > - https://unix.stackexchange.com/questions/72592/ > - https://wiki.sabayon.org/index.php?title=HOWTO:_chroot_from_a_LiveCD > - https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_LVM > - https://wiki.sabayon.org/index.php?title=HOWTO:_Mount_Encrypted_Partition > > > Regards, > Andreas works correctly for me after a clean F26 install (only OS) and upgraded to F27. Same issue with a directly F27 install
I also encountered this problem with my Acer Aspire E 15 notebook. I managed to boot into Fedora 27 without downgrading shim when I followed the instructions from comment #16. Out of curiosity, I also selected the UEFI file shimx64-fedora.efi, which comes with shim-x64-13.0.7, as trusted for executing and was able to boot, too. However, the entry for shimx64.efi still remained the default. Since I could neither delete the entry for shimx64.efi nor change the boot order in efibootmgr (changes were shown in efibootmgr, but didn’t survive reboot), I selected in the UEFI menu Security -> Restore Secure Boot to Factory Default (also requires a supervisor password). This deletes all custom boot menu entries. After a reboot (changes take effect only after reboot), I selected the shimx64-fedora.efi as trusted for executing, which is now my default boot entry so that I needn’t manually select an entry from the boot menu any more. Then I selected shimx64.efi, which had not worked before, as trusted for executing, and it booted successfully. It seems that it is necessary to clear the boot menu (e.g. by restoring the factory defaults) to remove the broken entry for shimx64.efi from the boot menu. However, after factory defaults are restored, all of these UEFI files successfully boot when selected as trusted for executing: * shimx64.efi * shimx64-fedora.efi * grubx64.efi I didn’t try shim.efi, but I would expect that it also works. Interestingly, shim.efi and shimx64.efi from shim-x64-13.0.7 have the same SHA1 sum as shim.efi from shim-0.8-10. Since, according to some comments, the older shim, that has the same content as the new one, seems to work, there must be another difference between these files. This difference is the timestamp: all UEFI files from shim-0.8-10 have a timestamp from 2016-08-15, whereas all UEFI files from shim-x64-13-0.7 have a timestamp from 2017-10-04. Maybe the UEFI checks if the timestamp of a trusted UEFI file has changed, and, if so, does not trust it anymore? If this is the actual problem, a simple "touch -r" should solve it. Can anyone confirm this?
Reading the last question of Daniel Woschée comment 43, I tried the suggestion. So I started first with "touch -r", but the problem was, that to get the reference time stamps, you need to install FC26 shim-0.8-10, and then made a copy with cp -p , in a reference directory outside EFI file system (because when booting, all the EFI file system is explored - we shall see later by WHAT !), ans if you just rename the EFI/BOOT and EFI/fedora directory before installing shim-x64-13.0.7, you get artifact because two shim.EFI are detected !! So I moved this BOOT and fedora directories in a tempo directory in my ext4 main file system, and just checked the time date of all the *.efi file from this backup directory with ls -l. It looked OK, so I removed shim-0.8-10, and then installed shim-x64-13.0.7 with dnf, so its dependencies are installed too. In my case : dbxtool, and efivars My reference file was copied under : UTILS0=/utils/RHF27_i686_x86_64_addons/EFI/fedora So I defined this export REF0=$UTILS0/shim.efi AND made the change on Fedora 27 files: # cd /boot/efi/EFI/ # touch -r $REF0 BOOT/* # cd fedora # touch -r $REF0 BOOT.CSV* MokManager.efi shim.efi shim-fedora.efi AND tried to boot as is! I was not working ! ========= So reinstalled shim-0.8-10, And chek deeper the time stamps: # stat /boot/efi/EFI/fedora/shim.efi File: /boot/efi/EFI/fedora/shim.efi Size: 1293304 Blocks: 2528 IO Block: 8192 regular file Device: 801h/2049d Inode: 1533 Links: 1 Access: (0700/-rwx------) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:dosfs_t:s0 Access: 2016-08-15 18:31:50.000000000 +0200 Modify: 2016-08-15 18:31:50.000000000 +0200 Change: 2018-02-27 21:19:48.000000000 +0100 Birth: - Unfortunately , the backup reference in $UTILS0 whith cp -r, or cpio -pumd, does not get the same Access time, and even if you change the time stamps of the backup reference file, whith # export REF0=/boot/efi/EFI/fedora/shim.efi and you applies # touch -r $REF0 ... to all file in $UTILS0 and $UTILS0/../BOOT As soon as you have rebooted, the supposed backup reference file have their Acces time stamp modified (only Modified time stamps remain at 2016-08-15 18:31:50.) So at the end I used this script (/root/bin/reset_efi_timestamp): ========== REF_TS="201608151831.50" for F in \ /boot/efi/EFI/BOOT/BOOTX64.EFI \ /boot/efi/EFI/BOOT/fallback.efi \ /boot/efi/EFI/fedora/BOOT.CSV \ /boot/efi/EFI/fedora/MokManager.efi \ /boot/efi/EFI/fedora/shim.efi \ /boot/efi/EFI/fedora/shim64.efi \ /boot/efi/EFI/fedora/shim-fedora.efi do if [ -f $F ] then echo "adjust time stamp on:" echo "$F" touch -t 201608151831.50 "$F" stat "$F" | egrep 'File:|Access:|Modify:' fi done =================== to quicly reset the time stamps once shim-x64-13.0.7 and it dependence were installed. and then NO SUCCES at boot on my HP EliteBook 8740W I even try after this install, to remove only shim-x64-13.0.7 with rpm -i (because dnf remove, remove also its dependencies), and then reinstall only shim-0.8-10.x86_64.rpm, with dbxtool, and efivars always installed, show a successful EFI boot!!! ========== So now I decided to go on further experimentation to understand how my HP EliteBook 8740W boot in UEFI mode in comparison with my Lenovo ThinkCenter M700. The last one is booting perfectly, after an upgrade from Fedora 25 to Fedora 27 so with shim-x64-13.0.7 and its dependency installed. I explain all that in my next comment, and all the tests that helped me to understand which code is wrong for old PC related here by people in some bad experience , while was working fine until Fedora 26 included !
So I checked the history on my HP elitebook from the beginning: What I supposed to be an UEFI secure boot was actually NOT ! I just supposed that because each time I booted my PC, I could see a message like: System Boot Order not Found, Initailizing default Creating boot entry "Boot00<xx>" with label "Fedora" for file ... (its difficult to read, so short is the show of this message: < 1s, so I made a video of my screen during booting, and passed it in VLC in slow motion!) And after the grubs menu appears. NOTICE that I modified the EFI/fedora/grub.cfg ======= if loadfont $font ; then ... insmod png insmod gettext set gfxmode=1024x768x32,auto insmod gfxterm terminal_output gfxterm else ... fi ... ( and some lines below) if background_image /EFI/fedora/FED24STARBG-1024x768.png ; then #set color_normal=black/black #set color_highlight=magenta/black set color_normal=cyan/black #set color_highlight=magenta/black set color_highlight=yellow/black else set color_normal=cyan/blue set color_highlight=white/blue fi set timeout=-1 ================ So that my grub choice is over a colored backgound. ( this required to have some grub module inside EFI partition, in particular png, because ext2 module is loaded too late, and the EFI first stage loader is not able to search them in Linux ext2/3/4 file system: I made a complete copy of all *.mod in EFI/fedora/x86_64-efi , from package: grub2-efi-x64-modules: /usr/lib/grub/x86_64-efi/) THIS POINT IS NOT A DETAIL, because with this set in place, I discovered with the experiments detailed below that you know immediately if you boot in secure mode or not! On my both PC I get this specific grub.cfg options installed! On My Lenovo, I discovered that if I boot in secure mode, the background image is not shown!! And later the NVIDIA proprietary modules is NOT loaded because NOT SIGNED !!!!(while of course in not UEFI secure mode, grubmenu background si visible, and later NVIDIA module is loaded !!) I never get this on my HP (also with a Nvidia Graphic chip) So I checked MY UEFI MOnitor carefully. Details in next comment
I always configured my HP UEFI monitor, to show the UEFI boot menu choice at least 10 s and the boot order is: 1) NOTEBOOK Upgrade Bay (UEFI) 2) OS BOOT MAnager 3) Boot from EFI file ... I never use the other ones NOTEBOOK Ugrade Bay Notebook Hard drive Notebbok ethernet because they are not for UEFI booting ============= So by default 1) is used, and conducts to boot until Linux grub menu except when you encounter the problem of this bugzilla report 2) boot windows via secure loader bootmgfw.efi (at the end maybe it's not secure as in Linux booting as explaine below !!!) 3) allow too boot via any valid *.efi loader found in EFI file system ( in my case allow for example to boot via shim.efi or grub.efi found in EFI/fedora) ***** So concentrate on the first case: I do nothing and I let the PC boot freely: with shim-0.8-10, It boots: =========================== Each time with the message: System Boot Order not Found, Initailizing default Creating boot entry "Boot00<xx>" with label "Fedora" for file ... And after the grubs menu appears. Once booted: efibootmgr show something like : [root@encelade RHF27_i686_x86_64_addons]# efibootmgr BootCurrent: 0000 Timeout: 10 seconds BootOrder: 0004,0000,0001,0002 Boot0000* Notebook Upgrade Bay Boot0001* Notebook Hard Drive Boot0002* Notebook Ethernet Boot0003* SD Card Boot0004* Fedora Boot0005* Fedora Boot0031* Windows Boot Manager ++++++++++ and with efibootmgr -v, we see details likes Boot0004* Fedora HD(1,GPT,36037381-f9d1-11ce-b1ed-f52e2f70cddf,0x800,0xff801)/File(\EFI\fedora\shim.efi) Boot0005* Fedora HD(1,GPT,36037381-f9d1-11ce-b1ed-f52e2f70cddf,0x800,0xff801)/File(\EFI\fedora\shim.efi) That why I supposed that the system booted in secure mode ! But its not the case. An entry is added by the program shim.efi , but it seams that BootOrder is not stored anywhere in the UEFI EEPROM. That's the point on this "old" PC, with not a fully implemented UEFI functionality. So I removed the file shim*.efi from EFI/fedora, when shim-0.8-10 was installed, and my PC continued to boot in the same way !!!!! I removed EFI/BOOT/BOOTX64.EFI,and then : -> no more message: System Boot Order not Found, Initailizing default Creating boot entry "Boot00<xx>" with label "Fedora" for file ... Appears , that's the proof that this messages is managed by shim.efi or BOOTX64.efi (the same code), and NOT by UEFI monitor !! -> And the PC boot directly under WINDOWS (so via the entry 2 of the UEFI boot order) AND NOW with the standard Fedora 27 shim-x64-13-0.7 package =========================================================== With no modification I got: System Boot Order not Found, Initailizing default Creating boot entry "Boot00<xx>" with label "Fedora" for file ... System Reset AND GO BACK to UEFI MONITOR, in and endless loop, adding one entry in UEFI table monitor, until the EEPROM is saturated from Boot0000* to Boot002F*. So the logic is: the same code : EFI/fedora/shim.efi or EFI/BOOT/BOOTX64.efi does follow different successive steps (remember on HP 8740W booting via shim.efi is only possible by browsing EFI partition) In fact booting manually by shim.efi, shim-fedora.efi, or grubx64.efi get the same result; give grubmenu on my colored background, and then boot linux kernel Secure boot is ignored, probably because reduced UEFI monitor does not give to shim.efi/ the parameters required !!! Ok , so now I'm conviced by this test that by default HP elitebook 8740, I removed the programm supposed to be executed when secureboot with BOOTX64.EFI cannot perform a secure boot: >>>>>>>>>>>>>> fallback.efi <<<<<<<<<<<<<<<<<<<<<<< THAT THE POISONOUS FILE !!! If you replace it by the one from , you have copied from a shim-0.8-10 package, the system does not reboot, by stays ONE MINUTE showing this: (no movie required to got it !!!!) System Boot Order not Found, Initializing default Creating boot entry "Boot00<xx>" with label "Fedora" for file "EFI\fedora\shimia32.efi" Load Image failed : 14 Device Path; "PciRoot(0) ..(I do not copy this long path)...\EFI\fedora\shimia32.efi" + hexa boot code 8 lines x 16 columns of bytes !!!!! AFTER ONE MINUTE OF PAUSE, the system go back to UEFI monitor, ans so on in an endless loop !!!! =================== Where does this info "EFI\fedora\shimia32.efi" come from ? FROM EFI/fedora/BOOT.CSV On my system, once the 2 bad file are corrected: [root@encelade BOOT]# pwd /boot/efi/EFI/BOOT [root@encelade BOOT]# ls -l ../fedora/BOOT.CSV* -rwx------. 1 root root 104 Feb 28 00:19 ../fedora/BOOT.CSV -rwx------. 1 root root 104 Dec 4 22:14 ../fedora/BOOT.CSV.0.8-10 -rwx------. 1 root root 112 Oct 4 17:39 ../fedora/BOOT.CSV.13-0.7 So a keep a copy from the both package: shim-0.8, and shim-x64-13-0.7 [root@encelade BOOT]# cat ../fedora/BOOT.CSV.13-0.7 ��shimia32.efi,Fedora,,This is the boot entry for Fedora [root@encelade BOOT]# cat ../fedora/BOOT.CSV.0.8-10 ��shim.efi,Fedora,,This is the boot entry for Fedora It's obvious that shimia32.efi has nothing to do in our x86 architecture . If I correct just ONLY BOOT.CSV, its does not boot (but endless loop again) so AGAIN >>>>>>>> fallback.efi <<<<<<< is the week point. AFTER A CLEAN INSTALLATION of shim-x64, with dnf only replacing this file with the one from shim-0.8-10 AND BOOT.CSV from shim-0.8-10 all is going fine with the HP old implemented UEFI monitor ========= In summary in Fedora 27, shim-x64 , does not provide a good alternate booting mode when all other have failed !!!! I ask now to the developer and packager of these shim packages: COULD THIS BE CORRECTED ???
just a mistake writen in my comment 45. ext2 module is not loaded toot late. The fact is that any shim.efi have basic module embedded (ext2, font) but not png. That's why you must provide this from an external file . BUT Is secure boot, only shim.efi is loaded, because this is the only file signed by a private key from Microsoft. A full UEFI monitor can check validity of shim.efi signature , because it has a certificate with corresponding Microsoft public key. So I suppose that when UEFI mon has checked this successfully, it give this information to shim.efi executed program, which continue its secure boot process. Shim.efi in this case cannot call outside program (like png.module, not signed by microsoft !) otherwise, the security boot process could be compromised by this "little" code !!! THAT'S WHY YOU HAVE NOT COLORED BACKGROUND in secure boot !!! (at least if you provide it in PNG format: I did not found information about any emmbedded image format module in shim.efi ! Then with the Redhat publickey , embedded in shim.efi (or BOOTX64.EFI: the same code) (embedded before signon by Microsoft of course), shim.efi read the grub module signed by a redhat private key, and if checked successfully, inform grub that it has been loaded and verified successfully , and give it the redhat certificate with public key, embedded in shim.efi . grub loader, read the simple text grub.cfg, where no malicious code can be hidden, and load after checking the signature , the only file signed, and recognised as such by re-computing with the public key provided by shim.efi: mainly: linuxefi -> /boot/vmlinuz-.... initrdefi -> /boot/initramfs The kernel is also informed by grub that it's signature was checked , and now linux kernel cannot accept to load module not signed ! THAT'S WHY YOU HAVE NO PROPRIETARY kernel module loaded in this situation, because they are not signed at compiling time because, they have closed source code embedded! ========== So secure boot is NOT just for fun ! But as important as SELinux for the application and libs.
Hello, Just for the record: Problem does NOT occur on a Lenovo Thinkpad T460S UEFI Boot environment (Version N1CET63W 1.31 2017-12-19, Secure Boot disabled). Everything works as expected. So old Thinkpad T430S UEFI boot is affected, newer models obviously might work.
(In reply to josh from comment #37) > @David Berlioz - it's pretty simple. > > Boot to a F27 Live DVD > Download the shim RPM from a F26 repository using firefox (or use wget as in > comment #34) > mount <root partition> /mnt > mount </boot partition> /mnt/boot > mount </boot/efi partition> /mnt/boot/efi > mount --bind /dev /mnt/dev > mount --bind /proc /mnt/proc > mount --bind /sys /mnt/sys > copy the downloaded RPM to /mnt/tmp > chroot /mnt > yum remove shim-x64 > yum install /tmp/shim*.rpm > exit > reboot > > THe hardest part is getting the F27 Live DVD burned if you can't boot the > machine... Hello How do I find the name of the /boot partition? My 'parted -l' says: Disco /dev/sda: 512GB Dimensione del settore (logica/fisica): 512B/4096B Tabella delle partizioni: gpt Flag del disco: Numero Inizio Fine Dimensione File system Nome Flag 1 1049kB 274MB 273MB fat32 EFI System Partition avvio, esp 2 274MB 290MB 16,8MB Microsoft reserved partition msftres 3 290MB 81,7GB 81,4GB ntfs Basic data partition msftdata 6 81,7GB 82,7GB 1074MB ext4 8 82,7GB 83,8GB 1074MB ext4 9 83,8GB 204GB 121GB lvm 4 204GB 205GB 523MB ntfs Basic data partition nascosta, diag 5 205GB 266GB 61,6GB ntfs Basic data partition msftdata 7 266GB 512GB 246GB lvm So, I assume my /boot/efi is /dev/sda1. /dev/sda2 is perhaps noacuse it says microsoft? Could /boot be one of 6 or 8?
Lenovo x240, BIOS 2.42, secure boot disabled, the same problem encountered after upgrade to f27. I resolved it by going into BIOS settings, disabling "Boot Order Lock", rebooted, machine reseted boot order and automatically rebooted, went into BIOS, reenabled "Boot Order Lock" and now everything is OK.
(In reply to Jaroslav Škarvada from comment #50) > Lenovo x240, BIOS 2.42, secure boot disabled, the same problem encountered > after upgrade to f27. > > I resolved it by going into BIOS settings, disabling "Boot Order Lock", > rebooted, machine reseted boot order and automatically rebooted, went into > BIOS, reenabled "Boot Order Lock" and now everything is OK. Thank you for your solution! I had the same problem with my Lenovo X260, your solution did the trick.
Similar problem here with Fedora 27 and 28 on a Sony Vaio Pro, which has a restricted BIOS so that the various workarounds involving BIOS settings cannot be used. However, the system does boot, but the message in attachment 1 [details] does flash up briefly, without the Reset System line. I checked with a couple of other distributions and the machine boots cleanly on those. Tried the solution in comment #37 https://bugzilla.redhat.com/show_bug.cgi?id=1512410#c37 but this didn't work.
(In reply to lothar.teworte from comment #53) > Similar problem here with Fedora 27 and 28 on a Sony Vaio Pro, which has a > restricted BIOS so that the various workarounds involving BIOS settings > cannot be used. > > However, the system does boot, but the message in attachment 1 [details] > does flash up briefly, without the Reset System line. > > I checked with a couple of other distributions and the machine boots cleanly > on those. > > Tried the solution in comment #37 > https://bugzilla.redhat.com/show_bug.cgi?id=1512410#c37 but this didn't work. Hi Lothar, I also have the issue on a Sony Vaio Pro and used a workaround that didn't involve bios settings. See my Comments 7, 8 and 10 earlier in this thread. Hope it works for you too. In case you don't have an EFI directory lying around like described, you can make a livemedia with an older Fedora version (e.g. 26) to obtain them. Cheers, Fjalar
Well, I upgraded to fc28 and this issue is still there. But my workaround still works. Remove shim-x64 and install the shim-x64 from fc26. wget https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/26/Workstation/x86_64/os/Packages/s/shim-0.8-10.x86_64.rpm
This problem appears after I upgrade to FC29. My God.
Indeed !! An now the solution of shim from Fedora 26 is NO MORE a bug turn around. The problem is new: no more endlessloop, BUT With shim-x64-15-2 from Fedora 29 or shim-0.8 from Fedora 26 the fallback initial programm , respectively EFI/BOOT/fbx64.efi for the first package, and EFI/BOOT/fallback.efi for the second Show the grub menu from EFI/fedora/grub.cfg So fallback chains normally to grubloader first stage, but whatever Linux entry of my multiboot PC I choose, I get a grub error: - - - - - - - error ../../grub-core/kern/dl.c:431:symbol 'grub_efi_allocate_pages' not found. press any key to continue - - - - - - Only the chain entry toward windows is working So is it a shim bug ??? or a grub bug ???
Ok, this problem is also signalled in bug: 1643802 https://bugzilla.redhat.com/show_bug.cgi?id=1643802
my Comment 57 is not complete: ============================= If fact there is always endless loop by default,when shimx64.efi is not usable because an incomplete implementation of standard UEFI , in a poor an early UEFI monitor. And the responsible of this loop is the BAD EFI/BOOT/fbx64.efi, till NOT corrected from the beginning of Fedora 27. But you can chain normally to grubmenu, if you are using EFI/fedora/grubx64.efi, choosing it manually by navigating in EFI fat system tree from your UEFI monitor! To avoid this manual choice , and get an automatic boot a short bug turn around : ========================= is to make a copy of EFI/fedora/grubx64.efi in EFI/BOOT/BOOTX64.EFI and then AT least you chain to grub menu choice ! **AND there you got the problem signalled in bug: 1643802 (link in comment 58 above)** See the solution in my comment on this link NOTE ==== On HP Elitebook 8740W, installing or upgrading to Fedora 29, give an endless loop, whith standard boot, either from -> UEFI boot entrie stored in monitor flash EEPROM standard one (listed with "efibootmgr -v ", once booted in UEFI mode) are something like Boot0004* fedora HD(1,gpt,< GPT PARTUUID of UFI part.>,0x800, 0xff801)/File(\EFI\fedora\shimx64.efi) or from -> the fallback programm when this one has failed: EFI/BOOT/BOOTX64.EFI This last one, insert a new entry in UEFI monitor flash EEPROM, with the programm pointed by EFI/fedora/GRUBX64.CSV (shimx64.efi par défaut), supposed to be a good one for the next reboot, and then give hands to fbx64.efi, and loops. I have tried to point on grubx64.efi, in EFI/fedora/GRUBX64.CSV: then you can see that EFI/BOOT/BOOTX64.EFI has inserted this new PATH in new entry created. But because the buggy implementation of HP Elitebook UEFI monitor, the next boot this entry is not sucessfully used, and the monitor chains again on EFI/BOOT/BOOTX64.EFI ... and ... the endless loop.
Hello, I just wanted to say that the problem did not appear when upgrading from Fedora 27 to 28 and 29 on the same mentioned T430, even when I used the correct shim-x64 package as designed. So at least for me, the problem vanished. However, I took comment #50 and comment #51 as inspiration and disabled the boot order lock in the BIOS settings upfront. Maybe this did the trick. Regards, Andreas
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. 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 '28'. 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 28 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 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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.