Bug 748121 - grub2 bootloader install failed to boot block of btrfs partition
grub2 bootloader install failed to boot block of btrfs partition
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: grub2 (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
:
Depends On: 728742
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-22 04:53 EDT by Henrik Nordström
Modified: 2012-06-02 09:14 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 728742
Environment:
Last Closed: 2012-06-02 09:14:53 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)
F16 Final TC2 anaconda.log (50.20 KB, text/plain)
2011-10-22 04:54 EDT, Henrik Nordström
no flags Details
F16 Final TC2 program.log (228.04 KB, text/plain)
2011-10-22 04:54 EDT, Henrik Nordström
no flags Details

  None (edit)
Description Henrik Nordström 2011-10-22 04:53:38 EDT
Description of problem:

During dialogs for fresh install from DVD (Fedora 16 Final TC2), I chose to install boot loader to boot block of btrfs boot partition.  After all packages had been installed, I got a dialog box "Bootloader: An error occurred while installing the bootloader.  The installed system might not be bootable."

Version-Release number of selected component (if applicable):
anaconda-16.22 (F16 Final TC2 compose)
grub2-1.99-9.fc16


How reproducible:

Every time

Steps to Reproduce:
1. Fresh install from Fedora 16 Final TC2
2. Select to format /boot as btrfs
3. Choose Install bootloader to boot block of boot partition.
 
Actual results:

After all packages have been installed, dialog box appears " Bootloader: An error occurred while installing the bootloader.  The installed system might not be bootable." and no bootloader was installed.

Expected results: success.


Additional info:

Manually running "grub2-install --force /dev/sda2" from chroot into /sysroot installs grub as expected. 

Installed system did boot properly after manually installing the bootloader.

anaconda.program.log ends with

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.


If redoing the exact same installation but selecting the default ext4 for /boot then the bootloader installs fine.
Comment 1 Henrik Nordström 2011-10-22 04:54:15 EDT
Created attachment 529587 [details]
F16 Final TC2 anaconda.log
Comment 2 Henrik Nordström 2011-10-22 04:54:55 EDT
Created attachment 529588 [details]
F16 Final TC2 program.log
Comment 3 Sandro Mathys 2011-11-02 08:52:30 EDT
Still reproducible with F16 Final RC4. :/
Comment 4 David Lehman 2011-11-02 10:59:56 EDT
Seems like, on btrfs, grub2 recognizes '/dev/sda' but does not recognize '(hd0,2)'. Seems like a grub2 bug to me.
Comment 5 Mads Kiilerich 2011-11-02 11:26:39 EDT
So essentially a duplicate of bug 748071 ?
Comment 6 Henrik Nordström 2011-11-03 05:06:01 EDT
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.
Comment 7 Mads Kiilerich 2011-11-03 09:25:07 EDT
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
Comment 8 Henrik Nordström 2011-11-03 11:04:13 EDT
From what I recall both /dev/sda2 and '(hd0,2)' worked. But I will try again with RC5.
Comment 9 Mads Kiilerich 2011-11-03 11:29:11 EDT
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
Comment 10 Henrik Nordström 2011-11-03 19:34:00 EDT
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.
Comment 11 Henrik Nordström 2011-11-03 19:45:17 EDT
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.
Comment 12 Mads Kiilerich 2011-11-09 18:52:04 EST
Bug 751728 (grub2 gets confused when / is btrfs and /boot is a subvolume) might be related.
Comment 13 Vladimir Serbinenko 2012-06-02 07:27:56 EDT
Installing using blocklists on btrfs isn't sane, especially given that alternative (install using btrfs embedding zone) already works. This bug should be closed.
Comment 14 Mads Kiilerich 2012-06-02 09:14:53 EDT
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.

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