Unable to mount filesystem

Unable to mount filesystem

[Chris Korent]

This seemed to happen after a power failure. I rebooted and the FS was
mounted, but read-only and there were some errors (journalctl not able
to start. I did not capture all the errors). I rebooted again and then
it wouldn't mount at all. Is there anything else I can do?

uname -a
Linux sysresccd 3.10.35-std420-amd64 #2 SMP Wed Apr 2 18:31:51 UTC
2014 x86_64 Intel(R) Core(TM) i7-3740QM CPU @ 2.70GHz GenuineIntel
GNU/Linux

btrfs --version
Btrfs v3.14.1

btrfs fi show
Label: 'ROOT'  uuid: c3117347-03eb-4746-9981-814a32749785
Total devices 1 FS bytes used 605.88GiB
devid    1 size 913.00GiB used 754.06GiB path /dev/mapper/vg_crypt-lv_root

Btrfs v3.14.1

When I try to mount:
mount -o recovery /dev/mapper/vg_crypt-lv_root /mnt/frog
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/vg_crypt-lv_root,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

Output in dmesg:
[76286.328518] device label ROOT devid 1 transid 562914
/dev/mapper/vg_crypt-lv_root
[76286.329709] btrfs: enabling auto recovery
[76286.329714] btrfs: disk space caching is enabled
[76286.336555] btrfs bad tree block start 142638070361910812 1107795361792
[76286.336641] btrfs bad tree block start 142638070361910812 1107795361792
[76286.336734] btrfs bad tree block start 142638070361910812 1107795361792
[76286.336945] btrfs bad tree block start 142638070361910812 1107795361792
[76286.337057] btrfs bad tree block start 142638070361910812 1107791572992
[76286.337184] btrfs bad tree block start 142638070361910812 1107791572992
[76286.337198] btrfs: failed to read tree root on dm-2
[76286.337301] btrfs bad tree block start 142638070361910812 1107768221696
[76286.337399] btrfs bad tree block start 142638070361910812 1107768221696
[76286.337409] btrfs: failed to read tree root on dm-2
[76286.337605] parent transid verify failed on 1107746967552 wanted
562911 found 562914
[76286.337812] parent transid verify failed on 1107746967552 wanted
562911 found 562914
[76286.337818] btrfs: failed to read tree root on dm-2
[76286.352774] btrfs: open_ctree failed

btrfs-find-root /dev/mapper/vg_crypt-lv_root
Super think's the tree root is at 1107748114432, chunk root 1621341777920
Went past the fs size, exiting#

This shows 3 bad chunks
btrfs rescue chunk-recover -v /dev/mapper/vg_crypt-lv_root
---SNIP---
Bad Chunks:
  Chunk: start = 0, len = 4194304, type = 2, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 0
      Block Group: start = 0, len = 4194304, flag = 2
      No device extent.
  Chunk: start = 4194304, len = 8388608, type = 4, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 4194304
      Block Group: start = 4194304, len = 8388608, flag = 4
      No device extent.
  Chunk: start = 12582912, len = 8388608, type = 1, num_stripes = 1
      Stripes list:
      [ 0] Stripe: devid = 1, offset = 12582912
      No block group.
      No device extent.

Total Chunks: 758
  Heathy: 755
  Bad: 3

Orphan Block Groups:

Orphan Device Extents:
Fail to recover the chunk tree.

btrfsck does not run
btrfsck /dev/mapper/vg_crypt-lv_root
Check tree block failed, want=1107795361792, have=142638070361910812
Check tree block failed, want=1107795361792, have=142638070361910812
Check tree block failed, want=1107795361792, have=142638070361910812
Check tree block failed, want=1107795361792, have=142638070361910812
Check tree block failed, want=1107795361792, have=142638070361910812
read block failed check_tree_block
Couldn't setup extent tree
Check tree block failed, want=1107745558528, have=142638070361910812
Check tree block failed, want=1107745558528, have=142638070361910812
Check tree block failed, want=1107745558528, have=142638070361910812
Check tree block failed, want=1107745558528, have=142638070361910812
Check tree block failed, want=1107745558528, have=142638070361910812
read block failed check_tree_block
Couldn't setup csum tree
Check tree block failed, want=1107795329024, have=142638070361910812
Check tree block failed, want=1107795329024, have=142638070361910812
Check tree block failed, want=1107795329024, have=142638070361910812
Check tree block failed, want=1107795329024, have=142638070361910812
Check tree block failed, want=1107795329024, have=142638070361910812
read block failed check_tree_block
Checking filesystem on /dev/mapper/vg_crypt-lv_root
UUID: c3117347-03eb-4746-9981-814a32749785
Critical roots corrupted, unable to fsck the FS

