Error Mounting /home. BTRFS. No Linux Drive Access Even Through live dvd

English Install/Boot/Login
1

13.1 / Current / BTRFS. Can no longer access the desktop and I think it’s btrfs related. I kept getting minor freezes and glitches and never thought much of it, a reboot settled things down, until the last freeze and reboot.

I can boot to the Grub2 menu and choose Windows (which still works). I can choose opensuse and I get to the first splash screen and it looks like it’s going to load to the desktop but a jet black strip drops down from the top and this repeats until the words btrfs : failed to read the log tree. Something like this repeating:

190.770523  btrfs : failed to read log tree
xxx.xxxxxx  btrfs : failed to read log tree
xxx.xxxxxx  btrfs : failed to read log tree
xxx.xxxxxx  btrfs : failed to read log tree

So I tried the recovery mode option from the boot menu and noticed; **Failed : cannot mount /home **

So I tried the opensuse live DVD and see the same thing. So puts the opensuse KDE live CD in to see if I can access the /home partition and get some of yesterdays files off and onto some external storage. I click on the /home partition and get this error message:

An error occurred while accessing '200.1 GiB  Hard Drive', the system responded: The requested operation has failed:  Error mounting /dev/sda4 at  /run/media/linux/0d213eb2-2bc4-4080-8c85-997d28c0c7bc: Command-line  `mount -t "btrfs" -o "uhelper=udisks2,nodev,nosuid" "/dev/sda4"


"/run/media/linux/0d213eb2-2bc4-4080-8c85-997d28c0c7bc"'  exited with non-zero exit status 32: mount: wrong fs type, bad option,  bad superblock on /dev/sda4, missing codepage or helper program, or  other error In some cases useful info is found in syslog - try dmesg |  tail or so.

So I tried an Ubuntu disk and get the same:

An error occurred while accessing '200.1 GiB Hard Drive', the system  responded: The requested operation has failed: Error mounting /dev/sda4  at /run/media/linux/0d213eb2-2bc4-4080-8c85-997d28c0c7bc: Command-line  `mount -t "btrfs" -o "uhelper=udisks2,nodev,nosuid" "/dev/sda4"  "/run/media/linux/0d213eb2-2bc4-4080-8c85-997d28c0c7bc"' exited with  non-zero exit status 32: mount: wrong fs type, bad option, bad  superblock on /dev/sda4, missing codepage or helper program, or other  error In some cases useful info is found in syslog - try dmesg | tail or  so.

I’ve still got a hefty chunk of work sat on the desktop (even though it’s only a day or two worth) and would like to access and save if at all possible. I’m not too bothered if the installation gets any more borked though, I just want access to the files, and possibly get my Firefox sessions folder too.

Thanks.

2

Sounds like the FS is toasted.

try running fsck on the partitions from a live cd/dvd

Note this could be a result of a bad sector so running smartctrl would me a good idea to see if the disk itself is messed up

3

From an Ubuntu dvd it told me I had to use btrfsck and this what it returned:

ubuntu@ubuntu:~$ sudo -i
root@ubuntu:~# fsck /dev/sda4
fsck from util-linux 2.20.1
If you wish to check the consistency of an unmounted
btrfs filesystem or recover files from or repair a
damaged filesystem, see btrfs check and btrfs restore help
output.
root@ubuntu:~# btrfsck /dev/sda4
parent transid verify failed on 282411008 wanted 223822 found 223821
parent transid verify failed on 282411008 wanted 223822 found 223821
parent transid verify failed on 282411008 wanted 223822 found 223821
parent transid verify failed on 282411008 wanted 223822 found 223821
Ignoring transid failure
Checking filesystem on /dev/sda4
UUID: 0d213eb2-2bc4-4080-8c85-997d28c0c7bc
checking extents
checking free space cache
checking fs roots
checking csums
checking root refs
Transid errors in file system
found 40601669653 bytes used err is 1
total csum bytes: 72770416
total tree bytes: 219840512
total fs tree bytes: 115867648
total extent tree bytes: 16302080
btree space waste bytes: 40549307
file data blocks allocated: 81074487296
 referenced 74418626560
Btrfs v3.12
root@ubuntu:~#

Are there btrfs options to fix that??

4

You should use the openSUSE repair disk to be sure of the same version

But I don’t know BTRFS well. And in the past repair options have been rather thin. If the openSUSE fsck (or btrfsck) does not offer the repair I don’t know. It looks to me to be a rather serious problem and may simply be non-repairable.

Have you done a check on the disk to see if it has bad sectors? You should do this first if there is a disk problem you should not attempt a repair

