Description of problem: On a Laptop "Acer Aspire E15 E5-571G", preinstalled Win 8.1, it is only possible to boot F21 Workstation Beta TC4 x86_64 in UEFI mode, Secure Boot, by putting Grub into the UEFI Whitelist. F21 is installed on an external disk. Currently Grub is in the Whitelist. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1.install F21 via LiveCD on an external disk (i.e. disable secure boot, to stay in UEFI mode for installation) 2. Look into the Boot menue of the Bios, to see, whether the external boot media is seen by the Bios. 3. Start boot from the external media Actual results: error message, then PC is halted Expected results: Successful boot of F21 Additional info:
Created attachment 949071 [details] db-d719b2cb-3d3a-4596-a3bc-dad00e67656f As requested by Peter Jones in the testlist thread "Windows 8.1 and F21, BIOS in UEFI Mode" Any chance you can put a copy of /sys/firmware/efi/efivars/db-d719b2cb-3d3a-4596-a3bc-dad00e67656f someplace we can see it? (in a bugzilla report would be fine.)
Okay, I don't see any obvious reason this shouldn't work. There are 5 trusted certificates here, including the correct microsoft and UEFI CA certs, one cert from Acer (with "unique" guid 55555555-5555-5555-5555-555555555555, good job Acer!), and two self signed certificates with CN=DisablePW and CN=ABO, and then there are two whitelisted hashes (which I assume you added through the firmware interface.) As far as I can see, shim.efi should be whitelisted by the 3rd certificate in the list.
Does the install media fail to boot if secure boot is enabled, or is it just the installed system? Can you attach the output from efibootmgr -v ?
Did you actually try booting shim.efi (as opposed to grubx64.efi), or did some error occur that stopped you from doing that?
log of efibootmgr -v, as the system is (configuration as I filed this bug) If this log is not that, what You wanted, please tell: [joerg@localhost ~]$ su Passwort: [root@localhost joerg]# efibootmgr -v BootCurrent: 0003 Timeout: 0 seconds BootOrder: 0004,2001,0000,2002,2003 *** Error in `efibootmgr': double free or corruption (out): 0x00007fffa2df2790 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x7850e)[0x7f55afe5450e] /lib64/libc.so.6(cfree+0x5b5)[0x7f55afe60165] efibootmgr[0x4076d6] efibootmgr[0x402e67] /lib64/libc.so.6(__libc_start_main+0xf0)[0x7f55afdfbfe0] efibootmgr[0x4032c5] ======= Memory map: ======== 00400000-0040b000 r-xp 00000000 fd:00 2499987 /usr/sbin/efibootmgr 0060a000-0060b000 r--p 0000a000 fd:00 2499987 /usr/sbin/efibootmgr 0060b000-0060c000 rw-p 0000b000 fd:00 2499987 /usr/sbin/efibootmgr 02473000-0249c000 rw-p 00000000 00:00 0 [heap] 7f55af7a7000-7f55af7bd000 r-xp 00000000 fd:00 2498813 /usr/lib64/libgcc_s-4.9.1-20140930.so.1 7f55af7bd000-7f55af9bc000 ---p 00016000 fd:00 2498813 /usr/lib64/libgcc_s-4.9.1-20140930.so.1 7f55af9bc000-7f55af9bd000 r--p 00015000 fd:00 2498813 /usr/lib64/libgcc_s-4.9.1-20140930.so.1 7f55af9bd000-7f55af9be000 rw-p 00016000 fd:00 2498813 /usr/lib64/libgcc_s-4.9.1-20140930.so.1 7f55af9be000-7f55af9c1000 r-xp 00000000 fd:00 2498711 /usr/lib64/libdl-2.20.so 7f55af9c1000-7f55afbc0000 ---p 00003000 fd:00 2498711 /usr/lib64/libdl-2.20.so 7f55afbc0000-7f55afbc1000 r--p 00002000 fd:00 2498711 /usr/lib64/libdl-2.20.so 7f55afbc1000-7f55afbc2000 rw-p 00003000 fd:00 2498711 /usr/lib64/libdl-2.20.so 7f55afbc2000-7f55afbd9000 r-xp 00000000 fd:00 2499263 /usr/lib64/libresolv-2.20.so 7f55afbd9000-7f55afdd8000 ---p 00017000 fd:00 2499263 /usr/lib64/libresolv-2.20.so 7f55afdd8000-7f55afdd9000 r--p 00016000 fd:00 2499263 /usr/lib64/libresolv-2.20.so 7f55afdd9000-7f55afdda000 rw-p 00017000 fd:00 2499263 /usr/lib64/libresolv-2.20.so 7f55afdda000-7f55afddc000 rw-p 00000000 00:00 0 7f55afddc000-7f55aff90000 r-xp 00000000 fd:00 2498624 /usr/lib64/libc-2.20.so 7f55aff90000-7f55b018f000 ---p 001b4000 fd:00 2498624 /usr/lib64/libc-2.20.so 7f55b018f000-7f55b0193000 r--p 001b3000 fd:00 2498624 /usr/lib64/libc-2.20.so 7f55b0193000-7f55b0195000 rw-p 001b7000 fd:00 2498624 /usr/lib64/libc-2.20.so 7f55b0195000-7f55b0199000 rw-p 00000000 00:00 0 7f55b0199000-7f55b01a0000 r-xp 00000000 fd:00 2498739 /usr/lib64/libefivar.so.0 7f55b01a0000-7f55b039f000 ---p 00007000 fd:00 2498739 /usr/lib64/libefivar.so.0 7f55b039f000-7f55b03a0000 r--p 00006000 fd:00 2498739 /usr/lib64/libefivar.so.0 7f55b03a0000-7f55b03a6000 rw-p 00007000 fd:00 2498739 /usr/lib64/libefivar.so.0 7f55b03a6000-7f55b03bb000 r-xp 00000000 fd:00 2499554 /usr/lib64/libz.so.1.2.8 7f55b03bb000-7f55b05ba000 ---p 00015000 fd:00 2499554 /usr/lib64/libz.so.1.2.8 7f55b05ba000-7f55b05bb000 r--p 00014000 fd:00 2499554 /usr/lib64/libz.so.1.2.8 7f55b05bb000-7f55b05bc000 rw-p 00015000 fd:00 2499554 /usr/lib64/libz.so.1.2.8 7f55b05bc000-7f55b05c7000 r-xp 00000000 fd:00 2499187 /usr/lib64/libpci.so.3.2.1 7f55b05c7000-7f55b07c7000 ---p 0000b000 fd:00 2499187 /usr/lib64/libpci.so.3.2.1 7f55b07c7000-7f55b07c8000 r--p 0000b000 fd:00 2499187 /usr/lib64/libpci.so.3.2.1 7f55b07c8000-7f55b07c9000 rw-p 0000c000 fd:00 2499187 /usr/lib64/libpci.so.3.2.1 7f55b07c9000-7f55b07ea000 r-xp 00000000 fd:00 2498477 /usr/lib64/ld-2.20.so 7f55b09c8000-7f55b09cd000 rw-p 00000000 00:00 0 7f55b09e7000-7f55b09ea000 rw-p 00000000 00:00 0 7f55b09ea000-7f55b09eb000 r--p 00021000 fd:00 2498477 /usr/lib64/ld-2.20.so 7f55b09eb000-7f55b09ec000 rw-p 00022000 fd:00 2498477 /usr/lib64/ld-2.20.so 7f55b09ec000-7f55b09ed000 rw-p 00000000 00:00 0 7fffa2dd3000-7fffa2df4000 rw-p 00000000 00:00 0 [stack] 7fffa2dfc000-7fffa2dfe000 r--p 00000000 00:00 0 [vvar] 7fffa2dfe000-7fffa2e00000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Boot0000* Windows Boot ManagerAbgebrochen (Speicherabzug geschrieben) [root@localhost joerg]#
I made the following tests: 1. erase all secure boot setting -> only Win 8.1 boots -> try to boot F21: - Grub boot menue - then: Bootloader has not verified image. System is compromosed.Haltet 2. added shim.efi ... same bad result for F21 3. added shim-fedora.efi too .... same bad result for F21 4. added grubx64.efi too .... boot F21 ok
Are you able to boot the F21 install media without whitelisting grubx64.efi?
LiveCDs are bootable with WIN 8.1, secure boot. USB Media are bootable -so far as I tried- produced with Fedora LiveUSB Creator run with WIN 8.1, secure boot, but not bootable in UEFI, when produced in Legacy Mode (F21) with Fedora LiveUSB Creator. In both cases there was no whitelisting.
Ok so shim is fine - the problem is that you've ended up with a boot entry pointing at grub, not at shim. There's clearly something wrong here, since your boot variables are weird enough to confuse efibootmgr. Reassigning there.
I think the version of efibootmgr in updates-testing should actually fix the traceback. Based on your comments, it sounds like the install media is working as expected, and so shim is working, but your firmware is doing something strange with the boot variables once installed? shim in the installed system is the same as on the boot media, so if the firmware allows one but not the other, that's a firmware problem.
I will wait for Beta TC5/6 and the final release, and see what happens. For my use there is no problem - by "whitelisting" I can boot F21 in secure boot mode. In addition I can ask the Acer support.
The Fedora installer sets up an EFI entry that points to shim.efi. However, if that entry doesn't stick for whatever reason (maybe because it's pointing to a removable device), then EFI finds the default EFI/BOOT/BOOTX64.EFI instead. This points directly at grubx64.efi not shim. Is there something different between the grubx64.efi on the installer vs. the one on the installed system? Is there some tool to check the signature on the files?
I dont'know, if this is of interest: I deleted again all boot entries, and set secure boot to factory default. Then but only for one time I saw as boot device for USB-FDD "Fedora", in this case F21 bootet without "whitelisting". But next time there was again as boot device for USB-FDD Samsung.... and there came again the error message. Can it be a hardware problem in the direction of the USB adapter? A "misunderstanding" between Bios and adapter?
Sorry the behaviour in the last comment described (USB-FDD "fedora") happens only, when I delete all boot entries in the security branch (i.e grubx64.efi), then directly boot F21 and afterwards shutdown with restart, then I can reproduce this, and I can continue with "shutdown with restart", F21 always boots untill the next total shutdown. This means: When there is in the Bios shown as boot device: "USB-FDD fedora" F21 boots In case.........................................."USB-FDD Samsung..." there is no boot, but the error message. I hope I have described this understandable.
Because of this boot problem, I have called ACER support. They told me, they have tested only Win 7, 8, 8.1 compatibility, they don't or didn't test with Linux. If this problem is really in the ACER firmware of this laptop, I will nevertheless send them the link of this bug and ask them per mail.
Yes, that was what I was describing. Although I'm not clear what you mean by "directly boot F21". I thought you weren't able to boot it. Does it work if you boot the bad entry to the grub menu, then reboot the laptop? Does the Fedora entry show up then?
- UEFI is whitelisted - start the PC, enter BIOS (in my case F2) - Security Menue, delete all UEFI entries (deletes all Linux entries except Win 8.1), then set to factory default in the same menue - let the boot process go on - F21 boots still correctly - shutdown with restart option - PC restarts, boot F21 is ok again, this I can repeat as often as I want - when I enter Bios while restarting, I see in addition to USB HDD Boot, a Fedora boot possibility, which is in the first position as boot option and boots successfully and is called "Fedora" - after shutdown of PC without restart, and F21 does not boot again, and there comes the error message, which I described. In my opinion restarting is so quick, that some capacities in the "bios chip" might be not totally deloaded. But that's only an idea.
On my mail to Acer Support with reference to this bug I got an bios update. Previously V1.01 now V1.09. With this Bios Version still a whitelist entry is needed, i.e. shim.efi. I can boot now with shim.efi. Without whitelist no F21 boot possible. Current F21 Workstation Beta RC1.
(In reply to Samuel Sieb from comment #12) > The Fedora installer sets up an EFI entry that points to shim.efi. However, > if that entry doesn't stick for whatever reason (maybe because it's pointing > to a removable device), then EFI finds the default EFI/BOOT/BOOTX64.EFI > instead. This points directly at grubx64.efi not shim. This isn't correct - when shim is invoked as \EFI\BOOT\BOOTX64.EFI , it executes fallback.efi from the same directory. fallback.efi traverses all the subdirectories in its ..\ that aren't named "BOOT", and in each of them looks for a file named BOOT.CSV (this is a UCS-2 encoded file). That file, in turn, describes what to add to the boot order. In our case it finds the one in \EFI\fedora, which says: shim.efi,Fedora,,This is the boot entry for Fedora and shim creates an entry for \EFI\fedora\shim.efi with the label "Fedora". > Is there something > different between the grubx64.efi on the installer vs. the one on the > installed system? Is there some tool to check the signature on the files? They differ in what grub's $prefix variable is set to ("/EFI/fedora" on grubx64.efi vs "/EFI/BOOT" in gcdx64.efi, which is copied into the boot image as grubx64.efi), but otherwise they're identical builds, and they're both signed by the same signing key. "pesign -i <file> -l" will show signatures on a binary.
Have to add for readers as unexperienced in bios problems as I am. After Bios update to V1.09 and resetting bios (in my case F9), and then deleting the whitelist, I can boot F21 on this Acer Aspire E15 without whitelist.
(In reply to Peter Jones from comment #19) > This isn't correct - when shim is invoked as \EFI\BOOT\BOOTX64.EFI , it > executes fallback.efi from the same directory. fallback.efi traverses all > the subdirectories in its ..\ that aren't named "BOOT", and in each of them > looks for a file named BOOT.CSV (this is a UCS-2 encoded file). That file, > in turn, describes what to add to the boot order. In our case it finds the > one in \EFI\fedora, which says: > > shim.efi,Fedora,,This is the boot entry for Fedora > > and shim creates an entry for \EFI\fedora\shim.efi with the label "Fedora". > Ok, but there is some difference. I'll have to check it on one of the laptops. On an installed system, the "Fedora" entry works, but the "boot whatever is on this drive" entry dies with secure boot errors. However, booting the installer from a flash drive works fine.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. 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 '21'. 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 21 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 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.