btrfs rescue super-recover -v /dev/mapper/vg_crypt-lv_root
All Devices:
Device: id = 1, name = /dev/mapper/vg_crypt-lv_root

Before Recovering:
[All good supers]:
device name = /dev/mapper/vg_crypt-lv_root
superblock bytenr = 65536

device name = /dev/mapper/vg_crypt-lv_root
superblock bytenr = 67108864

device name = /dev/mapper/vg_crypt-lv_root
superblock bytenr = 274877906944

[All bad supers]:

All supers are valid, no need to recover

btrfs-show-super -a /dev/mapper/vg_crypt-lv_root
superblock: bytenr=65536, device=/dev/mapper/vg_crypt-lv_root
---------------------------------------------------------
csum 0x808ef02b [match]
bytenr 65536
flags 0x1
magic _BHRfS_M [match]
fsid c3117347-03eb-4746-9981-814a32749785
label ROOT
generation 562914
root 1107748114432
sys_array_size 129
chunk_root_generation 562226
root_level 1
chunk_root 1621341777920
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 980326285312
bytes_used 650558619648
sectorsize 4096
nodesize 4096
leafsize 4096
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0xb
csum_type 0
csum_size 4
cache_generation 562914
uuid_tree_generation 108092
dev_item.uuid 5c783feb-181c-4bb5-b0af-3c4899c5228f
dev_item.fsid c3117347-03eb-4746-9981-814a32749785 [match]
dev_item.type 0
dev_item.total_bytes 980326285312
dev_item.bytes_used 809668444160
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/mapper/vg_crypt-lv_root
---------------------------------------------------------
csum 0x20efd8e5 [match]
bytenr 67108864
flags 0x1
magic _BHRfS_M [match]
fsid c3117347-03eb-4746-9981-814a32749785
label ROOT
generation 562914
root 1107748114432
sys_array_size 129
chunk_root_generation 562226
root_level 1
chunk_root 1621341777920
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 980326285312
bytes_used 650558619648
sectorsize 4096
nodesize 4096
leafsize 4096
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0xb
csum_type 0
csum_size 4
cache_generation 562914
uuid_tree_generation 108092
dev_item.uuid 5c783feb-181c-4bb5-b0af-3c4899c5228f
dev_item.fsid c3117347-03eb-4746-9981-814a32749785 [match]
dev_item.type 0
dev_item.total_bytes 980326285312
dev_item.bytes_used 809668444160
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=274877906944, device=/dev/mapper/vg_crypt-lv_root
---------------------------------------------------------
csum 0xdd688ed4 [match]
bytenr 274877906944
flags 0x1
magic _BHRfS_M [match]
fsid c3117347-03eb-4746-9981-814a32749785
label ROOT
generation 562914
root 1107748114432
sys_array_size 129
chunk_root_generation 562226
root_level 1
chunk_root 1621341777920
chunk_root_level 1
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 980326285312
bytes_used 650558619648
sectorsize 4096
nodesize 4096
leafsize 4096
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0xb
csum_type 0
csum_size 4
cache_generation 562914
uuid_tree_generation 108092
dev_item.uuid 5c783feb-181c-4bb5-b0af-3c4899c5228f
dev_item.fsid c3117347-03eb-4746-9981-814a32749785 [match]
dev_item.type 0
dev_item.total_bytes 980326285312
dev_item.bytes_used 809668444160
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

Thanks,
Chris

Re: Unable to mount filesystem

[Marc MERLIN]

