[natty] btrfs "grub-probe: error: unknown filesystem"

Bug #732149 reported by Id2ndR on 2011-03-09
104
This bug affects 17 people
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
High
Colin Watson
Natty
High
Colin Watson

Bug Description

Binary package hint: grub2

With yesterday update, grub appears to be broken now.

yesterday : $ sudo grub-probe /
btrfs
now : $ sudo grub-probe /
grub-probe: error: unknown filesystem.

When rebooting the machine :
could not find the chunk descriptor

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: grub-common 1.99~rc1-3ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-5.32-generic 2.6.38-rc6
Uname: Linux 2.6.38-5-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
CheckboxSubmission: 1085bd3e1d3dc5fdefc443fc7f3687c2
CheckboxSystem: f78c696d4c0399fa91f9da1b540d7fd0
Date: Wed Mar 9 18:40:04 2011
EcryptfsInUse: Yes
ProcEnviron:
 LANGUAGE=fr_FR:fr:en_GB:en
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: grub2
UpgradeStatus: Upgraded to natty on 2011-03-01 (7 days ago)

Id2ndR (id2ndr) wrote :
Id2ndR (id2ndr) wrote :

Fixed with yesterday updates

Changed in grub2 (Ubuntu):
status: New → Fix Released
Nagy Ferenc László (nfl) wrote :

Hi! I've just updated Natty after about a week, and my postinstall scripts fail with
Generating grub.cfg ...
/usr/sbin/grub-probe: error: unknown filesystem.

Now I've purged everything grub, and reinstalled grub-common (1.99~rc1-4ubuntu1), but still
$ sudo grub-probe /
grub-probe: error: unknown filesystem.

I can't install grub-pc, because it aborts with
Creating config file /etc/default/grub with new version
/usr/sbin/grub-probe: error: unknown filesystem.
Auto-detection of a filesystem of /dev/sda3 failed.
Please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <email address hidden>

Note that I don't even have /boot/grub/device.map. And I have btrfs root, which contains /boot. Is this a regression in the package? And what should I do before reboot? :-)

Colin Watson (cjwatson) wrote :

I don't think this is a regression, but it does seem that occasionally a btrfs filesystem gets into a state where GRUB can't read it. This may be a problem in btrfs or it may be a problem in GRUB; at the moment I can't tell. It would be good if we could debug it before you reboot, though.

Could you please provide the same grub-probe output, but this time with -vv rather than just -v?

Changed in grub2 (Ubuntu):
status: Fix Released → Incomplete
Colin Watson (cjwatson) wrote :

Incidentally, not having /boot/grub/device.map is normal on Ubuntu. We're trying to move away from this problematic concept.

Colin Watson (cjwatson) wrote :

Thanks! We're going to have to build a debug version of grub-probe to inspect this, I think, as there isn't quite enough information even in the -vv dump (which is the maximum verbosity available). How long can you hold out without rebooting?

In the meantime, there is a tool called btrfs-image which saves an image of all the metadata in your filesystem, but zeroes all the data, so that this can be used for filesystem debugging. Could you use this and send me the image? You can send it to <email address hidden> if you'd rather not attach it to a public bug report even with zeroed data.

Nagy Ferenc László (nfl) wrote :

Thank you. I'm fine without reboot as long as it works.

This is a test partition, probably doesn't contain too much private info.

Colin Watson (cjwatson) wrote :

Thanks. I think this reproduces the problem, and I'm analysing it (though it's the weekend, so there'll be some delay).

