Red Hat Bugzilla – Bug 448255
Unreported GRUB installation failure
Last modified: 2009-10-15 08:39:20 EDT
Description of problem: F8 upgraded to F9 on multiple machines. Two of the machines had F8 installed on a RAID-1 partition (/dev/md??). GRUB failed to install on these two machines, however the failure was not reported by Anaconda. After all the packages were updated, it proceeded to install the bootloader configuration; then claimed that the installation is completed, ejected the DVD, and prompted to reboot. The first machine had two SCSI hard drives (aic79xx.ko): /dev/md1 on / type ext3 (rw) /dev/md0 on /boot type ext3 (rw) Upon reboot, GRUB dropped into its "minimal shell". It did not load grub.conf. Rescue mode produced the following results: * /mnt/sysimage had a succesfull F9 install sitting on it. * After chrooting to /mnt/sysimage, running "/sbin/grub-install /dev/sda" fails with an error message saying that grub cannot map boot devices. * Inside /mnt/sysimage, /etc/mtab is a plain file, left over from the F8 shutdown. After replacing /etc/mtab with a soft link to /proc/mounts, "/sbin/grub-install /dev/sda" succeeds, and the machine subsequently boots F9 succesfully. * Before rebooting, the /etc/mtab soft link must be restored to a plain, empty file, otherwise initscripts, on the subsequent reboot, has a heartburn. This is arguably an initscript bug, since it should clear out /etc/mtab on each boot. Since Anaconda did not report any errors installing a bootloader, I was unaware of the problem until I rebooted. When I upgraded a second machine that had F8 installed on a pair of SCSI drives in RAID-1, prior to rebooting I flipped through the virtual screens, and captured an error message on one of the ttys. I could only capture this image by taking a screendump. See attachment. The attachment is a screen cap of the error message on one of the ttys just before Anaconda finishes, from the second machine with a RAID-1 install. Anaconda also apparently exhibits a second, closely-related bug, on the second machine. I believe that it's a different bug because only the second machine also has an IDE hard drive, which is a factor in the second bug. Conclusion: /sbin/grub-install apparently needs to read /etc/mtab when it gets invoked with F9 installed on /dev/mdxx, which is set up as two SCSI hard drives in a RAID-1 configuration.
Created attachment 306594 [details] Screen capture of the Anaconda grub install failure
Can you please retest with F11 when it is release and let us know if this is still an issue for you? There's been a significant amount of work involving storage, RAID, and bootloader installation for this release. Thanks.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Retested with F11, problem still exists. After upgrading from F10 to F11, the subsequent reboot threw me into the grub shell. I had to manually mount the partition and load the config file from the grub shell, boot, and rerun /sbin/grub-install, to restore normal boot configuration. After rebooting, I see no errors in /root/upgrade.log. I'll be upgrading more machines from F10 to F11, in the coming weeks, let me know if you want me to grab something while anaconda is still doing its thing.
Repeating F10 -> F11 upgrade on another machine, grub failed to install again. I captured the following output on tty5, at the end of the installation process: GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> root (hd0,1) Filesystem type is ext2fs, partition type 0x83 grub> GNU GRUB version 0.97 (640K lower / 3072K upper memory) [ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 p (hd0,1)/grub/grub.conf Error 12: Invalid device requested grub> That's the error that's causing grub installation to fail.
Could you please test if http://rvykydal.fedorapeople.org/updates.upgf11.img fixes the issue?
What's that -- a replacement installer initrd image? I presume it's 32bit. I do have one more 32 bit machine to upgrade, but I also have several 64 bit machines too, that I need to do.
It is runtime updates image (http://fedoraproject.org/wiki/Anaconda/Updates) When installing/upgrading, add boot option: linux updates=http://rvykydal.fedorapeople.org/updates.upgf11.img
Tried to upgrade my next machine. * Booted with the given option * Got the "Retrieving update from <url>" message * Grub got installed without errors, however: * On the ALT-F5 screen I spied two messages, verbiage is approximate: Retrieving update from <url> Error mounting /dev/loop7 on /tmp/update.img: (null) This updates.upgf11.img file reads as a gzipped cpio archive. If I did not actually end up loading this update, there was no indication to that effect in the actual anaconda GUI, and on this specific laptop the original bug was not reproduced, but I still have several more machines to upgrade. The alternative explanation is that after failing to loopback-mount the update, anaconda's plan B was to try read the update as a gzipped cpio archive, in which case the update might have worked.
(In reply to comment #9) > The alternative explanation is that after failing to loopback-mount the update, > anaconda's plan B was to try read the update as a gzipped cpio archive, in > which case the update might have worked. Yes, that's what happened I think. You can check for the presence of update files during install on tty2 by looking into /tmp/updates directory.
Bug from comment #5 should be fixed in version 12.0-1 of anaconda (F12). Thanks for the report.