On Thu, May 08, 2014 at 01:06:25PM +0000, Chris Korent wrote:
> This seemed to happen after a power failure. I rebooted and the FS was
> mounted, but read-only and there were some errors (journalctl not able
> to start. I did not capture all the errors). I rebooted again and then
> it wouldn't mount at all. Is there anything else I can do?

You did some things, but look at the checklist I put on 
https://btrfs.wiki.kernel.org/index.php/Btrfsck
1) use -o recovery,ro, not -o recovery)
2) does btrfs restore work?
3) btrfs check is your last option.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: Unable to mount filesystem

[Chris Murphy]

On May 8, 2014, at 7:06 AM, Chris Korent <ckorent@gmail.com> wrote:

> Linux sysresccd 3.10.35-std420-amd64 #2 SMP Wed Apr 2 18:31:51 UTC
> 
> btrfs --version
> Btrfs v3.14.1

I'm uncertain if this is an OK combination. I'm under the impression that the kernel should be the same or newer version than progs. Also kernel 3.10 is old in Btrfs terms. Before altering the file system further, I'd try a normal mount with the newest kernel you can get your hands on. If normal mount doesn't work, try either -o ro,recovery (bit more conservative but any repair isn't permanent) or -o recovery.

Although before you even get started, it's probably a good idea to take an image:

btrfs-image -c9 -t4 /dev/sdX /path/to/big/file

If you use btrfs check don't use any options yet.

The errors look a lot like Marc Merlin's error messages, and is also a case of Btrfs on dmcrypt.


Chris Murphy

Re: Unable to mount filesystem

[Duncan]

Chris Murphy posted on Sat, 10 May 2014 10:49:07 -0600 as excerpted:

> On May 8, 2014, at 7:06 AM, Chris Korent <ckorent@gmail.com> wrote:
> 
>> Linux sysresccd 3.10.35-std420-amd64 #2 SMP Wed Apr 2 18:31:51 UTC
>> 
>> btrfs --version Btrfs v3.14.1
> 
> I'm uncertain if this is an OK combination. I'm under the impression
> that the kernel should be the same or newer version than progs. Also
> kernel 3.10 is old in Btrfs terms. Before altering the file system
> further, I'd try a normal mount with the newest kernel you can get your
> hands on.

In theory it's OK as the progs are supposed to be backward compatible at 
least some way (I wouldn't try anything pre-2.6.32 for sure as that was 
the last big format change, IIRC, and anything pre-3.5 or so may work but 
I'd not suggest it), but... there are of course bugs, and btrfs is still 
under intense enough development that there are bugs being fixed every 
kernel...

So while yes, in theory the above version spread should work, the 
recommendation to try the latest stable-kernel from the latest stable 
series 3.14.x is an absolutely solid one, and in fact we're late enough 
in the 3.15-rc cycle now that trying with that is ultimately the best bet.

In fact, as the output from mkfs.btrfs suggests, running the latest 
stable at the oldest really is recommended, and kernel is a bit more 
critical in that regard than btrfs-progs, since the kernel is what 
actually handles the filesystem and thus running an old kernel really is 
basically uselessly risking your btrfs and the data on it to known and 
now fixed bugs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Unable to mount filesystem

[Wictor Lund]

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

Hi!
 
I cannot mount my filesystem anymore. The problem started with it going
into read-only mode after the filesystem accidentally became full. At
some point the system crashed and after that I got this error. Is it
possible to recover the filesystem or at least recover some data from
it?

Here is some information from the system:
 
$ uname -a
Linux localhost.localdomain 4.8.6-300.fc25.x86_64 #1 SMP Tue Nov 1 12:36:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
 
$ btrfs --version
btrfs-progs v4.6.1
 
$ sudo mount /dev/sda4 /mnt
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.
 
$ sudo btrfs fi show
Label: 'fedora'  uuid: 3ddc9cf1-ff3f-4081-900a-4f732838c31b
   Total devices 1 FS bytes used 208.67GiB
   devid 1 size 230.04GiB used 212.06GiB path /dev/sda4
 
$ dmesg | grep -i btrfs
[ 5.747551] Btrfs loaded, crc32c=crc32c-intel
[ 5.748632] BTRFS: device label fedora devid 1 transid 649633 /dev/sda4
[   48.663727] BTRFS info (device sda4): disk space caching is enabled
[   48.665184] BTRFS error (device sda4): bad tree block start 0 1234052513792
[   48.665194] BTRFS warning (device sda4): failed to read tree root
[   48.680625] BTRFS: open_ctree failed
 
$ sudo btrfs check /dev/sda4
checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
bytenr mismatch, want=1234052513792, have=0
Couldn't read tree root
Couldn't open file system

$ sudo btrfs restore -l /dev/sda4
checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
bytenr mismatch, want=1234052513792, have=0
Couldn't read tree root
Could not open root, trying backup super
checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
bytenr mismatch, want=1234052513792, have=0
Couldn't read tree root
Could not open root, trying backup super
Superblock bytenr is larger than device size
Could not open root, trying backup super

--
Wictor Lund

[-- Attachment #2: OpenPGP digital signatur --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Unable to mount filesystem

[André-Sebastian Liebe]

Hi Wictor, Hi List

I'm more or less stuck with the same problem as you. Btrfs on my
external drive got corrupted after I moved a lot of files to it and
would'n mount anymore.
This happened to me in november 2015 and I haven't tried again since
today, as tools and code have matured eventually.

I tried a lot of things, but nothing helped yet :-/

$ uname -a
> Linux apc01 4.10.13-1-ARCH #1 SMP PREEMPT Thu Apr 27 12:15:09 CEST
2017 x86_64 GNU/Linux

$ [root@apc01 ~]# btrfs --version
> btrfs-progs v4.11.1

$ btrfs fi sh
> Label: 'external_0001'  uuid: 6acf5972-91a8-49a1-a5a1-2bcd86b8eb8b
>         Total devices 1 FS bytes used 2.18TiB
>         devid    1 size 3.64TiB used 2.19TiB path /dev/mapper/roverlay

1. cloned the drive with dd
2. attached the cloned drive to my computer and created an writable
overlay (with losetup and dmsetup), so I can test many things without
changing one bit on the cloned drive
3. tried recovery

3a) `mount -t btrfs /dev/mapper/roverlay /mnt`
> BTRFS info (device dm-0): disk space caching is enabled
> BTRFS info (device dm-0): has skinny extents
> BTRFS error (device dm-0): bad tree block start 11851697049360863559
21053440
> BTRFS error (device dm-0): bad tree block start 7989935996922551463
21053440
> BTRFS error (device dm-0): failed to read chunk tree: -5
> BTRFS error (device dm-0): open_ctree failed

3b) `mount -t btrfs -o ro,recovery /dev/mapper/roverlay /mnt`
same as 3a)

