fsck.btrfs not found in the system

Bug #660649 reported by BSA on 2010-10-14
78
This bug affects 13 people
Affects Status Importance Assigned to Milestone
btrfs-tools (Debian)
New
Undecided
Unassigned
btrfs-tools (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: btrfs-tools

$ lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10
$ grep btrfs /var/log/boot.log
fsck: fsck.btrfs: not found
fsck: Error 2 while executing fsck.btrfs for /dev/sdb2
$ dpkg-query -S fsck.btrfs
dpkg: *fsck.btrfs* not found.
$ which fsck.btrfs
$ locate fsck |grep btrfs
/sbin/btrfsck
/usr/share/man/man8/btrfsck.8.gz

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: btrfs-tools 0.19+20100601-3
ProcVersionSignature: Ubuntu 2.6.35-22.34-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Thu Oct 14 20:37:16 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
ProcEnviron:
 LANG=ru_RU.utf8
 SHELL=/bin/bash
SourcePackage: btrfs-tools

Related branches

BSA (b-s-a) wrote :
god (humper) wrote :

confirm - same here: "fsck: fsck.btrfs: not found" appears during boot, 10.10 x86_64

Gary M (garym) wrote :

The fsck,btrfs symlink was deliberately removed upstream, as btrfsck is far from complete and does not support the various command line options used to invoke it at boot time (bug #460246).

Changed in btrfs-tools (Ubuntu):
status: New → Confirmed
Evan Prodromou (evanprodromou) wrote :

So is this properly a bug on mountall, then?

Gary M (garym) wrote :

@evan : I see the current behaviour of mountall as a feature, as I'm happy to be reminded that btrfs is still a "work in progress". A better btrfs repair tool may appear upstream soon and make it into the natty release.

Loïc Minier (lool) wrote :

See also bug #460246

Loïc Minier (lool) wrote :

I've pushed a btrfs-tools package in my PPA with the symlink and a patch to skip "-*" flags passed to btrfsck; would someone please test it? I can test on armel, but I don't have an armel build of it (and I'm lazy).

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package btrfs-tools - 0.19+20100601-3ubuntu2

---------------
btrfs-tools (0.19+20100601-3ubuntu2) natty; urgency=low

  * New patch, ignore all arguments starting with "-" as to be compatible with
    the way mountall and other programs call fsck.btrfs (for instance with
    -a); this helps checking of btrfs filesystems by mountall on boot, but the
    proper fix would be to implement support for these flags; patch by
    Sten Heinze found in Debian #567681; LP: #460246.
  * Re-add fsck.btrfs -> btrfsck symlink; LP: #660649.
 -- Loic Minier <email address hidden> Wed, 30 Mar 2011 16:32:20 +0200

Changed in btrfs-tools (Ubuntu):
status: Confirmed → Fix Released
Andrius Štikonas (stikonas) wrote :

After this update btrfsck does full disk scan on every boot which is not a good idea. Probably btrfsck does not yet mark filesystem as clean after checking it and btrfsck only checks filesystem, it cannot repair filesystem yet, so maybe it would be better to wait until C. Mason release his new btrfs tool before running it on each boot.

DavidEscott (david-escott) wrote :

btrfs check is adding ~75 seconds to my boot. I would like to see this symlink removed until the tools works better.

Joke de Buhr (joke) wrote :

In my case the symblink adds about 20 minutes to my boot.

Id2ndR (id2ndr) wrote :

In my case it adds 4 seconds (root partition on my SSD).

|I've also got this problem on debian and ubuntu

but i had to manually create the symlink from btrfsck to fsck.btrfs
but now i get an error about -a

it goes past too fast to write down but it is about -a

Joke de Buhr (joke) wrote :

Well you can always disable the filesystem check via /etc/fstab. Just set the value in the sixth column to 0. This way fsck assumes the filesystem doesn’t need to be checked ever and fsck.btrfs will never be run. But you have to remember enable the check later on if a proper fsck.btrfs has been released.

Carey Underwood (cwillu) wrote :

Really, it should be treated the same way as fsck.xfs: fsck.btrfs being a no-op, with a message for a user to invoke btrfsck if they want to do a manual check.

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