Bug 748121

Created attachment 529587 [details]
F16 Final TC2 anaconda.log

Created attachment 529588 [details]
F16 Final TC2 program.log

Still reproducible with F16 Final RC4. :/

Seems like, on btrfs, grub2 recognizes '/dev/sda' but does not recognize '(hd0,2)'. Seems like a grub2 bug to me.

So essentially a duplicate of bug 748071 ?

I don't know who is at fault here, but as I said earlier chrooting into the installed tree and running the grub2 installation manually from the console works somehow. Also works fine to reinstall grub2 after booting F16.

22:20:21,800 INFO program: Running... grub2-set-default Fedora Linux, with Linux 3.1.0-0.rc10.git0.1.fc16.x86_64
22:20:21,996 INFO program: Running... grub2-mkconfig -o /boot/grub2/grub.cfg
22:20:23,448 ERR program: Generating grub.cfg ...
22:20:23,479 ERR program: cat: /boot/grub2/video.lst: No such file or directory
22:20:23,872 ERR program: Found linux image: /boot/vmlinuz-3.1.0-0.rc10.git0.1.fc16.x86_64
22:20:23,911 ERR program: Found initrd image: /boot/initramfs-3.1.0-0.rc10.git0.1.fc16.x86_64.img
22:20:28,094 ERR program: done
22:20:28,752 INFO program: Running... grub2-install --force --no-floppy (hd0,2)
22:20:30,901 ERR program: /sbin/grub2-setup: error: unable to identify a filesystem in hd0; safety check can't be performed.

The video.lst error message has been solved by Bug 736993, so logs from rc4 or later would perhaps make it more clear what the real problem is.

Henrik, how do you install grub manually? Do you specify /dev/sda2 or (hd0,2)?

David, grub2 do not claim to support '(hd0,2)'; according to the documentation it should be '(hd0,gpt2)' or '(hd0,msdos2)'. It kind of makes sense that it needs to know which of the partition tables it should use if both are present. That might have changed between the pre-1.99 snapshot and the real 1.99.
http://www.gnu.org/software/grub/manual/grub.html#Naming-convention

From what I recall both /dev/sda2 and '(hd0,2)' worked. But I will try again with RC5.

I guess it could be interesting to see if manual installation from a console immediately after anaconda has failed would work, or if there is something that do that the commands only work after a reboot.

These commands could perhaps also give an idea of what grub can and can't detect:
grub2-probe --device /dev/sda -t partmap
grub2-probe --device /dev/sda2 -t partmap
grub2-probe --device /dev/sda2 -t fs

Problem still exists in RC5 when tested in KVM, but in slightly different form. Same result, but other error messages, now complaining that /grub2/core.img can not be read correctly.

To reproduce the error in KVM by sure there is a DOS label on the virtual disk and selecting to format /boot as btrfs and select to install the bootloader on the boot partition and not MBR.

Unfortunately I pressed the wrong button just after installation failure so it rebooted before I had a chance to try the grub2-probe commands directly after installation.

As in Final TC2 it seems to work fine if /boot is formatted using ext4. The problem only shows up if /boot is formatted using btrfs.

even more strange. Seems to be timing related somehow. It works if grub2-install is retried a number of times, and then continues working until the files are removed from /boot/grub2/ in which case it again fails a number of times before starting to succeed again.

Think this really is a grub2 bug, where it forgets do prepare properly for blocklist loading of core.img from btrfs. needs to both fsync the file and set the immutable flag for blocklist generation to be ok and I think it does neither. fsync to make sure the blocks have been written (block allocation is delayed in btrfs), immutable to lock them in place (btrfs may move stuff around otherwise).

Anaconda should be corrected to use the supported device partitioning naming model for grub2. But that seems to be completely unrelated to the issue seen here.

Regarding bug 748071, these two are related but different.

Fixing 748071 works around this bug as it avoids blocklist loading from btrfs entirely, at least for as long as core.img fits in the btrfs boot area.

this bug is about failing to install in blocklist mode loading core.img from grub2/core.img when /boot is btrfs.

748071 is an enhancement request to utilize the relatively big boot area of btrfs to embed core.img as raw blocks outside the filesystem as such, avoiding to need to resort to blocklist loading of core.img.

A workaround which seems to work is to

grub2-install ...
if failed
  sync
  grub2-install
endif
if btrfs
  chattr +i /boot/grub2/core.img
endif

the chattr needs to be verified if really needed, but is probably wise. Probably even for ext4.

Bug 751728 (grub2 gets confused when / is btrfs and /boot is a subvolume) might be related.

Installing using blocklists on btrfs isn't sane, especially given that alternative (install using btrfs embedding zone) already works. This bug should be closed.

Closing. blockslists on btrfs will not be supported. Other bugs might have led in that direction, but these bugs should be fixed. Especially the anaconda support for btrfs will have to be reworked anyway.