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-dae...@googlemail.com> wrote: > Delivery to the following recipient failed permanently: > > 701...@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 <shackl...@gmail.com> > Date: Wed, 3 Jul 2013 23:13:33 +1000 > Message-ID: > <cajbol970elfvegavu5a+wujrx-na7ysvb1mtgdl1w3ra56r...@mail.gmail.com> > Subject: Re: Bug#701956: btrfs can't fsck /run/rootdev on boot > To: 701936 <701...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