Changed in grub2 (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
importance: Undecided → High
status: Incomplete → Confirmed
Nagy Ferenc László (nfl) wrote :

Thank you. So now I'm free to do anything to make my system unbootable? I think I'll change grub-probe to echo "btrfs". Have a good weekend!

I'm actually not sure yet that btrfs-image gives me something I can
debug. It will take having a chance to sit down for an hour or two with
it, which may not happen until Monday.

Nagy Ferenc László (nfl) wrote :

I did an apt-get source grub-common to try to debug the issue, but the executable I built from source seems to work:

root@snoopy:/home/nfl# grub-probe -d /dev/sda3
grub-probe: error: unknown filesystem.
root@snoopy:/home/nfl# grub2-1.99~rc1/grub-probe -d /dev/sda3
btrfs

Nagy Ferenc László (nfl) wrote :

I did not apply the patches in the previous compilation.

Today I made packages with "apt-get build-dep grub-common" and "apt-get -b source grub-common", but looks like I used the filesystem too much, and now the original grub-probe binary detects btrfs, too. Sorry. Maybe the btrfs-image backup helps.

Id2ndR (id2ndr) wrote :

I've got the same behavior: it can work a time, but can break at anytime. I got a computer that display "grub rescue>" at boot without having applied any update the last time it started.

Nagy Ferenc László (nfl) wrote :

So I installed grub-pc without errors and finally rebooted my computer. The result is:

error: couldn't find the chunk descriptor.

Press any key to continue...

Actually I can't continue. Caps Lock and Scroll Lock flashes instead. Probably the filesystem was indeed damaged. (I had video related problems and blind reboots before.) I can access the partition from Maverick. Let me know if I can help anything.

Del (delonly) wrote :

I am having the same problem since yesterdays updates. Running Kubuntu 11.04 64-bit with btrfs root filesystem. After safe-upgrade I get the follwoing:

$ sudo grub-install /dev/sda
/usr/sbin/grub-probe: error: unknown filesystem.
Auto-detection of a filesystem of /dev/sda1 failed.
Please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <email address hidden>

Please inform if there is anything I can do to help.

Del (delonly) wrote :

Tried btrfsck, and got the following messages:

$ sudo btrfsck /dev/sda1
parent transid verify failed on 6690148352 wanted 22858 found 22860
parent transid verify failed on 6690148352 wanted 22858 found 22860
parent transid verify failed on 6690148352 wanted 22858 found 22860

AFAIK, there is no particular reason for this filesystem to be corrupt. No power outages have been experienced.

Nagy Ferenc László (nfl) wrote :

I think the btrfsck output may not be meaningful, as according to https://btrfs.wiki.kernel.org/index.php/Btrfsck, it can only be run on an unmounted FS.

Howdy, amateur here. My instinct is that this is not caused by a btrfs inconsistency/corruption/file system problem. The reason why is that I've had this problem twice now and the first time I "corrected" something in grub.cfg and/or reinstalled grub via chroot with liveCD (I'm not clear which did the trick) and it would boot again (after acknowledging a grub error "error: sparse file not allowed") but now I'm unable to do it again :( I have root on subvol @ and I'm using lzo compression. I've been running this since Alpha 1 I believe. I guess every time I update this is going to be a royal pain... Is there any way I can help? If anybody can tell me how to get this bootable again, I'd appreciate it.

Del (delonly) wrote :

With the latest updates it seems OK again. Currently I get the following output:

 $ sudo grub-install /dev/sda
 Installation finished. No error reported.

 $ sudo grub-probe -d /dev/sda1
 btrfs

Colin Watson (cjwatson) wrote :

Nothing has changed yet in GRUB - this is a transient error which comes
and goes, but that doesn't mean it's fixed.

Del (delonly) wrote :

Indeed, a reboot left me at the grub rescue prompt.

Nagy Ferenc László (nfl) wrote :

I tried to debug my "couldn't find the chunk descriptor" problem, and it fails at "if (csize <= 0)" in grub_btrfs_read_logical function. Seems like csize (grub_ssize_t) is 32 bits. Shouldn't it be 64 bits?

Nagy Ferenc László (nfl) wrote :

At "chunk_found" label I have:

addr: 0x10a981000
key->object_id: 0x100 (GRUB_BTRFS_OBJECT_ID_CHUNK)
key->type: 0xe4 (GRUB_BTRFS_ITEM_TYPE_CHUNK)
key->offset: 0x101c00000
chunk->type: 0x24 (GRUB_BTRFS_CHUNK_TYPE_DUPLICATED + 4)
chunk->size: 0x10000000
chunk->nstripes: 2

off = addr - grub_le_to_cpu64 (key->offset) = 0x10a981000 - 0x101c00000 = 0x8d81000
stripe_length = grub_divmod64 (grub_le_to_cpu64 (chunk->size),
                                             grub_le_to_cpu16 (chunk->nstripes),
                                             NULL) = 0x8000000
csize = stripe_length - off = 0x8000000 - 0x8d81000

csize will be negative => "couldn't find the chunk descriptor"

Hope this helps.

Id2ndR (id2ndr) wrote :

rootflags=subvol=@ seems not to be added anymore with latest grub update.

Colin Watson (cjwatson) on 2011-04-07
Changed in grub2 (Ubuntu):
status: Confirmed → Triaged
Martin Erik Werner (arand) wrote :

Just marked my Bug #752506 as a dupe of this.

