[Pkg-sysvinit-devel] Bug#701956: btrfs can't fsck /run/rootdev on boot

[Ben Klein]

Bug still occurs with
* btrfs-tools 0.19+20130315-2
* sysv-rc 2.88dsf-41
* sysvinit 2.88dsf-41
* sysvinit-utils 2.88dsf-41
* initscripts 2.88dsf-41

I notice this bug has been reduced in severity from "critical" to
"important" again. Sorry, but I have to agree that it IS a critical
bug, unless systemd has suddenly become the standard init system.

Even worse, systemd is behaving incorrectly in this case, as it is
SKIPPING fsck instead of finding the root device some other way and
running fsck on that (though this would still trigger bug #712078). So
ultimately, the issue is either:
* in mountpoint's syscall for getting the device node, or
* in checkroot.sh which needs some btrfs-specific method to find the
correct argument to pass to btrfsck/btrfs check (taking subvolumes
into account)

I've attached an alternative patch for checkroot.sh that explicitly
checks for btrfs and, more importantly, triggers a warning when it is
detected.

On 3 July 2013 23:14, Mail Delivery Subsystem
<mailer-daemon at googlemail.com> wrote:
> Delivery to the following recipient failed permanently:
>
>      701936 at bugs.debian.org
>
> Technical details of permanent failure:
> Google tried to deliver your message, but it was rejected by the server for the recipient domain bugs.debian.org by buxtehude.debian.org. [140.211.166.26].
>
> The error that the other server returned was:
> 550 Unknown or archived bug
>
> ----- Original message -----
>
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
>         d=gmail.com; s=20120113;
>         h=mime-version:from:date:message-id:subject:to:content-type;
>         bh=px+OPpHGSuCWET/ZpEdvUogwdz8Bfdx76muBojFroOQ=;
>         b=m5JA2Cuz+AKixuGZFAICuH7T6qpL6Tfo6Vz9PrqdDjkQlcNdJUxWvaV5ZZNFhWQzNH
>          UgZcCs91sIm12KDvVDgqCbrc2/iiSAscOvF1mPtXlDcxsZJTKOinDZwl4MacnQcrjj3t
>          v4kWDd/a5A0xI6nikrsjuefnpX+Xr3DIc4tuwZB295rXbggx/yNo18hxHQ4e5a518Rsn
>          2Iv2wDxT2hA8E7dTUFSrFsLSJRi3HwqUy/H9WlNbbrkbcfEVoz5/s4rlpVh4fJtBxfFa
>          TKzKvx1jEVP8HCWr89SsxuqP69JVFQaQHQHloJQ7qTN6ov6Z5SfhMDX8hFmH+NxrGYp9
>          SE3g==
> X-Received: by 10.194.249.129 with SMTP id yu1mr627241wjc.10.1372857234000;
>  Wed, 03 Jul 2013 06:13:54 -0700 (PDT)
> MIME-Version: 1.0
> Received: by 10.216.231.72 with HTTP; Wed, 3 Jul 2013 06:13:33 -0700 (PDT)
> From: Ben Klein <shacklein at gmail.com>
> Date: Wed, 3 Jul 2013 23:13:33 +1000
> Message-ID: <CAJboL970ELfVEgaVu5a+WUjRx-NA7YSVb1MtGdL1w3Ra56RaZw at mail.gmail.com>
> Subject: Re: Bug#701956: btrfs can't fsck /run/rootdev on boot
> To: 701936 <701936 at bugs.debian.org>
> Content-Type: multipart/mixed; boundary=001a11c29996c2956804e09b3b40
>
> Bug still occurs with
> * btrfs-tools 0.19+20130315-2
> * sysv-rc 2.88dsf-41
> * sysvinit 2.88dsf-41
> * sysvinit-utils 2.88dsf-41
> * initscripts 2.88dsf-41
>
> I notice this bug has been reduced in severity from "critical" to
> "important" again. Sorry, but I have to agree that it IS a critical
> bug, unless systemd has suddenly become the standard init system.
>
> Even worse, systemd is behaving incorrectly in this case, as it is
> SKIPPING fsck instead of finding the root device some other way and
> running fsck on that (though this would still trigger bug #712078). So
> ultimately, the issue is either:
> * in mountpoint's syscall for getting the device node, or
> * in checkroot.sh which needs some btrfs-specific method to find the
> correct argument to pass to btrfsck/btrfs check (taking subvolumes
> into account)
>
> I've attached an alternative patch for checkroot.sh that explicitly
> checks for btrfs and, more importantly, triggers a warning when it is
> detected.