Bug 753328 - grub2 boots into rescue mode after install; can't find RAID devices
Summary: grub2 boots into rescue mode after install; can't find RAID devices
Keywords:
Status: CLOSED DUPLICATE of bug 750794
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-11 21:22 UTC by Ryan Tokarek
Modified: 2012-04-16 21:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-04-16 21:58:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
install logs from a problem install (95.89 KB, application/x-gzip)
2011-11-24 02:36 UTC, Ryan Tokarek
no flags Details

Description Ryan Tokarek 2011-11-11 21:22:00 UTC
Description of problem:

After an install on md RAID mirrored drives, the system reboots into grub  rescue mode claiming it can't find the proper filesystem to boot from. This might be related to the closed bug 732164 (similar symptoms, but perhaps not the same problem?). 

System setup:

2 250G SATA drives
/dev/sd[ab]1 is a 500M md RAID 1 with an ext4 fs mounted at /boot
/dev/sd[ab]2 takes the remaining space, and is an md RAID 1 with logical volumes for /, /var, and /tmp

After the reboot from a clean install, grub throws an error "no such device" with the UUID of the fs on /boot, and enters rescue mode. Everything installs without apparent error. Waiting for the md RAIDs to finish syncing before rebooting doesn't seem to make any difference. 

If I drop to a shell at the end of the install process (right before the reboot), and run "grub2-install --boot-directory=/mnt/sysimage/boot /dev/sda", the command succeeds, but a subsequent reboot leads to the same error of not being able to find the /boot fs UUID device. 

The only solution I've found is to boot into rescue mode. Rescue mode can't find any Linux partitions to mount so the md RAIDs need to be assembled by hand (mdadm --assemble --scan), and the volume group changed to active (vgchange -a y /dev/vg0). Then /, and /boot need to be mounted by hand somewhere (like /mnt/sysimage). 

After this, a "grub2-install --boot-directory=/mnt/sysimage/boot /dev/sda" works, and a subsequent reboot works as expected. 

The only substantial differences I see in the broken vs. working grub2 directories is the presence of a load.cfg file, and differing core.img files. In the broken version, there is a load.cfg with the following contents (/boot/grub2/load.cfg):

   search.fs_uuid (uuid of /boot ext4 fs) root
   set prefix=($root)/grub2

After booting into rescue mode from the install disk, manually mounting filesystems and running grub2-install, the load.cfg file is gone, and core.img is different. All other files in the grub2 directory are identical between broken/working versions. No operations were done on any of the filesystems beyond mounting them. Nothing was done to the md RAIDs except to assemble them after a boot into rescue mode from the install disk (mdadm --examine --scan would find the RAIDs, but not get the kernel to load them). All the UUIDs mentioned in the files matched the real devices/file systems in both versions. 


Version-Release number of selected component (if applicable):

grub2-1.99-12.fc16.x86_64


How reproducible:

Always


Additional Notes:

I can do more testing if it would be helpful. I'm not sure what information would be most useful.

Comment 1 Mads Kiilerich 2011-11-17 21:28:53 UTC
Can you attach anaconda.log and program.log from the installer?

This issue shows many similarities with Bug 750794 . Something do that grub2 probing doesn't work at first but works after a reboot.

Comment 2 Ryan Tokarek 2011-11-24 02:36:59 UTC
Created attachment 535752 [details]
install logs from a problem install

Attached is a tarball of /root and /var/log/anaconda/ inside a directory install-logs.

Comment 3 Mads Kiilerich 2011-11-24 11:01:14 UTC
17:21:54,897 INFO program: Running... grub2-set-default Fedora Linux, with Linux 3.1.0-7.fc16.x86_64
17:21:55,066 INFO program: Running... grub2-install --no-floppy (hd0)
17:21:59,042 INFO program: Installation finished. No error reported.
17:21:59,043 INFO program: Running... grub2-install --no-floppy (hd1)
17:22:03,125 INFO program: Installation finished. No error reported.
17:22:03,126 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg
17:22:04,184 ERR program: Generating grub.cfg ...
17:22:04,611 ERR program: Found linux image: /boot/vmlinuz-3.1.0-7.fc16.x86_64
17:22:04,626 ERR program: Found initrd image: /boot/initramfs-3.1.0-7.fc16.x86_64.img
17:22:07,281 ERR program: done
17:22:08,339 INFO program: Running... grub2-install --no-floppy (hd0)
17:22:12,291 INFO program: Installation finished. No error reported.
17:22:12,292 INFO program: Running... grub2-install --no-floppy (hd1)
17:22:16,283 INFO program: Installation finished. No error reported.

So yes, I think it looks a lot like the problem I mentioned in comment 1.

Comment 4 Mads Kiilerich 2012-04-16 21:58:15 UTC
No further comments - let's assume it was a duplicate of 750794

*** This bug has been marked as a duplicate of bug 750794 ***


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