Duncan 1i5t5.duncan at cox.net writes:
Plus, either way you can report back the results and then we'll
know
whether it's safe to recommend btrfs check for the next report,
or not.
=:^)
Well this is just bloody brilliant.
I did btrfs check --repair with from integration and a bunch of
Andreas Reis andreas.reis at gmail.com writes:
Turns out that when I try to run any binary from the restored
partition (via LiveCD), *every* *single* *one* fails with this
remarkably expressive error. If I manually replace one with a
fresh download, I get a SIGBUS crash instead.
Alright
://bugzilla.novell.com/show_bug.cgi?id=760279 Guess that was a
different underlying issue, though.
Duncan posted on Wed, 23 Apr 2014 02:55:36 +:
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
on the partition? I'm
not keen on that failing mid-process at the same assertion and thus
breaking it over a bunch of minor files, just like it happened with my
previous btrfs partitions.
On 21.04.2014 21:13, Andreas Reis wrote:
Alright, turns out the partition does actually mount on 3.15-rc2 (error
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
is
BTRFS error (device sdc5): error loading props for ino 1810424 (root
257): -5
I've now tried to mount with -o recovery and clear_cache, no effect.
On 21.04.2014 18:16, Andreas Reis wrote:
Kernel 3.15.0-rc2, btrfs-progs 3.14.1
While doing some minor package updates my btrfs root partition
