Description of problem: grub2 crashes when I enter 'e' to edit the boot commands. Version-Release number of selected component (if applicable): grub2-2.00-9.fc18.x86_64 How reproducible: every time Steps to Reproduce: 1. UEFI install to GPT disk of Fedora-18 pre-Beta (TC3 or so) from DVD built containing grub2-2.00-9 2. UEFI boot installed system 3. Type 'e' to edit commands Actual results: Central window expands from about 24x7.5 cm to 33x18 cm, with interior all black, then system freezes with no response to keyboard or mouse. Hardware reset is required. Expected results: Editing commands. Additional info:
Do the command line mode work? What hardware do you use? Please attach a photo of the frozen system - the exact failure mode might give a hint what the problem could be.
Created attachment 627167 [details] screen photo at freeze Letting the count-down timer expire, gives successful boot to multi-user mode. Typing 'c' gives a command line. (The font is very ugly, but "correctly drawn" and usable.) In command line, typing <ESC> gets back to non- command line. This is ASUS P8Z68-V/GEN3 mainboard (UEFI AMIBIOS version 3402 of May 2012) with Intel Core i5. Monitor is 1920x1080 driven by nVidia GT430. GRUB display field has a 3cm margin (all black) on left and right, 1.5cm margin on top and bottom. Normal X11 display after successful boot does not have these margins.
This sounds and looks a lot like Bug 859632. Are you 200% sure that you are booting the 2.00-9 grub?
The same problem appears using a 1024x768 monitor. With regard to which version: The boot-time splash screen says "GRUB Boot Menu" and the banner after typing 'c' says "GNU GRUB version 2.00". There is no 'version' command. The output from typing "help\r" scrolls by so fast that it is unreadable except for the last 15 [physical] lines, which contain no version information. [So there's an additional bug: the necessary info is not displayed by the software itself.] The build log for the compose of the .iso by pungi says: ----- pylorax.yumhelper.DEBUG: 1:grub2-2.00-9.fc18.x86_64 installed successfully pylorax.yumhelper.DEBUG: 1:grub2-efi-2.00-9.fc18.x86_64 installed successfully ----- The /Packages/g directory of the physical DVD has: ----- -rw-r--r--. 2 jreiser jreiser 606305 Sep 5 16:27 grub-0.97-91.fc18.x86_64.rpm -rw-r--r--. 2 jreiser jreiser 1236568 Oct 1 11:28 grub2-2.00-9.fc18.x86_64.rpm -rw-r--r--. 2 jreiser jreiser 3609580 Oct 1 11:27 grub2-efi-2.00-9.fc18.x86_64.rpm -rw-r--r--. 2 jreiser jreiser 4820680 Oct 1 11:27 grub2-tools-2.00-9.fc18.x86_64.rpm -rw-r--r--. 2 jreiser jreiser 56392 Oct 2 19:28 grubby-8.20-1.fc18.x86_64.rpm ----- The /images directory of the physical DVD has: ----- -rw-r--r--. 1 jreiser jreiser 4999168 Oct 13 13:22 efiboot.img -rw-r--r--. 1 jreiser jreiser 20021248 Oct 13 13:22 macboot.img drwxr-xr-x. 2 jreiser jreiser 2048 Oct 13 13:22 pxeboot -r--r--r--. 1 jreiser jreiser 665 Oct 13 13:22 TRANS.TBL -----
You mention DVD, but you are booting from ESP, right? With the shim starting grub2? Or could there be some other old .efis on the ESP?
Because the comlete version info is not displayed on the initial splash screen, nor on the banner for the 'c' session, nor in a 'version' command, I included the DVD info as part of trying to discern which version was actually running. Yes, I am booting from the EFI System Partition. The BIOS has a builtin boot manager which offers a choice of boot devices. The menu lists both UEFI and non-UEFI entries for the harddrive in question. I choose the UEFI entry. There is a brief message in VGA font about some missing file, then the "graphical" GNU Grub Menu. After a complete usual boot and login to multiuser graphical session, then "cd /boot/efi/EFI; ls -lR" says ----- # ls -lR .: total 4 drwx------. 3 root root 2048 Oct 15 06:17 fedora drwx------. 2 root root 2048 Oct 13 23:03 redhat ./fedora: total 2940 drwx------. 2 root root 2048 Oct 13 23:06 fonts -rwx------. 1 root root 814356 Oct 1 18:01 gcdx64.efi -rwx------. 1 root root 4810 Oct 13 23:09 grub.cfg -rwx------. 1 root root 833300 Oct 1 18:01 grubx64.efi -rwx------. 1 root root 1352415 Aug 14 19:20 shim.efi ./fedora/fonts: total 2502 -rwx------. 1 root root 2560080 Oct 1 18:01 unicode.pf2 ./redhat: total 96 -rwx------. 1 root root 47400 Jul 28 02:48 modelist.efi -rwx------. 1 root root 47400 Jul 28 02:48 route80h.efi # ----- This machine also has another harddrive (also GPT) with an "independent" UEFI. The order of installs on that harddrive was: Fedora 17, Windows 7, Fedora 18-alpha. The UEFI booting was working for both Fedora 17 and Windows 7; and the BIOS boot manager offered a UEFI entry for Windows, a UEFI entry for Fedora, and a non-UEFI entry for Fedora. The install of Fedora 18-alpha onto that first harddrive didn't even get beyond partitioning, but it trashed the Fedora UEFI booting on that drive. So now I'm trying to be more careful about UEFI installs of Fedora. I disconnected the first harddrive, connected the second drive, installed UEFI Fedora 18, then re-connected the first drive. Now the BIOS boot manager offers UEFI Windows (1st drive) and UEFI Fedora (2nd drive) and non-UEFI Fedora (2nd drive). Both UEFI choices succeed.
Strange. The symptoms are exactly like pre-alpha. Do the efi grub.cfg search for the right root where it can find a valid grub2/themes/system/unicode.pf2 ? Poking around in the command line can perhaps give a hint what is going on and what it actually finds. Will disconnecting the first drive make any difference? Do non-efi boot work correctly, also when editing?
"Poking around in the command line can perhaps give a hint" Please be specific; what should I try? The message in VGA text that flies by before the splash screen is: error: file `EFI/fedora/locale/en.mo.gz' not found There are two drives, the first is 500GB, the second is 750GB. I have annotated the mount points under the "File system" column, and edited the column spacing for readability: ----- # parted /dev/sda ### the "first" drive (parted) p Model: ATA WDC WD5000AAKX-7 (scsi) Disk /dev/sda: 500GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 8389kB 67.1MB 58.7MB fat16 (/boot/efi) EFI System Partition boot 2 67.1MB 591MB 524MB ext3 (/boot) 3 591MB 97.2GB 96.6GB ntfs (Win7) 4 97.2GB 113GB 16.1GB linux-swap(v1) 5 113GB 129GB 16.1GB ext4 (/ Fedora17) 6 129GB 130GB 134MB Microsoft reserved partition msftres (parted) q # parted /dev/sdb ### the "second" drive GNU Parted 3.1 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: ATA WDC WD7501AALS-0 (scsi) Disk /dev/sdb: 750GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 53.5MB 52.4MB fat16 (/boot/efi) EFI System Partition boot 2 53.5MB 603MB 549MB ext4 (/boot) 3 603MB 17.5GB 16.9GB ext4 (/ Fedora18) 4 17.5GB 22.0GB 4503MB linux-swap(v1) (parted) q # ----- Notice that each drive has partition #1 as a fat16 with Name of "EFI System Partition" and flag 'boot'. Neither one of the BIOS boot manager non-UEFI boot entries succeeds. Both of them give the same output in VGA text ("non-graphical") when both drives are connected: ----- GRUB loading. ## normal VGA text (white on black) Welcome to GRUB! ## those characters are in inverse video (black on white) error: unknown filesystem. Entering resue mode... grub rescue> help Unknown command `help'. grub rescue> ls ## I have broken the one output line for readability (hd0) (hd0,gpt4) (hd0,gpt3) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,gpt6) (hd1,gpt5) (hd1,hpt4) (hd1,gpt3) (hd1,gpt2) (hd1,gpt1) (hd3) (hd4) ----- which is interesting because a) both outputs are the same and b) the logical order is swapped. The 6-partition 500MB drive (which is connected to a lower-numbered SATA port on the mainboard, and has a lower-numbered [higher] priority in the boot list) is listed as hd1, while the 4-partition 750MB drive (which is connected to a higher-numbered SATA port on the mainboard, and has a higher-numbered [lower] priority in the boot list) is listed as hd0. Still with both drives connected, booting UEFI from the second drive, and typing 'c' to get a command-line session (again, output has been edited for clarity): ----- grub> ls (hd0) (hd0,gpt6) ... (hd0,gpt1) ### ellipsis: original has expanded form (hd1) (hd1,gpt4) ... (hd1,gpt1) (hd2) (hd3) error: failure reading sector 0xfc from `hd2' error: failure reading sector 0xe0 from `hd2' error: failure reading sector 0xfc from `hd3' error: failure reading sector 0xe0 from `hd3' grub> ----- Here the hd1 and hd0 are swapped from rescue mode. [My head begins to spin.] Now, I *disconnect* the first drive: shutdown, unplug the external power cable to the box, unplug both the data cable and the power cable to the first drive, re-plug the external power cable to the box, and reboot in UEFI mode from the second drive (and there is only one UEFI entry in the BIOS boot menu). I see the same original problem: a freeze after typing 'e'. So the bits on the second drive definitely have a problem. I believe that those bits are grub2-2.00-9.fc18 (or grub2-efi of the same version). I wonder how strongly the various pieces of grub2 are bound together for EFI mode. Are all "links" done by UUID? Is there any possibility of confusion because each drive has a "EFI System Partition" with the 'boot' flag, or does grub2 only pay attention to the "right" one? Here are the partitions; dracut can tell them apart by UUID, for instance: ----- [root@f18e64 ~]# ls -l /dev/disk/by-partuuid total 0 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 0dc293dd-2ba2-4fd8-8199-54338df5090e -> ../../sdb4 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 1897719d-f4db-4b95-86b3-4b06b35ba338 -> ../../sdb1 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 1f3ed6f0-ab1a-42b6-b6a3-c3725b04e517 -> ../../sda2 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 26495dd8-65bc-43ea-9f42-faa351bb20dd -> ../../sdb3 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 51833917-3617-472d-8d94-eac5adb6070c -> ../../sda5 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 59000353-c534-44d2-8c96-a1a174e0a24b -> ../../sda1 lrwxrwxrwx. 1 root root 10 Oct 15 04:39 855168f1-8bf0-431f-8e53-15395e012364 -> ../../sdb2 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 c2c0257d-9612-4b3f-9e4b-3456e139447c -> ../../sda6 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 ca0430a4-81b2-47dc-8b04-c2b13761122b -> ../../sda3 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 cb0bcbfe-17b8-4c81-866f-81d27c80a3da -> ../../sda4 [root@f18e64 ~]# ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 10104278-3dba-4a83-872e-4ee466a5650a -> ../../sda4 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 18a879f4-925e-4683-80b7-5dfac0476946 -> ../../sda5 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 311E-E1AE -> ../../sdb1 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 3A6AA7426AA6F9B1 -> ../../sda3 lrwxrwxrwx. 1 root root 10 Oct 15 04:39 52cee3f2-11bd-4992-8de7-e0676a191ddc -> ../../sdb2 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 8278411c-bafa-47c7-9c98-6f4e41e7a5ec -> ../../sda2 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 9FD2-B22A -> ../../sda1 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 ae4c1eb8-2879-48cb-943e-e3f851fb085a -> ../../sdb4 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 af448ff5-835e-402f-a2ec-c85a2d92228c -> ../../sdb3 [root@f18e64 ~]# ls -l /dev/disk/by-partlabel total 0 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 EFI\x20System\x20Partition -> ../../sdb1 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 Microsoft\x20reserved\x20partition -> ../../sda6 [root@f18e64 ~]# ls -l /dev/disk/by-label total 0 lrwxrwxrwx. 1 root root 10 Oct 15 04:39 boot -> ../../sdb2 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 EFIboot -> ../../sdb1 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 f17e64 -> ../../sda5 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 f18e64 -> ../../sdb3 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 staging -> ../../sda2 lrwxrwxrwx. 1 root root 10 Oct 15 04:38 Win7pro -> ../../sda3 [root@f18e64 ~]# ----- Incidentally, with only the second drive connected, then the first gdm session does not appear. I have to switch to VT2, login as root, "kill -TERM" the X server, then "startx". I attribute this to problems with the nouveau driver in Fedora 18 [pre-]Beta. I don't have gdm problem when both drives are connected.
That's a lot of information. But I do not see any pattern or explanation. But Grub should always find partitions by UUID. The device naming should not matter. You can try to check if the UUIDs in the efi grub.cfg are as you expect them to be. In the grub command line you can try to run 'set' or 'echo $root' and something like 'ls ($root)' and tab completion to see which devices are found. Commands from grub.cfg can also be run manually.
I will try the grub command hints shortly; thank you. "You can try to check if the UUIDs in the efi grub.cfg are as you expect them to be." # blkid /dev/sdb1 /dev/sdb2 /dev/sdb3 ## sdb ==> 750GB second disk, Fedora 18 /dev/sdb1: SEC_TYPE="msdos" LABEL="EFIboot" UUID="311E-E1AE" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="1897719d-f4db-4b95-86b3-4b06b35ba338" /dev/sdb2: LABEL="boot" UUID="52cee3f2-11bd-4992-8de7-e0676a191ddc" TYPE="ext4" PARTUUID="855168f1-8bf0-431f-8e53-15395e012364" /dev/sdb3: LABEL="f18e64" UUID="af448ff5-835e-402f-a2ec-c85a2d92228c" TYPE="ext4" -----f18e64:/boot/efi/EFI/fedora/grub.cfg: ## on sdb1: second drive, 750 GB if [ x$feature_default_font_path = xy ] ; then font=unicode else insmod part_gpt insmod ext2 set root='hd0,gpt3' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3 af448ff5-835e-402f-a2ec-c85a2d92228c else search --no-floppy --fs-uuid --set=root af448ff5-835e-402f-a2ec-c85a2d92228c fi font="/usr/share/grub/unicode.pf2" fi ----- Here the Linux root UUID (af44...) is correct for Fedora 18 on the second drive (750 GB) but hints of "hd0" are necessarily correct. hd0 *was* correct (for the install, I disconnected the first drive as a safety precaution), but now I hope that hd0 means the first drive (500 GB: Fedora 17, Win7) not the second (750 GB: Fedora 18). -----f18e64:/boot/efi/EFI/fedora/grub.cfg: ## on sdb1 insmod part_gpt insmod ext2 set root='hd0,gpt2' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 52cee3f2-11bd-4992-8de7-e0676a191ddc else search --no-floppy --fs-uuid --set=root 52cee3f2-11bd-4992-8de7-e0676a191ddc fi ----- Again the /boot UUID (52ce...) is correct but the hints "hd0" are not necessarily correct. And in the third line "set root='hd0,gpt2'" is worrisome. Is that "hd0" a hint that is overridden later? It had better be, because "hd0" could be the wrong one now that there are two drives with competing versions of grub2. Here's /boot/efi/EFI on the first drive (500 GB: Fedora 17, Win7). The failed attempt to install Fedora 18-Alpha did muck things up. The BIOS boot manager believes that this drive now has only a Windows UEFI entry, whereas before the BIOS boot manager listed both a Fedora UEFI and a Windows UEFI entry (as well as a non-UEFI entry, which should have been for Fedora 17.) ----- # cd /sda1/EFI; ls -lR .: total 6 drwxr-xr-x. 2 root root 2048 Jul 4 22:31 Boot drwxr-xr-x. 3 root root 2048 Jul 4 22:23 Microsoft drwxr-xr-x. 2 root root 2048 Sep 11 00:43 redhat ./Boot: total 658 -rwxr-xr-x. 1 root root 672640 Nov 20 2010 bootx64.efi ./Microsoft: total 2 drwxr-xr-x. 26 root root 2048 Jul 4 22:23 Boot ./Microsoft/Boot: total 2092 -rwxr-xr-x. 1 root root 36864 Oct 14 20:02 BCD -rwxr-xr-x. 1 root root 33792 Oct 14 20:02 BCD.LOG -rwxr-xr-x. 1 root root 0 Jul 4 22:31 BCD.LOG1 -rwxr-xr-x. 1 root root 0 Jul 4 22:31 BCD.LOG2 -rwxr-xr-x. 1 root root 672640 Nov 20 2010 bootmgfw.efi -rwxr-xr-x. 1 root root 669568 Nov 20 2010 bootmgr.efi -rwxr-xr-x. 1 root root 65536 Jul 4 22:31 BOOTSTAT.DAT drwxr-xr-x. 2 root root 2048 Jul 4 22:31 en-US [snip 23 other directories of <language>-<country>] -rwxr-xr-x. 1 root root 611200 Nov 20 2010 memtest.efi ./Microsoft/Boot/en-US: ## other <language>-<country> directories lack memtest.efi.mui total 204 -rwxr-xr-x. 1 root root 85056 Jul 13 2009 bootmgfw.efi.mui -rwxr-xr-x. 1 root root 77824 Jul 13 2009 bootmgr.efi.mui -rwxr-xr-x. 1 root root 43584 Apr 12 2011 memtest.efi.mui ./Microsoft/Boot/Fonts: total 11696 -rwxr-xr-x. 1 root root 3694080 Jun 10 2009 chs_boot.ttf -rwxr-xr-x. 1 root root 3876772 Jun 10 2009 cht_boot.ttf -rwxr-xr-x. 1 root root 1984228 Jun 10 2009 jpn_boot.ttf -rwxr-xr-x. 1 root root 2371360 Jun 10 2009 kor_boot.ttf -rwxr-xr-x. 1 root root 47452 Jun 10 2009 wgl4_boot.ttf ./redhat: total 246 -rwxr-xr-x. 1 root root 64 Jul 3 20:49 device.map -rwxr-xr-x. 1 root root 1315 Aug 23 22:56 grub.conf -rwxr-xr-x. 1 root root 246697 Apr 27 15:45 grub.efi # -----
Likely the same issue as bug 859632. But try the patch in that bug to be sure.
Also try and overwrite the grub2-efi grubx64.efi with grub2-install grub2-mkconfig -o /boot/grub2/grub.cfg That will make clear whether the problem is in the grub code or in the Fedora grubx64.efi packaging.
I'm experiencing also this error in Fedora 18 x86_64 with versions: grub2-2.00-15.fc18.x86_64 grub2-efi-2.00-15.fc18.x86_64 My motherboard is an Asus P8Z68-V LE with latest UEFI version 4002. I can move between entries, and when I press 'e' the central window gets black and the system freezes. I need to push the reset button to restart the computer. I have taken a photo exactly like the one attached in this report. If I configure in /etc/default/grub: GRUB_TERMINAL=console and grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg It works perfectly, but logically without the graphical theme. Previously, I had the system installed and booted with "legacy BIOS", and it worked ok.
Created attachment 760319 [details] My grub.cfg This is my grub.cfg. When I press 'e' to edit an entry, the system freezes.
I've upgraded to F19 and now I can edit the boot entries in graphical mode. grub2-efi-2.00-23.fc19.x86_64
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 WONTFIX if it remains open with a Fedora 'version' of '18'. 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 prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 to Fedora 18's end of life. 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 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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.