Ah. Thank you for the replies. I didn't get them as mails and spinics
didn't update the thread until yesterday.
So I take it that the recommended course of action is not to wait for
any more or less unlikely btrfs-progs fix, but to try --repair and be
ready to restore from backup, too. Darn,
Same failure with btrfs-progs from integration-20140421 (apart from the
line number 1156).
Can I get a bit of input on this? Is it safe to just ignore the error
for now (as I'm doing atm), ie. remount as rw to skip the orphan cleanup?
Might it even be safe to call btrfs check --repair on the
Andreas Reis posted on Tue, 22 Apr 2014 20:16:13 +0200 as excerpted:
Same failure with btrfs-progs from integration-20140421 (apart from the
line number 1156).
Can I get a bit of input on this? Is it safe to just ignore the error
for now (as I'm doing atm), ie. remount as rw to skip the
Kernel 3.15.0-rc2, btrfs-progs 3.14.1
While doing some minor package updates my btrfs root partition [*]
decided to corrupt itself. There was no system crash, although I had
plenty of these (due to an USB-related regression) in recent weeks that
resulted in no trouble.
First only one of a
Alright, turns out the partition does actually mount on 3.15-rc2 (error
messages remain, of course).
But systemd will fail to continue booting as /bin/mount returns exit
status 32 and / thus ends as ro, yet can be manually remounted as rw.
Another error message I've spotted with 3.15 is
Andreas Reis posted on Mon, 21 Apr 2014 21:13:16 +0200 as excerpted:
Alright, turns out the partition does actually mount on 3.15-rc2 (error
messages remain, of course).
But systemd will fail to continue booting as /bin/mount returns exit
status 32 and / thus ends as ro, yet can be manually
