Your message dated Mon, 29 Jul 2013 15:55:11 +0100
with message-id
<canbhlug67pcvcnzaaesywzsfi-0psc3+83x7vbhc5wo-vzt...@mail.gmail.com>
and subject line Btrfs & SysV init
has caused the Debian Bug report #701936,
regarding btrfs can't fsck /run/rootdev on boot with sysvinit
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
701936: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701936
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: btrfs-tools
Version: 0.19+20130131-2
Severity: critical
Justification: renders systems with btrfs as root file-system unbootable
Hi,
Axel Beckert wrote on Wed, 27 Feb 2013 20:01:30 +0100:
> > btrfs-tools (0.19+20130131-2) unstable; urgency=low
> > .
> > * Replacing fsck.btrfs with wrapper arround 'btrfs check' to avoid
> > different behaviour based on the filename btrfs is copied to (Closes:
> > #701776).
>
> Thanks for the quick fix, but unfortunately the problem persists, just
> with a different error message and a different exit-code, but with the
> same symptom: The system fails to start.
>
> check_mounted(): Could not open /run/rootdev
> Could not check mount status: No such device or address
> fsck died with exit status 250
There's one more confirmation that there's still an issue which breaks
systems, even with the newest version, at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701776#65
Additionally, several people contacted me on Jabber/IRC about how to
fix this issue, too, so I'm posting a recipe at the end of this mail
and also Cc this mail to #701776.
> Do you have any preference if #701776 should be reopend or if a new
> bug should be filed for that?
Since I didn't get a reply from Daniel on this question within a day,
I'm herewith filing a new bug report as the issue may have a different
cause despite very similar symptoms and the affected systems still
being broken if you don't downgrade btrfs-tools to 0.19+20121004-1 or
earlier.
As I already wrote in #701776, I consider such breakage of severity
critical since http://www.debian.org/Bugs/Developer.en.html#severities
defines "critical" as "makes unrelated software on the system (or the
whole system) break". I see this condition as given.
For all those who are also suffering from this issue, too, here's the
recipe how I downgraded btrfs-tools to the version from testing again
on my system:
At the maintenance mode password prompt, enter the root password.
You may need to add /sbin and /usr/sbin to the path depending on your
login shell setup. Thanks Christian Stalp!
# export PATH="/sbin:/usr/sbin:$PATH"
With the default setup, sourcing /etc/profile should suffice.
# . /etc/profile
Mount the root file system read-write:
# mount -o remount,rw /
Mount the /boot partition, if existing:
# mount /boot
Either get network, ...
# dhclient eth0
(Since Julien Cristau NMUed btrfs-tools in Wheezy yesterday[1], you
may want to update your package lists, too.)
# apt-get update
..., fetch the version from testing (assuming you have a deb-line with
testing in your sources.list, too) and downgrade to it, ...
# apt-get install -t testing btrfs-tools
... or, if you haven't done "apt-get clean" for a while, you may be able to
just do
# dpkg -i /var/cache/apt/archives/btrfs-tools_0.19+20121004-1_*.deb
Then call sync to make sure the new version is on disk:
# sync
and reboot, e.g. by pressing Ctrl-D.
That way, both, Christian and me got working systems back again.
[1] http://packages.qa.debian.org/b/btrfs-tools/news/20130228T204729Z.html
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
--- End Message ---
--- Begin Message ---
I believe since sysvinit -42 upload, it is possible to correctly boot
btrfs systems with sysvinit, since this particular problem has been
worked around.
I do understand a general desire for a proper and better behaved
fsck.btrfs. And that's something I will continue to work towards.
But this bug per se (can't boot), is resolved for now.
Regards,
Dmitrijs.
--- End Message ---