grub-probe fails with btrfs root (and ext3 /boot)

[Jeff Waugh]

Binary package hint: grub2

grub-probe (and thus, update-grub) fails with a btrfs root, seemingly because it can't identify the type of filesystem. Although I can manually fix up /boot/grub/grub.cfg in order to boot (which works as expected), lack of update-grub love is inconvenient. ;-)

jdub@fehung:~$ sudo update-grub
grub-probe: error: cannot find a device for /.

jdub@fehung:~$ sudo grub-probe /
grub-probe: error: cannot find a device for /.

jdub@fehung:~$ mount | grep ^/
/dev/sda2 on / type btrfs (rw,errors=remount-ro)
/dev/sda1 on /boot type ext3 (rw,relatime,errors=remount-ro)

ProblemType: Bug
Architecture: i386
Date: Tue Oct 13 21:54:20 2009
DistroRelease: Ubuntu 9.10
Package: grub2 (not installed)
ProcEnviron:
 LANGUAGE=en_AU.UTF-8
 PATH=(custom, user)
 LANG=en_AU.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-13.44-generic
SourcePackage: grub2
Uname: Linux 2.6.31-13-generic i686

[Jeff Waugh (jdub)]

Oh, and the device map is fine, so it's not that...

jdub@fehung:~$ cat /boot/grub/device.map
(hd0) /dev/sda

[alien8 (fb-alien8)]

Just a note,

1) Not surprisingly, doesn't work on amd64 as well.
2) Good old grub 0.97 is not complaining when /boot has it's own partition.

Frank

[Iain Buclaw (iainb)]

Is anything happening with this upstream?

I've managed to get grub2 working via backporting the legacy 0.97 shell probe functions into the grub-mkconfig_lib file. But this doesn't really seem right.
Attached my changes against this post anyway for people to see.

Regards
Iain

[Carey Underwood (cwillu)]

A simpler change would be to to add "|| true" to the end of the "GRUB_DEVICE=..." line in grub-mkconfig, and then set your root device by hand in /etc/default/grub, or something along those lines.

[Abrahm Scully (abrahm-scully)]

By changing grub-mkconfig, update-grub no longer fails and I can produce a valid grub.cfg. However, grub still fails at boot with "Unknown Filesystem" in up-to-date ubuntu karmic and leaves you at the rescue prompt.

However, I can boot to a root btrfs filesystem.

My setup:
/dev/sda1 is /boot (ext2)
/dev/sda2 is / (btrfs)
Rebuild your initrd after adding btrfs, libcrc32c, crc32c, and zlib_deflate /etc/initramfs-tools/modules.

The grub rescue commands go something like this:
set prefix=(hd0,1)/grub
insmod linux
linux (hd0,1)/vmlinuz-2.6.... rootfstype=btrfs root=/dev/sda2 ro
initrd (hd0,1)/initrd-2.6....

Since I don't boot so often, I'm happy to have this working.

[Abrahm Scully (abrahm-scully)]

Please excuse me. My failure to boot was solved by re-running grub-install after I added my seperate /boot partition.

[Claes Wallin (clacke)]

This is more serious than it seems, not simply a matter of convenience. Packages like desktop-base, which runs update-grub in postinst, fail to install properly when running on a btrfs root.

[Ben Gamari (bgamari)]

This seems to be a pretty good workaround allowing manual override of the root device. Simply drop a GRUB_DEVICE=/dev/... line into /etc/default/grub and things should just work again. Certainly not a permanent solution, but then again btrfs has quite a while until it sees usage outside of testing.

[Iain Buclaw (iainb)]

Well since everyone seems pretty much fixed on the idea that static GRUB_DEVICE and GRUB_DEVICE_UUID entries are ok, just have two posing questions.

How do you suppose we get those entries there in the first place?
What would we do in the event that a UUID changes (if unlikely, I know :) ?

Or are we just going to leave that up to the distribution/user to figure out, afterall btrfs is still not production ready, and it is still technically the fault of btrfs not exporting it's internal relationships between physical and virtual devices that we have this problem in the first place.

For the time being, however, I have my eyes pinned here: http://article.gmane.org/gmane.comp.file-systems.btrfs/2856
This seems like a sound idea, but may chime in saying I would still rather LVM-style /dev/mapper locations.

Regards
Iain

[Ben Gamari (bgamari)]

I definitely wouldn't call the GRUB_DEVICE solution acceptable. Btrfs is still quite new and I don't think it makes sense to merge it hacks like this. I believe that this is a case where the bleeding edge users should need to build their own packages and maintain their own configuration. Trying to handle cases like changing UUIDs completely defeats the purpose of a hack which only exists because btrfs doesn't yet have a mechanism for identifying devices to user space.
The solution you cite does look promising, although it would be nice if there were some actual code behind it.

[KOCMOHABT (kocmo)]

If your btrfs root partition is on top of any crypto devices, you'll be also affected by bug #551055. I posted a procedure for Ubuntu Karmic in comment 4 there, involving instructions from both threads. It restores full automagic functionality both for update-grub and update-initramfs.

[KOCMOHABT (kocmo)]

Upgraded to Ubuntu Lucid, this bug no longer applies; update-grub runs fine. If you got your btrfs root partition on top of crypto, bug #551055 still applies.

[Chow Loong Jin (hyperair)]

Marking invalid as per last comment.

[Claes Wallin (clacke)]

I'm running Lucid, and update-grub still fails in the same way.

Adding GRUB_DEVICE in /etc/default/grub is not enough, you also need the "|| true" patch, because the script (grub-mkconfig) always tests for root, before it even loads /etc/default/grub.

For me an acceptable fix would be that if GRUB_DEVICE is set in default/grub, then don't run the test.

Is there any other way to indicate a btrfs volume for root than using /dev/whatever? Saying that a certain block device is root isn't really btrfs'y, since one block device may contain more than one volume, and may contain less than all of one volume. Does root= accept anything like BTRFSVOL=asdf or equivalent?

[Colin Watson (cjwatson)]

Maybe it's fixed for some people but apparently not for everyone. In any case I think I understand what's going on here (we should be using statvfs, or something like that) so please leave this open.

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 1.98+20100614-1ubuntu1

---------------
grub2 (1.98+20100614-1ubuntu1) maverick; urgency=low

  * Resynchronise with Debian:
    - Add btrfs probing support, currently only in the single-device case
      (LP: #450260).
    - Insert partmap module in prepare_grub_to_access_device to handle
      cross-partmap setups (LP: #451585).
    - Fix verbose error output when device-mapper isn't supported by the
      running kernel (LP: #526045).
    Remaining changes:
    - Adjust for default Ubuntu boot options ("quiet splash").
    - Default to hiding the menu; holding down Shift at boot will show it.
    - Set a monochromatic theme for Ubuntu.
    - Apply Ubuntu GRUB Legacy changes to legacy update-grub script: title,
      recovery mode, quiet option, tweak how memtest86+ is displayed, and
      use UUIDs where appropriate.
    - Fix backslash-escaping in merge_debconf_into_conf.
    - Remove "GNU/Linux" from default distributor string.
    - Add crashkernel= options if kdump and makedumpfile are available.
    - If other operating systems are installed, then automatically unhide
      the menu. Otherwise, if GRUB_HIDDEN_TIMEOUT is 0, then use keystatus
      if available to check whether Shift is pressed. If it is, show the
      menu, otherwise boot immediately. If keystatus is not available, then
      fall back to a short delay interruptible with Escape.
    - Allow Shift to interrupt 'sleep --interruptible'.
    - Don't display introductory message about line editing unless we're
      actually offering a shell prompt. Don't clear the screen just before
      booting if we never drew the menu in the first place.
    - Remove some verbose messages printed before reading the configuration
      file.
    - Suppress progress messages as the kernel and initrd load for
      non-recovery kernel menu entries.
    - Keep the loopback file open so that subsequent changes to the "root"
      environment variable don't affect it.
    - Change prepare_grub_to_access_device to handle filesystems
      loop-mounted on file images.
    - Ignore devices loop-mounted from files in 10_linux.
    - Show the boot menu if the previous boot failed, that is if it failed
      to get to the end of one of the normal runlevels.
    - Handle RAID devices containing virtio components.
    - Don't generate /boot/grub/device.map during grub-install or
      grub-mkconfig by default.
    - Store grub-pc/install_devices as persistent device names under
      /dev/disk/by-id/.
    - Change priority to optional to match the priority of grub.
    - Don't display "GRUB loading" unless Shift is held down.
    - Adjust versions of grub-doc and grub-legacy-doc conflicts to tolerate
      our backport of the grub-doc split.
    - Fix LVM/RAID probing in the absence of /boot/grub/device.map.
    - Look for .mo files in /usr/share/locale-langpack as well, in
      preference.
    - Don't run /etc/grub.d/README, even if it somehow ended up being
      executable.
    - Make sure GRUB_TIMEOUT isn't quoted unnecessarily.
    - Probe all devices in 'grub-probe --target=drive' if
      /boot/grub/device.map is missing.
    - Adjust hostdisk id f...

[Nobu (benjo316)]

This seems to have regressed in grub2 1.99 on Natty, or else I've stumbled onto another problem.

Discussion started here: http://ubuntuforums.org/showthread.php?p=10183644

[Chow Loong Jin (hyperair)]

On Thursday 02,December,2010 07:29 AM, Nobu wrote:
> This seems to have regressed in grub2 1.99 on Natty, or else I've
> stumbled onto another problem.
>
> Discussion started here:
> http://ubuntuforums.org/showthread.php?p=10183644
>

Yeah, it doesn't work on my Maverick system either, using a cryptsetup/LVM
solution. Perhaps it works on more conventional setups.

  affects ubuntu/grub2
  status confirmed

--
Kind regards,
Loong Jin

[Colin Watson (cjwatson)]

Please file a new bug with full details, rather than reopening this one. It's unlikely to be quite the same cause.