Bug 866275 - crash when edit boot commands
crash when edit boot commands
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
18
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-14 21:28 EDT by John Reiser
Modified: 2014-02-05 07:34 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 07:34:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screen photo at freeze (129.96 KB, image/jpeg)
2012-10-14 23:01 EDT, John Reiser
no flags Details
My grub.cfg (10.08 KB, text/plain)
2013-06-12 17:08 EDT, Juan Orti
no flags Details

  None (edit)
Description John Reiser 2012-10-14 21:28:01 EDT
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:
Comment 1 Mads Kiilerich 2012-10-14 21:48:48 EDT
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.
Comment 2 John Reiser 2012-10-14 23:01:33 EDT
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.
Comment 3 Mads Kiilerich 2012-10-15 05:30:32 EDT
This sounds and looks a lot like Bug 859632. Are you 200% sure that you are booting the 2.00-9 grub?
Comment 4 John Reiser 2012-10-15 09:00:07 EDT
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
-----
Comment 5 Mads Kiilerich 2012-10-15 09:05:19 EDT
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?
Comment 6 John Reiser 2012-10-15 09:42:34 EDT
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.
Comment 7 Mads Kiilerich 2012-10-15 13:20:05 EDT
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?
Comment 8 John Reiser 2012-10-15 16:08:50 EDT
"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.
Comment 9 Mads Kiilerich 2012-10-15 17:03:01 EDT
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.
Comment 10 John Reiser 2012-10-15 17:40:15 EDT
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
# 
-----
Comment 11 Lingzhu Xiang 2012-12-07 04:39:49 EST
Likely the same issue as bug 859632. But try the patch in that bug to be sure.
Comment 12 Mads Kiilerich 2012-12-07 05:12:24 EST
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.
Comment 13 Juan Orti 2013-06-12 17:06:14 EDT
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.
Comment 14 Juan Orti 2013-06-12 17:08:39 EDT
Created attachment 760319 [details]
My grub.cfg

This is my grub.cfg. When I press 'e' to edit an entry, the system freezes.
Comment 15 Juan Orti 2013-07-04 11:35:50 EDT
I've upgraded to F19 and now I can edit the boot entries in graphical mode.

grub2-efi-2.00-23.fc19.x86_64
Comment 16 Fedora End Of Life 2013-12-21 04:07:23 EST
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.
Comment 17 Fedora End Of Life 2014-02-05 07:34:46 EST
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.

Note You need to log in before you can comment on or make changes to this bug.