3c) `btrfs rescue zero-log /dev/mapper/roverlay`
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found CF3B13F9 wanted 4A9A0385
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> bytenr mismatch, want=21053440, have=11851697049360863559
> Couldn't read chunk tree
> ERROR: cannot open ctree

3d) `btrfs restore /dev/mapper/roverlay /data/recovery`
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found CF3B13F9 wanted 4A9A0385
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> bytenr mismatch, want=21053440, have=11851697049360863559
> Couldn't read chunk tree
> Could not open root, trying backup super
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found CF3B13F9 wanted 4A9A0385
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> bytenr mismatch, want=21053440, have=11851697049360863559
> Couldn't read chunk tree
> Could not open root, trying backup super
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found CF3B13F9 wanted 4A9A0385
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> bytenr mismatch, want=21053440, have=11851697049360863559
> Couldn't read chunk tree
> Could not open root, trying backup super

3e) `btrfs check -s 0 /dev/mapper/roverlay`
> using SB copy 0, bytenr 65536
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found CF3B13F9 wanted 4A9A0385
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> bytenr mismatch, want=21053440, have=11851697049360863559
> Couldn't read chunk tree
> ERROR: cannot open file system

3f) `btrfs check -s 1 /dev/mapper/roverlay`
> using SB copy 1, bytenr 67108864
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found CF3B13F9 wanted 4A9A0385
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> bytenr mismatch, want=21053440, have=11851697049360863559
> Couldn't read chunk tree
> ERROR: cannot open file system

