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.
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.
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.
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.
No further comments - let's assume it was a duplicate of 750794 *** This bug has been marked as a duplicate of bug 750794 ***