Attempt a repair with (according to man)


btrfsck --repair *theparitionthere*

I’d certainly try to use the openSUSE repair disk (or live 13.1 DVD) since other OS’s may have older or newer versions and may or may not work.

5

Disk is brand new WD Black so didn’t check and I ran the opensuse DVD after you said and it corrected the [size=2] “bytes used err is 1” [/size][size=2]to[/size][size=2] [size=3][size=2][FONT=Verdana]“bytes used err is 0” [/size][/size][/size][/FONT][size=2]it didn’t correct the rest[/size] tho


[size=2]linux@linux:~> su
linux:/home/linux # btrfsck /dev/sda4
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
Ignoring transid failure
Checking filesystem on /dev/sda4
UUID: 0d213eb2-2bc4-4080-8c85-997d28c0c7bc
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 61782461732 bytes used err is 0
total csum bytes: 72770416
total tree bytes: 219856896
total fs tree bytes: 115867648
total extent tree bytes: 16318464
btree space waste bytes: 40565481
file data blocks allocated: 81074487296
 referenced 74418626560
Btrfs v0.20-rc1+20130701[/size]

Repair option didn’t resolve anything and seems to be the same…


[size=2]inux:/home/linux # btrfsck --repair /dev/sda4
enabling repair mode
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
Ignoring transid failure
Checking filesystem on /dev/sda4
UUID: 0d213eb2-2bc4-4080-8c85-997d28c0c7bc
checking extents
checking free space cache
cache and super generation don't match, space cache will be invalidated
checking fs roots
checking csums
checking root refs
found 61782461732 bytes used err is 0
total csum bytes: 72770416
total tree bytes: 219856896
total fs tree bytes: 115867648
total extent tree bytes: 16318464
btree space waste bytes: 40565481
file data blocks allocated: 81074487296
 referenced 74418626560
Btrfs v0.20-rc1+20130701[/size]

I came across a few links that might be worth investigating but I’ll have to look into them tomorrow, although I’m not that hopeful.

6

Hi
What about;


btrfs rescue super-recover [options] <device>

btrfs-debug-tree --help
7

On 2014-10-08 18:46, david banner wrote:

