Description of problem: after updating shim to 0.5-1.fc20.x86_64, system boots only to black screen with cursor. Version-Release number of selected component (if applicable): 0.5-1 How reproducible: every time Steps to Reproduce: 1. upgrade to shim 0.5-1 2. reboot Actual results: system hangs on black screen. holding option key allows you to boot from Fedora by selecting it manually. Expected results: system boots without loading rescue menu Additional info: system info: MacBookPro9,2 (PN: Mac-6F01561E16C75D06) pulled this out of dmidecode, not sure if it's helpful: String 1: Apple ROM Version. BIOS ID: MBP91. Built by: root@sa String 2: umon. Date: Wed Aug 8 11:32:13 PDT 2012. Revision: String 3: svn 27462 (B&I). Buildcave ID: 1105. ROM Version: 00D3_B0 i see one other user also reported an issue in pkgdb, not sure if they're using a Mac system as well... if further information is needed for debugging, please provide instructions and i will gladly do so.
Hit the same after updating to 0.5.1 on thinkpad so this is not limited to macs
Thinkpad T420
*** Bug 1023780 has been marked as a duplicate of this bug. ***
As mentioned in bug 1023780, a USB stick dd'd with either desktop or DVD ISO boots fine. But fails when produced with livecd-iso-to-disk. Fails on all the EFI Macs I have here.
well all the tc's have the 0.4 release and I'm forced to rescue boot the tc5 I got here as well as mount && downgrade shim to the 0.4 release to get a bootable system again.
TC6 has shim/shim-signed 0.5-1.
(In reply to Chris Murphy from comment #6) > TC6 has shim/shim-signed 0.5-1. Which means that someone just misused their power and sidestep the procedures we have in QA and it's going to be interesting to find out which individual decided to side step our procedures which we have in place for a reason.
I have zero interest in being CC:ed on bugs in which volunteers display this attitude towards other volunteers. I'll coordinate directly with Peter on ensuring that this is fixed.
whether there was a procedural issue or not (i don't know policy on this kind of thing), this is still an update to the testing repository of a release that's in alpha, so 'fails to boot' is not all that surprising. i ain't even mad, bro! just versionlock shim, mokutil, and shim{-signed,-unsigned} and carry on. for matthew/peter: whether you prefer not to communicate through the bug, the offer to assist with further troubleshooting remains open; feel free to email direct if better debug info is needed or there's trouble replicating. cheers.
(In reply to Matthew Garrett from comment #8) > I have zero interest in being CC:ed on bugs in which volunteers display this > attitude towards other volunteers. I'll coordinate directly with Peter on > ensuring that this is fixed. And we in QA have zero interest when we spent countless of hours going through bugs on meetings pinging maintainers approve freeze exception at the request of an maintainer [1] when suddenly it's discovered that the entire blocker bug process has been side step [²]. And we discover things being pulled in behind our back in a release that got released 2 days before the approval of said freeze exception. "Discussed in 2013-10-28 Blocker Review meeting [1]. Voted as an AcceptedFreezeException. This is required for secureboot to work and cannot be fixed with an update post-release. A tested fix would be considered after freeze." The individual that is responsibility for this can make his case to the QA community to drop the entire blocker bug process since he's so inclined to sidestep it. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1010474#c3 2. https://bugzilla.redhat.com/show_bug.cgi?id=1010474#c5 3. https://bugzilla.redhat.com/show_bug.cgi?id=1023767#c6 4. https://lists.fedoraproject.org/pipermail/test-announce/2013-October/000794.html
Dd'd Beta TC6 (both DVD and live) doesn't boot either. I tried them on Mac and one EFI machine. I've only got black screen (with small white cursor in the corner).
(In reply to Petr Schindler from comment #11) I just gdisk zapped the GPT and MBR on two USB sticks. Then dd'd Desktop and DVD Beta TC6 to each, and I can boot MacbookPro 4,1; 8,2; and 9,2 models (2008-2012). The litd produced sticks with TC6 fail to boot. TC5 boots regardless of stick creation method.
(In reply to Jóhann B. Guðmundsson from comment #2) > Thinkpad T420 Any chance you know what firmware version is on that machine? I've got a T430s in front of me that's not showing it, and I'd have expected them to be very similar. The one here is: UEFI BIOS Version G7ET560WW (2.02 ) UEFI BIOS Date (Y-M-D): 2012-09-11 EC Version: G7HT32WW (1.08 ) Machine Type Model: 2356JK8
(In reply to Chris Murphy from comment #12) > (In reply to Petr Schindler from comment #11) > I just gdisk zapped the GPT and MBR on two USB sticks. Then dd'd Desktop and > DVD Beta TC6 to each, and I can boot MacbookPro 4,1; 8,2; and 9,2 models > (2008-2012). The litd produced sticks with TC6 fail to boot. TC5 boots > regardless of stick creation method. If you just update the packages from shim-0.4 and shim-signed-0.4 on a working install, does that result in the machine working?
(In reply to Peter Jones from comment #13) > (In reply to Jóhann B. Guðmundsson from comment #2) > > Thinkpad T420 > > Any chance you know what firmware version is on that machine? I've got a > T430s in front of me that's not showing it, and I'd have expected them to be > very similar. The one here is: > > UEFI BIOS Version G7ET560WW (2.02 ) > UEFI BIOS Date (Y-M-D): 2012-09-11 > EC Version: G7HT32WW (1.08 ) > Machine Type Model: 2356JK8 It's the latest and greatest unless they have released a new one in the last couple of weeks... UEFI BIOS Version 83ET76WW (1.46 ) UEFI BIOS Date (Y-M-D): 2013-07-05 EC Version: 83HT30WW (1.20 ) Machine Type Model: 4180WPD
(In reply to Peter Jones from comment #14) > If you just update the packages from shim-0.4 and shim-signed-0.4 on a > working install, does that result in the machine working? Yes. I can also confirm that these have the same md5sum hash: d65071a494726473c6f530e06fe9e211 /boot/efi/EFI/BOOT/BOOTX64.EFI /boot/efi/EFI/fedora/shim.efi /mnt/tc6/EFI/BOOT/BOOTX64.efi = beta TC6 DVD ISO The subtle difference between the updated working install and boot off USB stick is that the firmware NVRAM entry is directed to /boot/efi/EFI/fedora/shim.efi on an HFS+ volume, rather than USB stick's /EFI/BOOT/BOOTX64.efi on FAT32. Yet another test: livecd-iso-to-disk --noverify --efi --format --reset-mbr --overlay-size-mb 150 Fedora-Live-Desktop-x86_64-20-Beta-TC5.iso /dev/sdc Confirm this boots MBP 4,1 and 9,2. mount /dev/sdc1 /mnt/stick cp -a /boot/efi/EFI/BOOT/BOOTX64.EFI /mnt/stick/EFI/BOOT/BOOTX64.efi md5sum /mnt/stick/EFI/BOOT/BOOTX64.efi d65071a494726473c6f530e06fe9e211 That's the 0.5 shim replacing the 0.4 shim. And now the stick hangs at a black screen on the MBP 4,1 and 9,2. No messages, no GRUB, just a white non-flashing dash/underscore. Additional info: The working TC5 with 0.4 shim USB stick, messages appear very briefly before GRUB that don't appear (or happen way too quickly) when booting from HDD: Could not open "\EFI\BOOT\fallback.efi": 14 Secure boot not enabled error: failure reading sector 0x0 from 'cd0'. error: failure reading sector 0x0 from 'cd0'. error: no such device: Fedora-Live-Desktop-x86_64-20-Be. And then I get a GRUB menu. Yet the same stick on a 9,2: Could not open "\EFI\BOOT\fallback.efi": 14 Secure boot not enabled error: failure reading sector 0x0 from 'hd1'. error: failure reading sector 0x0 from 'cd0'. error: failure reading sector 0x0 from 'hd1'. error: failure reading sector 0x0 from 'cd0'. error: no such device: Fedora-Live-Desktop-x86_64-20-Be. And then a functioning GRUB menu. Both computers have one internal HDD, one empty cd/dvd drive, and the USB boot stick.
C16 under "Additional info", the first bank of messages with only 'cd0' is on a Macbook Pro 4,1.
Proposing Beta blocker: "The installer must run when launched normally from the release-blocking images. " https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Installer_must_run F20 Beta TC6 fails this criterion for UEFI boot.
johann: I listed it for TC6 before it was approved as an FE - my bad. It was actually a brain fart: I sometimes list proposed blocker/FE fixes or things that aren't blocker or FE at all (like a new kernel or selinux-policy) prior to freeze, and for some reason thought that applied to TC6, even though we were actually frozen by that point. So I listed this and one other build from the proposed FE list, even though I shouldn't have done. Just got mixed up. Sorry. If there isn't a fix for this by the next compose we can just drop back to 0.4. I vote +1 blocker, obviously. I hit this bug with my early testing of TC6 just before I left for vacation - litd of the TC6 DVD boots to a black screen with grey cursor on my Asus P8P67 Deluxe based desktop.
Discussed in 2013-10-30 Blocker Review Meeting [1]. Voted as an AcceptedBlocker. This violates Alpha criterion "The installer must run when launched normally from the release-blocking images." [2] for UEFI boot for a lot of different hardware. Either fixing this or reverting to previous build is necessary. [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-30/ [2] https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Installer_must_run
For some more data: the TC6 netinstall boots fine on my thinkpad x1 carbon (tested both with secureboot enabled and disabled) when I prepare a usb stick with either litd or dd.
I've got a test build that may fix this. On machines without secure boot, can you please try the build at: http://koji.fedoraproject.org/koji/taskinfo?taskID=6117494 If you have a machine with secure boot, the testing is still meaningful, it's just more difficult. basically you'll want that same shim build as well as the grub2-efi build at http://koji.fedoraproject.org/koji/taskinfo?taskID=6116615 . You'll also need LockDown-rhtest.efi from http://pjones.fedorapeople.org/LockDown-rhtest.efi . Make a FAT filesystem on a disk, and put LockDown-rhtest.efi on it as /EFI/BOOT/BOOTX64.EFI . Put your machine in setup mode (sorry, I don't know what that's involved on your machine) and then boot that image. With that done, an image with the shim.efi and grubx64.efi from above should be testable.
Yep, that did the trick on my MacbookPro 9,2 with the following packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=6117494 shim-unsigned-0.5-2.fc20.x86_64 shim-debuginfo-0.5-2.fc20.x86_64 mokutil-0.5-2.fc20.x86_64 thanks for keeping Fedora awesome!
Replaced bootx64.efi on non-working TC6 litd stick with 0.5-2 shim. It now boots MacbookPro 4,1; 8,2; and 9,2.
We have tested it on three several machines: * PC with Asus motherboard * PC with MSI motherboard (with both secure boot on and off) * Apple Mac Mini. PC with MSI motherboard was only machine that worked - showed bootloader and booted. Mac and Asus were stuck with blinking cursor in upper left corner, without bootloader. Results were the same for dd, liveisotodisk and liveusb-creator methods.
(In reply to Jan Sedlák from comment #25) > We have tested it on three several machines: > > * PC with Asus motherboard > * PC with MSI motherboard (with both secure boot on and off) > * Apple Mac Mini. > > PC with MSI motherboard was only machine that worked - showed bootloader and > booted. Mac and Asus were stuck with blinking cursor in upper left corner, > without bootloader. Results were the same for dd, liveisotodisk and > liveusb-creator methods. At this point that's exactly what I'd expect for 0.5-1, but not the 0.5-2 linked above. Just so it's clear, the distinguishing factor is "does this machine support Secure Boot" - enabled or disabled doesn't matter, but there's a path we free an allocation incorrectly in 0.5-1 and it happens to be the allocation for the EFI variable "SecureBoot"; if you don't have that variable at all, then we wind up freeing a NULL. So on 0.5-1, only the machine that supports SB works, the others don't. On 0.5-2, that should be fixed. I've locally confirmed it on an Asus motherboard and a MacBook Air. So are sure you've correctly tested with the newer package build?
Oh, sorry, I am not sure, let me verify it. But it probably was 0.5-1.
Comment 25 was tested with shim 0.5-1 (Beta TC6).
F20 Beta RC2 contains shim-0.2-4.4.fc19 and UEFI USB boot works again. Clearing the blocker fields, Beta requirements were satisfied. If this or other broken shim build ends up in future Beta/Final compose, please add the blocker bug fields back. Thanks.
shim-0.7-1.fc20,shim-signed-0.7-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/shim-0.7-1.fc20,shim-signed-0.7-1.fc20
Package shim-0.7-1.fc20, shim-signed-0.7-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing shim-0.7-1.fc20 shim-signed-0.7-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-21311/shim-0.7-1.fc20,shim-signed-0.7-1.fc20 then log in and leave karma (feedback).
shim-0.7-1.fc20, shim-signed-0.7-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
shim-0.7-1.fc20.x86_64 shim-unsigned-0.7-1.fc20.x86_64 mokutil-0.7-1.fc20.x86_64 Working nicely now on my T420. Thanks!
With shim-0.7-1 I see bug 1032018.