Bug 448255 - Unreported GRUB installation failure
Unreported GRUB installation failure
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
11
All Linux
low Severity low
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-24 22:07 EDT by Sam Varshavchik
Modified: 2009-10-15 08:39 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-15 08:39:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screen capture of the Anaconda grub install failure (1.43 MB, image/jpeg)
2008-05-24 22:07 EDT, Sam Varshavchik
no flags Details

  None (edit)
Description Sam Varshavchik 2008-05-24 22:07:34 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.
Comment 1 Sam Varshavchik 2008-05-24 22:07:34 EDT
Created attachment 306594 [details]
Screen capture of the Anaconda grub install failure
Comment 2 Chris Lumens 2009-05-19 15:19:40 EDT
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.
Comment 3 Bug Zapper 2009-06-09 21:09:18 EDT
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
Comment 4 Sam Varshavchik 2009-06-12 22:37:00 EDT
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.
Comment 5 Sam Varshavchik 2009-06-21 15:17:24 EDT
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.
Comment 6 Radek Vykydal 2009-06-26 05:57:11 EDT
Could you please test if
http://rvykydal.fedorapeople.org/updates.upgf11.img
fixes the issue?
Comment 7 Sam Varshavchik 2009-06-26 06:59:09 EDT
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.
Comment 8 Radek Vykydal 2009-06-26 07:24:14 EDT
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
Comment 9 Sam Varshavchik 2009-06-27 00:52:56 EDT
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.
Comment 10 Radek Vykydal 2009-06-29 06:04:39 EDT
(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.
Comment 11 Radek Vykydal 2009-10-15 08:39:20 EDT
Bug from comment #5 should be fixed in version 12.0-1 of anaconda (F12). Thanks for the report.

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