> Code:
> --------------------
> An error occurred while accessing ‘200.1 GiB Hard Drive’, the system responded: The requested operation has failed: Error mounting /dev/sda4 at /run/media/linux/0d213eb2-2bc4-4080-8c85-997d28c0c7bc: Command-line `mount -t “btrfs” -o “uhelper=udisks2,nodev,nosuid” “/dev/sda4”
>
>
> “/run/media/linux/0d213eb2-2bc4-4080-8c85-997d28c0c7bc”’ exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sda4, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so.
> --------------------

And what did you find in “syslog - try dmesg | tail or so” as the
message said?

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

8

Thanks, not spotted those. First one, what option(s) do you pick? :

Try to restore files from a damaged filesystem (unmounted)                                                                                                                                                                   
                                                                                                                                                                                                                                 
-s              get snapshots 
-v              verbose
-i              ignore errors
-o              overwrite
-t              tree location
-f <offset>     filesystem location
-u <block>      super mirror
-d              find dir

second one, the --help option is not available but btrfs-debug-tree reads:

linux:/home/linux # btrfs-debug-tree
usage: btrfs-debug-tree  -e ]  -d ]  -r ]  -R ]
                        -b block_num ] device
        -e : print detailed extents info
        -d : print info of btrfs device and root tree dirs only
        -r : print info of roots only
        -R : print info of roots and root backups
        -b block_num : print info of the specified block only
Btrfs v0.20-rc1+20130701
9

tail gave nothing relevant at all. dmesg just made reference to the four that came up before…

[size=2]parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821
parent transid verify failed on 282411008 wanted 223823 found 223821[/size]

10

Note that even if a new drive you can have bad sectors.

Should check

11

On Thu 09 Oct 2014 09:56:15 AM CDT, david banner wrote:

malcolmlewis;2668488 Wrote:
> Hi
> What about;
> >
Code:

> >
> btrfs rescue super-recover [options] <device>
>
> btrfs-debug-tree --help
>

> >

Thanks, not spotted those. First one, what option(s) do you pick? :

Code:

Try to restore files from a damaged filesystem
(unmounted)
-s get snapshots
-v verbose
-i ignore errors
-o overwrite
-t tree location
-f <offset> filesystem location
-u <block> super mirror
-d find dir

second one, the --help option is not available but btrfs-debug-tree
reads:

Code:

linux:/home/linux # btrfs-debug-tree
usage: btrfs-debug-tree -e ] -d ] -r ] -R ]
-b block_num ] device
-e : print detailed extents info
-d : print info of btrfs device and root tree dirs only
-r : print info of roots only
-R : print info of roots and root backups
-b block_num : print info of the specified block only
Btrfs v0.20-rc1+20130701

Hi
I would recommend using the openSUSE 13.1 rescue cd for any attempts at
recovery. v0.20 is old… openSUSE has Btrfs v3.12+20131125.

Not sure on the above is best, however have you run;


btrfs-show-super -a /dev/sdXX

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.1 Kernel 3.11.10-21-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

12

lol. You got me me paranoid so I ran WD diags and fortunately it came back clean.

13

It’s a nice environment this live rescue cd, quite like Midori. lol.

Anyway, this is what it returns…

linux@linux:~> su
linux:/home/linux # btrfs-show-super -a /dev/sda4
superblock: bytenr=65536, device=/dev/sda4
---------------------------------------------------------
csum            0x98b47c47 [match]
bytenr            65536
flags            0x1
magic            _BHRfS_M [match]
fsid            0d213eb2-2bc4-4080-8c85-997d28c0c7bc
label            
generation        223823
root            31817728
sys_array_size        226
chunk_root_generation    221914
root_level        1
chunk_root        20971520
chunk_root_level    0
log_root        282411008
log_root_transid    0
log_root_level        0
total_bytes        214853222400
bytes_used        74765279232
sectorsize        4096
nodesize        16384
leafsize        16384
stripesize        4096
root_dir        6
num_devices        1
compat_flags        0x0
compat_ro_flags        0x0
incompat_flags        0x61
csum_type        0
csum_size        4
cache_generation    223821
dev_item.uuid        5141210e-cd60-41a1-9842-9ed118c7910f
dev_item.fsid        0d213eb2-2bc4-4080-8c85-997d28c0c7bc [match]
dev_item.type        0
dev_item.total_bytes    214853222400
dev_item.bytes_used    97748254720
dev_item.io_align    4096
dev_item.io_width    4096
dev_item.sector_size    4096
dev_item.devid        1
dev_item.dev_group    0
dev_item.seek_speed    0
dev_item.bandwidth    0
dev_item.generation    0


superblock: bytenr=67108864, device=/dev/sda4
---------------------------------------------------------
csum            0x38d55489 [match]
bytenr            67108864
flags            0x1
magic            _BHRfS_M [match]
fsid            0d213eb2-2bc4-4080-8c85-997d28c0c7bc
label            
generation        223823
root            31817728
sys_array_size        226
chunk_root_generation    221914
root_level        1
chunk_root        20971520
chunk_root_level    0
log_root        282411008
log_root_transid    0
log_root_level        0
total_bytes        214853222400
bytes_used        74765279232
sectorsize        4096
nodesize        16384
leafsize        16384
stripesize        4096
root_dir        6
num_devices        1
compat_flags        0x0
compat_ro_flags        0x0
incompat_flags        0x61
csum_type        0
csum_size        4
cache_generation    223821
dev_item.uuid        5141210e-cd60-41a1-9842-9ed118c7910f
dev_item.fsid        0d213eb2-2bc4-4080-8c85-997d28c0c7bc [match]
dev_item.type        0
dev_item.total_bytes    214853222400
dev_item.bytes_used    97748254720
dev_item.io_align    4096
dev_item.io_width    4096
dev_item.sector_size    4096
dev_item.devid        1
dev_item.dev_group    0
dev_item.seek_speed    0
dev_item.bandwidth    0
dev_item.generation    0
14

Good just remember things are never perfect.

As to the error I have no idea how to fix that if btrfsck does not do it it may be truly messed.

15

On 2014-10-09 18:56, gogalthorp wrote:
>
> Good just remember things are never perfect.
>
> As to the error I have no idea how to fix that if btrfsck does not do it
> it may be truly messed.

In that case, I suggest posting on the opensuse mail list. Maybe someone
there knows.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

16

There are still options to try yet, if I can figure the right option for btrfs rescue super-recover [options] <device> then it might work.

I’m working on it, but the documentation is sparse and not necessarily in date.

17

On Thu, 09 Oct 2014 16:56:01 GMT, gogalthorp
<gogalthorp@no-mx.forums.opensuse.org> wrote:

>
>Good just remember things are never perfect.
>
>As to the error I have no idea how to fix that if btrfsck does not do it
>it may be truly messed.

Sounds like it is time to use ddrescue to clone the volume/partition a few
times to try more dangerous tools. Who knows, maybe the copy will work ok
(long shot i expect).

?-)