3g) `btrfs check -s 2 /dev/mapper/roverlay`
> using SB copy 2, bytenr 274877906944
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> checksum verify failed on 21053440 found CF3B13F9 wanted 4A9A0385
> checksum verify failed on 21053440 found 42E96418 wanted 277C3E6A
> bytenr mismatch, want=21053440, have=11851697049360863559
> Couldn't read chunk tree
> ERROR: cannot open file system

3h) `btrfs rescue super-recover -v /dev/mapper/roverlay`
> All Devices:
>         Device: id = 1, name = /dev/mapper/roverlay
>
> Before Recovering:
>         [All good supers]:
>                 device name = /dev/mapper/roverlay
>                 superblock bytenr = 65536
>
>                 device name = /dev/mapper/roverlay
>                 superblock bytenr = 67108864
>
>                 device name = /dev/mapper/roverlay
>                 superblock bytenr = 274877906944
>
>         [All bad supers]:
>
> All supers are valid, no need to recover

3i) `btrfs rescue chunk-recover -v /dev/mapper/roverlay`
> All Devices:
>         Device: id = 1, name = /dev/mapper/roverlay
>
> Scanning: 2127447805952 in dev0chunk-recover.c:129:
process_extent_buffer: BUG_ON `exist->nmirrors >= BTRFS_MAX_MIRRORS`
triggered, value 1
> btrfs[0x463150]
> btrfs[0x463fd1]
> /usr/lib/libpthread.so.0(+0x7297)[0x7f0efc75a297]
> /usr/lib/libc.so.6(clone+0x3f)[0x7f0efc49b1ef]
> Aborted (core dumped)

Any more suggestions?

-
andre

On 02.07.2017 20:21, Wictor Lund wrote:
> Hi!
>  
> I cannot mount my filesystem anymore. The problem started with it going
> into read-only mode after the filesystem accidentally became full. At
> some point the system crashed and after that I got this error. Is it
> possible to recover the filesystem or at least recover some data from
> it?
>
> Here is some information from the system:
>  
> $ uname -a
> Linux localhost.localdomain 4.8.6-300.fc25.x86_64 #1 SMP Tue Nov 1 12:36:38 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>  
> $ btrfs --version
> btrfs-progs v4.6.1
>  
> $ sudo mount /dev/sda4 /mnt
> 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.
>  
> $ sudo btrfs fi show
> Label: 'fedora'  uuid: 3ddc9cf1-ff3f-4081-900a-4f732838c31b
>    Total devices 1 FS bytes used 208.67GiB
>    devid 1 size 230.04GiB used 212.06GiB path /dev/sda4
>  
> $ dmesg | grep -i btrfs
> [ 5.747551] Btrfs loaded, crc32c=crc32c-intel
> [ 5.748632] BTRFS: device label fedora devid 1 transid 649633 /dev/sda4
> [   48.663727] BTRFS info (device sda4): disk space caching is enabled
> [   48.665184] BTRFS error (device sda4): bad tree block start 0 1234052513792
> [   48.665194] BTRFS warning (device sda4): failed to read tree root
> [   48.680625] BTRFS: open_ctree failed
>  
> $ sudo btrfs check /dev/sda4
> checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
> checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
> bytenr mismatch, want=1234052513792, have=0
> Couldn't read tree root
> Couldn't open file system
>
> $ sudo btrfs restore -l /dev/sda4
> checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
> checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
> bytenr mismatch, want=1234052513792, have=0
> Couldn't read tree root
> Could not open root, trying backup super
> checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
> checksum verify failed on 1234052513792 found E4E3BDB6 wanted 00000000
> bytenr mismatch, want=1234052513792, have=0
> Couldn't read tree root
> Could not open root, trying backup super
> Superblock bytenr is larger than device size
> Could not open root, trying backup super
>
> --
> Wictor Lund