Andreas Reis 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.
Alr
Duncan <1i5t5.duncan 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
ibly similar issue fixed in 2012:
https://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
n 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-
ed with 3.15 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
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 pa
