Ubuntu – Filesystem Label Rename

btrfs is considered experimental and unless you're very adventurous, you should avoid using it. There is neither a fsck tool available in case the btrfs filesystem becomes corrupt (after a power failure for example).

An excerpt from the release notes:

The btrfs filesystem is considered experimental in this release. It can generally be installed and used, but with a number of problems. You should only use it if you are comfortable with dealing with problems and helping us resolve them.

• As the btrfs wiki notes: "Note that Btrfs does not yet have a fsck tool that can fix errors. While Btrfs is stable on a stable machine, it is currently possible to corrupt a filesystem irrecoverably if your machine crashes or loses power on disks that don't handle flush requests correctly. This will be fixed when the fsck tool is ready."
• GRUB cannot detect a btrfs installation within an encrypted disk, and fails to set up the correct kernel parameters. (757631)

GRUB can actually boot from btrfs filesystems (instructions), but note that Ubuntu still consider btrfs as experimental.

OK after a bit of rummaging around I found a how-to too get rid of this problem at least temporarily it is fairly simple however I don't have my system set-up with btrfs so I can't confirm this fix.

either comment out or remove this line:

if [ -n ${have_grubenv} ]; then save_env recordfail; fi

or

if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env \
recordfail; fi; fi

in this file

/etc/grub.d/00_header

then run

update-grub

the reason for not editing /boot/grub/grub.cfg directly is that it will be over written every time grub is updated in this case you would only have to "re do" the fix if the grub common packages is updated.

This is the bug on launchpad if you want to add yourself bug #736743

Quoting Colin Watson from the bug report

This is actually a misleading error message: what's happening is that GRUB's btrfs implementation doesn't implement the file read hook interface for returning blocklists to calling code. I posted to grub-devel about this and the upstream maintainer pointed out that, even aside from multi-device problems, writing to btrfs from GRUB is fundamentally risky because:

the same block may be used by multiple snapshots every tree which uses a given block will contain its checksum, and so on recursively

However, btrfs reserves space at the start for the boot loader. This space is more than GRUB needs to embed itself, and so we could use 1KB of it for an environment block.

In any case, this is not a new problem that arose from using subvolumes, nor does it prevent booting (you get a spurious "Press any key to continue" prompt, but if you just ignore it it'll boot anyway). Downgrading to wishlist.

Hope this helps