I've had some luck reproducing this issue by repeatedly reinstalling the linux-image-2.6.38-8-generic and linux-headers2.6.38-8-generic packages, alternatively.

I've also quite often been able to get btrfs out of this "un-probe-able" state by just creating a standard snapshot:
mount /dev/sda5 /mnt
btrfs subvolume snapshot /mnt/@ /mnt/@"$(date +%s)"

But as mentioned it comes and goes very randomly still.

Colin Watson (cjwatson) on 2011-04-08
Changed in grub2 (Ubuntu Natty):
milestone: none → ubuntu-11.04-beta-2
Colin Watson (cjwatson) wrote :

I've managed to reproduce this and am debugging.

Changed in grub2 (Ubuntu Natty):
status: Triaged → In Progress
Colin Watson (cjwatson) wrote :

I've constructed a reproduction case and have asked Vladimir (upstream) to have a look at it. It's currently here:

  http://people.canonical.com/~cjwatson/tmp/btrfs-broken.img.xz

'grub-fstest `pwd`/btrfs-broken.img cp /@/boot/vmlinuz-2.6.38-8-generic-pae x' fails with this image, although Linux's btrfs driver seems to have no problems.

Colin Watson (cjwatson) on 2011-04-09
Changed in grub2 (Ubuntu Natty):
status: In Progress → Fix Committed
Michael Hope (michaelh1) wrote :

I ran across this with beta1 on a fresh install. grub-probe -vv is attached.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package grub2 - 1.99~rc1-10ubuntu1

---------------
grub2 (1.99~rc1-10ubuntu1) natty; urgency=low

  * Resynchronise with Debian. 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 and an aubergine background 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 option.
    - Bypass menu unless other OSes are installed or Shift is pressed.
    - Allow Shift to interrupt 'sleep --interruptible'.
    - Reduce visual clutter in normal mode.
    - Remove verbose messages printed before reading configuration.
    - Suppress kernel/initrd progress messages, except in recovery mode.
    - Handle filesystems loop-mounted on file images.
    - Ignore devices loop-mounted from files in Linux grub.d scripts.
    - Show the boot menu if the previous boot failed.
    - Don't generate device.map during grub-install or grub-mkconfig.
    - Adjust upgrade version checks for Ubuntu.
    - Suppress "GRUB loading" message unless Shift is held down.
    - Adjust versions of grub-doc and grub-legacy-doc conflicts.
    - Fix LVM/RAID probing in the absence of /boot/grub/device.map.
    - Look for .mo files in /usr/share/locale-langpack first.
    - Build-depend on qemu-kvm rather than qemu-system for grub-pc tests.
    - Add a grub-rescue-efi-amd64 package.
    - On Wubi, don't ask for an install device, but just update wubildr
      using the diverted grub-install.
    - Check hardware support before using gfxpayload=keep.
    - Build part_msdos and vfat into EFI boot images.
    - Put second and subsequent Linux menu entries in a submenu.
    - Preferred resolution detection for VBE.
    - Set vt.handoff=7 for smooth handoff to kernel graphical mode.
    - Fix use of freed memory when replacing existing loopback device.
    - Add grub-mount-udeb, containing just grub-mount.

grub2 (1.99~rc1-10) unstable; urgency=low

  * Update branch_butter.patch, fixing RAID1/duplicated chunk size
    calculation (thanks, Vladimir Serbinenko; LP: #732149).
 -- Colin Watson <email address hidden> Sun, 10 Apr 2011 00:12:09 +0100

Changed in grub2 (Ubuntu Natty):
status: Fix Committed → Fix Released
Rami Al-Rfou' (rmyeid) wrote :

This is the third time I get this problem ! I am not sure how I solved it the last two times, but it was running all the grub commands multiple times. Hope you guys publish more systematic way to fix it

Martin Erik Werner (arand) wrote :

If you are unable to boot as a result of similar symptoms as was seen in this bug (which should be fixed by now, presumably, comment/report new if not) there is a possible workaround to enable booting after the grub config file has been written whilst grub-probe is unable to detect the btrfs:

1. At the boot menu [e]dit the entry and look at the kernel line:
linux /vmlinuz-2.6.38-8-generic root=/dev/mapper/mellu-uburooot ro rootflags=subvol=@ quiet splash vt.handoff=7

3. IF the "rootflags=subvol=@" boot option is missing add it, and then boot the command list using ctrl+x

4. Once booted make sure that grub-probe detects the btrfs OK and then run update-grub.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers