Created attachment 732878 [details] ls -lR /boot/efi # from Rescue mode Description of problem: Booting fails after a "Complete!" EFI install of Fedora-19-Alpha_TC5-x86_64-DVD.iso. Version-Release number of selected component (if applicable): grub2-efi-2.00-16.fc19.x86_64.rpm How reproducible: always (twice so far) Steps to Reproduce: 1. livecd-iso-to-disk --format --efi Fedora-19-Alpha_TC5-x86_64-DVD.iso /dev/sdc1 # to USB flash memory device 2. boot USB flash memory device in EFI mode 3. default graphical install (anaconda-19.16-1) 4. reboot to newly-installed system in EFI mode Actual results: Secure boot not enabled Welcome to GRUB! error: file `/EFI/fedora/locale/en.mo.gz' not found. <<hang: no output, no response to keyboard; hardware reset is necessary>> Expected results: Successful boot into newly-installed system Additional info: ASUS P8Z68-V/GEN3, BIOS version 3402; Intel Core i5
Created attachment 732879 [details] grub.cfg
Created attachment 732880 [details] /tmp/storage.log from installer
Created attachment 732881 [details] anconda.log
Created attachment 732882 [details] syslog from installer
A subsequent attempt to install using RC1 in EFI mode failed in the installer: "BootLoaderError: failed to set new efi boot target", bug #949786. After that, I used Rescue mode to run "efibootmgr --verbose >foo". Here is what it says: # cat foo BootCurrent: 0003 Timeout: 2 seconds BootOrder: 0001,0002,0003 Boot0001* CD/DVD Drive BIOS(3,0,00)AMGOAMNO........u.O.p.t.i.a.r.c. .D.V.D. .R.W. .A.D.-.7.2.8.0.S....................A...........................D..Gd-.;.A..MQ..L.O.p.t.i.a.r.c. .D.V.D. .R.W. .A.D.-.7.2.8.0.S......AMBOAMNO........o.T.S.S.T.c.o.r.p. .C.D.D.V.D.W. .S.H.-.S.2.2.3.C....................A...........................>..Gd-.;.A..MQ..L.4.R.3.1.G.6.B.A.1.2.3.2.9.1. . . . . . ......AMBO Boot0002* Hard Drive BIOS(2,0,00)AMGOAMNO........o.H.D.T.7.2.2.5.1.6.D.L.A.3.8.0....................A...........................>..Gd-.;.A..MQ..L. . . . . . .D.V.7.K.B.1.C.T.H.E.U.4.K.P......AMBOAMNO........}.K.i.n.g.s.t.o.n.D.T. .R.u.b.b.e.r. .3...0. .P.M.A.P....................A.............................J..Gd-.;.A..MQ..L.K.i.n.g.s.t.o.n.D.T. .R.u.b.b.e.r. .3...0. .P.M.A.P......AMBO Boot0003* UEFI: KingstonDT Rubber 3.0 PMAP ACPI(a0341d0,0)PCI(1a,0)USB(1,0)USB(1,0)HD(1,800,1d46800,6d6cfd88-519f-4f53-afb3-c399181be837)AMBO # od -c foo 0000000 B o o t C u r r e n t : 0 0 0 0000020 3 \n T i m e o u t : 2 s e c 0000040 o n d s \n B o o t O r d e r : 0000060 0 0 0 1 , 0 0 0 2 , 0 0 0 3 \n B 0000100 o o t 0 0 0 1 * C D / D V D 0000120 D r i v e \t B I O S ( 3 , 0 , 0000140 0 0 ) A M G O A M N O . . . . . 0000160 . . . u . O . p . t . i . a . r 0000200 . c . . D . V . D . . R . W 0000220 . . A . D . - . 7 . 2 . 8 . 0 0000240 . S . . . . . . . . . . . . 177 . 0000260 . . . . . . . A . . . . . . . . 0000300 . . . . . . . . . . . . . . 177 . 0000320 . . . . D . . G d - . ; . A . . 0000340 M Q . . L . O . p . t . i . a . 0000360 r . c . . D . V . D . . R . 0000400 W . . A . D . - . 7 . 2 . 8 . 0000420 0 . S . . . 177 . . . A M B O A M 0000440 N O . . . . . . . . o . T . S . 0000460 S . T . c . o . r . p . . C . 0000500 D . D . V . D . W . . S . H . 0000520 - . S . 2 . 2 . 3 . C . . . . . 0000540 . . . . . . . 177 . . . . . . . . 0000560 A . . . . . . . . . . . . . . . 0000600 . . . . . . . 177 . . . . . > . . 0000620 G d - . ; . A . . M Q . . L . 4 0000640 . R . 3 . 1 . G . 6 . B . A . 1 0000660 . 2 . 3 . 2 . 9 . 1 . . . 0000700 . . . . . . 177 . . . A M B 0000720 O \n B o o t 0 0 0 2 * H a r d 0000740 D r i v e \t B I O S ( 2 , 0 0000760 , 0 0 ) A M G O A M N O . . . . 0001000 . . . . o . H . D . T . 7 . 2 . 0001020 2 . 5 . 1 . 6 . D . L . A . 3 . 0001040 8 . 0 . . . . . . . . . . . . 177 0001060 . . . . . . . . A . . . . . . . 0001100 . . . . . . . . . . . . . . . 177 0001120 . . . . . > . . G d - . ; . A . 0001140 . M Q . . L . . . . . 0001160 . . D . V . 7 . K . B . 1 . C 0001200 . T . H . E . U . 4 . K . P . . 0001220 . 177 . . . A M B O A M N O . . . 0001240 . . . . . } . K . i . n . g . s 0001260 . t . o . n . D . T . . R . u 0001300 . b . b . e . r . . 3 . . . 0 0001320 . . P . M . A . P . . . . . . 0001340 . . . . . . 177 . . . . . . . . A 0001360 . . . . . . . . . . . . . . . . 0001400 . . . . . . . . 177 . . . . . J . 0001420 . G d - . ; . A . . M Q . . L . 0001440 K . i . n . g . s . t . o . n . 0001460 D . T . . R . u . b . b . e . 0001500 r . . 3 . . . 0 . . P . M . 0001520 A . P . . . 177 . . . A M B O \n B 0001540 o o t 0 0 0 3 * U E F I : K 0001560 i n g s t o n D T R u b b e r 0001600 3 . 0 P M A P \t A C P I ( a 0001620 0 3 4 1 d 0 , 0 ) P C I ( 1 a , 0001640 0 ) U S B ( 1 , 0 ) U S B ( 1 , 0001660 0 ) H D ( 1 , 8 0 0 , 1 d 4 6 8 0001700 0 0 , 6 d 6 c f d 8 8 - 5 1 9 f 0001720 - 4 f 5 3 - a f b 3 - c 3 9 9 1 0001740 8 1 b e 8 3 7 ) A M B O \n 0001755 # ----- So it looks like there are competing formats: some ASCII, some Unicode, some with '\n' terminator, some with '\0177' terminator, some with implied terminator after "AMBO". And the allocation of space looks very peculiar. The devices capable of booting were: O.p.t.i.a.r.c. .D.V.D. .R.W. .A.D.-.7.2.8.0.S # optical drive T.S.S.T.c.o.r.p. .C.D.D.V.D.W. .S.H.-.S.2.2.3.C # optical drive H.D.T.7.2.2.5.1.6.D.L.A.3.8.0 # 165GB harddrive UEFI: KingstonDT Rubber 3.0 PMAP # USB3.0 flash memory drive
I'm hitting this too on a Dell Optiplex 990 (in UEFI mode). I used the Dell UEFI setup to try changing the boot file from \EFI\fedora\shim.efi to \EFI\fedora\grubx86.efi (since this system doesn't support secure boot) but it still just gives me a plain "Welcome to GRUB!" and then it hangs.
Hitting this also on Mac Mini.
Adding this to the potential-Alpha-blocker pile, as a lot of testers seem to be hitting this (tflink and satellit also reported seeing similar results on IRC).
<jwb> adamw, you might ask them to change from gfxterm to console in grub.cfg tflink reported success when using serial console, so this could well be a gfxterm issue of some kind.
On the data we've got today, I'm leaning +1 blocker on this one - it seems like everyone who gets past bootloader installation with a UEFI install hits this one at boot time. I don't think I've heard of a successful UEFI install apart from tflink's serial console one.
I'm copying what Adam W said on devel@ to document a possible (untested) workaround: <pjones>: adamw: get them to try putting "GRUB_TERMINAL_OUTPUT=console" in /etc/default/grub and re-running grub2-mkconfig you could do that from ctrl-alt-f2 after install is complete but before rebooting, or you could do it from rescue mode or a live image on the installed system. The theory is that by disabling grub's graphical mode we'll work around whatever the problem is, and hence prove that the problem is with the graphical mode. If anyone actually got an entirely successful UEFI install with Alpha RC1 or RC2 - it installed without errors, and the installed system boots, showing you a graphical grub screen - that would be useful info to add to the bug; right now I'm working on the assumption that this is a complete showstopper for all UEFI installs.
Confirmed the same symptoms as the bug reporter on a Lenovo ThinkPad T520 after installing 19 Alpha RC2 in UEFI mode. (In reply to comment #9) > <jwb> adamw, you might ask them to change from gfxterm to console in grub.cfg > > tflink reported success when using serial console, so this could well be a > gfxterm issue of some kind. Also confirmed that putting "GRUB_TERMINAL_OUTPUT=console" in /etc/default/grub and re-running grub2-mkconfig allows the system to boot.
Discussed at 2013-04-11 F19 Alpha go/no-go meeting, acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting-1/2013-04-11/f19_alpha_gono-go_meeting.2013-04-11-17.00.log.html . Accepted as a blocker, as this appears to be a showstopper for all UEFI installs.
GRUB_TERMINAL_OUTPUT=console + grub2-mkconfig fixed it on my Dell Optiplex 990 too.
I also hit this with a shiny new Windows 8 Dell laptop and the terminal fix fixes it.
*** Bug 951053 has been marked as a duplicate of this bug. ***
Another workaround is loading the config file in F18's grub. So, if you have F18 still installed, you can boot F19 without changing the /etc/default/grub file and running grub2-mkconfig.
https://admin.fedoraproject.org/updates/FEDORA-2013-5509/anaconda-19.18-1.fc19 should address this for new installs. pjones wants to work on something else for upgrades, I believe. There will probably be a new build soon to verify the fix.
The new Alpha TC6 build (note: this is newer than RC2) should 'fix' this, by using console mode for grub for fresh UEFI installs. Can people please test and verify that things are good with TC6? Thanks! https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-TC6/
TC6 UEFI install succeeded, and the installed system booted via UEFI into gnome-initial-setup. I started the UEFI install with the efivars state of comment #5 above, plus a harddrive with gpt disk label and no partitions. I chose default partition setup except Standard Partition instead of LVM.
The resulting efivars state is: # efibootmgr --verbose BootCurrent: 0000 Timeout: 2 seconds BootOrder: 0000,0001,0002 Boot0000* Fedora HD(1,800,64000,fb925ab5-f720-4a1a-9e1e-b12c601654c1)File(\EFI\fedora\shim.efi) Boot0001* CD/DVD Drive BIOS(3,0,00)AMGOAMNO........u.O.p.t.i.a.r.c. .D.V.D. .R.W. .A.D.-.7.2.8.0.S....................A...........................D..Gd-.;.A..MQ..L.O.p.t.i.a.r.c. .D.V.D. .R.W. .A.D.-.7.2.8.0.S......AMBOAMNO........o.T.S.S.T.c.o.r.p. .C.D.D.V.D.W. .S.H.-.S.2.2.3.C....................A...........................>..Gd-.;.A..MQ..L.4.R.3.1.G.6.B.A.1.2.3.2.9.1. . . . . . ......AMBO Boot0002* Hard Drive BIOS(2,0,00)AMGOAMNO........o.H.D.T.7.2.2.5.1.6.D.L.A.3.8.0....................A...........................>..Gd-.;.A..MQ..L. . . . . . .D.V.7.K.B.1.C.T.H.E.U.4.K.P......AMBO # efibootmgr --verbose | od -c 0000000 B o o t C u r r e n t : 0 0 0 0000020 0 \n T i m e o u t : 2 s e c 0000040 o n d s \n B o o t O r d e r : 0000060 0 0 0 0 , 0 0 0 1 , 0 0 0 2 \n B 0000100 o o t 0 0 0 0 * F e d o r a \t 0000120 H D ( 1 , 8 0 0 , 6 4 0 0 0 , f 0000140 b 9 2 5 a b 5 - f 7 2 0 - 4 a 1 0000160 a - 9 e 1 e - b 1 2 c 6 0 1 6 5 0000200 4 c 1 ) F i l e ( \ E F I \ f e 0000220 d o r a \ s h i m . e f i ) \n B 0000240 o o t 0 0 0 1 * C D / D V D 0000260 D r i v e \t B I O S ( 3 , 0 , 0000300 0 0 ) A M G O A M N O . . . . . 0000320 . . . u . O . p . t . i . a . r 0000340 . c . . D . V . D . . R . W 0000360 . . A . D . - . 7 . 2 . 8 . 0 0000400 . S . . . . . . . . . . . . 177 . 0000420 . . . . . . . A . . . . . . . . 0000440 . . . . . . . . . . . . . . 177 . 0000460 . . . . D . . G d - . ; . A . . 0000500 M Q . . L . O . p . t . i . a . 0000520 r . c . . D . V . D . . R . 0000540 W . . A . D . - . 7 . 2 . 8 . 0000560 0 . S . . . 177 . . . A M B O A M 0000600 N O . . . . . . . . o . T . S . 0000620 S . T . c . o . r . p . . C . 0000640 D . D . V . D . W . . S . H . 0000660 - . S . 2 . 2 . 3 . C . . . . . 0000700 . . . . . . . 177 . . . . . . . . 0000720 A . . . . . . . . . . . . . . . 0000740 . . . . . . . 177 . . . . . > . . 0000760 G d - . ; . A . . M Q . . L . 4 0001000 . R . 3 . 1 . G . 6 . B . A . 1 0001020 . 2 . 3 . 2 . 9 . 1 . . . 0001040 . . . . . . 177 . . . A M B 0001060 O \n B o o t 0 0 0 2 * H a r d 0001100 D r i v e \t B I O S ( 2 , 0 0001120 , 0 0 ) A M G O A M N O . . . . 0001140 . . . . o . H . D . T . 7 . 2 . 0001160 2 . 5 . 1 . 6 . D . L . A . 3 . 0001200 8 . 0 . . . . . . . . . . . . 177 0001220 . . . . . . . . A . . . . . . . 0001240 . . . . . . . . . . . . . . . 177 0001260 . . . . . > . . G d - . ; . A . 0001300 . M Q . . L . . . . . 0001320 . . D . V . 7 . K . B . 1 . C 0001340 . T . H . E . U . 4 . K . P . . 0001360 . 177 . . . A M B O \n 0001372
this is fixed in TC6 EFI USB anaconda installs and desktop boots properly on MacbookPro i7 from efi USB If --efi is added: livecd-iso-to-disk --format --reset-mbr --efi Fedora-19-Alpha-TC6-x86_64-DVD.iso /dev/sdc
(In reply to comment #19) > The new Alpha TC6 build (note: this is newer than RC2) should 'fix' this, by > using console mode for grub for fresh UEFI installs. Can people please test > and verify that things are good with TC6? Thanks! > > https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-TC6/ TC6 testing[1]: # livecd-iso-to-disk --format --reset-mbr --efi Fedora-19-Alpha-x86_64-DVD.iso /dev/sdc USB EFI boot - (Yellow USB Icon for drive) from x86_64 l-i-t-d DVD.iso and desktop live.iso's (with --efi switch added) from a MacBookPro i7 to external USB HD. Installed sucessfully and re booted (Blue (f) icon for drive) into black and white grub2 and then gnome3 desktop. Sucessfull updates via wired network: enp2s0f0 [1] https://fedoraproject.org/wiki/Test_Results:Fedora_19_Alpha_TC6_Install#USB_stick
TC6 testing indicates this bug is 'fixed' by the workaround of using console rather than graphical mode for grub2 in UEFI installs. However, pjones wants to identify and fix the underlying bug, so we will not mark this bug as ON_QA/VERIFIED/CLOSED. Instead, when the relevant update - https://admin.fedoraproject.org/updates/FEDORA-2013-5509/anaconda-19.18-1.fc19 - goes stable, we will drop the blocker status.
anaconda-19.18-1.fc19 is in TC6 already, and as of 2013-04-15 16:07:46 (which is before 2013-04-15 13:40:32 EDT of comment #24) the build status says that the build can be considered stable at maintainer's discretion (3 days in testing; no karma of any kind.) So are we waiting for the next anaconda-19.19-1 to get graphical mode for grub2, or what?
john: we adjust the bug status when the package moves repository. It is still in updates-testing. It can't just be 'considered' stable - the maintainer has to push it to stable, and during a freeze, releng has to force it through the freeze. Then it will actually be in the 'stable' repository (the 'fedora' repo) and we can drop the blocker status of the bug.
(In reply to comment #24) > TC6 testing indicates this bug is 'fixed' by the workaround of using console > rather than graphical mode for grub2 in UEFI installs. However, pjones wants > to identify and fix the underlying bug, so we will not mark this bug as > ON_QA/VERIFIED/CLOSED. Instead, when the relevant update - > https://admin.fedoraproject.org/updates/FEDORA-2013-5509/anaconda-19.18-1. > fc19 - goes stable, we will drop the blocker status. As a point of reference - the workaround in RC3 fixes the issue for me. I no longer have to modify the grub configuration in order for my system to boot post-install.
anaconda 19-19-1 is not an improvement: l-i-t-d of x86_64 DVD with --efi fails now in RC3. It boots to "Secure boot not enabled" and halts in EFI boot on MacBool Pro i7. Also not that the l-i-t-d USB fails to boot in a normal PC (non efi) after using it in Mac. stSecure boot not enabled. Stops at "SELInux....... Is something being written to the USB under EFI boot that could erase normal booting,? I had to rewrite the litd DVD and then it boots on PC and installs fine.
(In reply to comment #28) I'm also hitting this with Mac Mini. Seems that Lorax might be responsible for this, as it's "the" thing that changed between TC6 and RC3. Filed bug #953447
anaconda 19.20 went stable, we're considering this no longer a blocker as it was worked around. The bug is still open because there's a genuine bug with the graphical mode here; pjones is working on a proper fix.
Looks like this does indeed break upgrades. See https://bugzilla.redhat.com/show_bug.cgi?id=966586 .
grub2-2.00-18.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/grub2-2.00-18.fc19
Package grub2-2.00-18.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing grub2-2.00-18.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-9069/grub2-2.00-18.fc19 then log in and leave karma (feedback).
grub2-2.00-18.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.