Salvage files from broken btrfs
On 03.11.2018 at 02:05 Qu Wenruo wrote: > On 2018/11/3 上午1:18, M. Klingmann wrote: >> On 02.11.2018 at 15:45 Qu Wenruo wrote: >>> On 2018/11/2 下午10:30, M. Klingmann wrote: On 31.10.2018 at 01:03 Qu Wenruo wrote: > My plan for such recovery is: > > 1) btrfs ins dump-super to make sure system chunk array is valid > 2) btrfs-find-root to find any valid chunk tree blocks > 3) pass that chunk tree bytenr to btrfs-restore >Unfortunately, btrfs-restore doesn't support specifying chunk root >yet. But it's pretty easy to add such support. > > So, please provide the "btrfs ins dump-super -Ffa" output to start with. Following your plan, I did 1) and 2). As 2) failed (see below), is there anything I can do to find the tree bytenr to supply btrfs-restore with it? 1) Here's the output given by "btrfs-show-super -Ffa": superblock: bytenr=65536, device=sdcard.iso - csum 0xb8e15dd7 [match] >> [snip] 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed". >>> It's not plain "btrfs-find-root" but "btrfs-find-root -o 5". >>> >>> And you should use btrfs-progs v4.17.1, not the old v4.4. >>> The ability to continue search even if chunk tree get corrupted is added >>> in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of >>> fixes and extra debug output. >>> >>> If you can't find any handy way to update btrfs-progs, you could use >>> Archlinux iso as a rescue OS to use the latest btrfs-progs. >> Using Archlinux in fact is the easiest way to use version 4.17.1 >> (Archlinux for 2018-11-01). >> >> Here's the output from "btrfs-find-root sdcard.iso": >> >> WARNING: cannot read chunk root, continue anyway >> Superblock thinks the generation is 1757933 >> Superblock thinks the level is 0 >> >> Here's the output using "btrfs-find-root -o 5 sdcard.iso": >> >> WARNING: cannot read chunk root, continue anyway >> Superblock doesn't contain generation info for root 5 >> Superblock doesn't contain the level info for root 5 > No other output at all? > > That means the whole 8M range of system chunk get corrupted. > Thus really no way to get any meaningful data out of the filesystem, > unfortunately. > > Thanks, > Qu That's a pity. So I'm back to the hex editor. I hope to find another angle before searching for file content. Thank you for your efforts anyway. Cheers, Mirko
Re: Salvage files from broken btrfs
On 2018/11/3 上午1:18, M. Klingmann wrote: > On 02.11.2018 at 15:45 Qu Wenruo wrote: >> On 2018/11/2 下午10:30, M. Klingmann wrote: >>> On 31.10.2018 at 01:03 Qu Wenruo wrote: My plan for such recovery is: 1) btrfs ins dump-super to make sure system chunk array is valid 2) btrfs-find-root to find any valid chunk tree blocks 3) pass that chunk tree bytenr to btrfs-restore Unfortunately, btrfs-restore doesn't support specifying chunk root yet. But it's pretty easy to add such support. So, please provide the "btrfs ins dump-super -Ffa" output to start with. >>> Following your plan, I did 1) and 2). >>> As 2) failed (see below), is there anything I can do to find the tree >>> bytenr to supply btrfs-restore with it? >>> >>> 1) Here's the output given by "btrfs-show-super -Ffa": >>> >>> superblock: bytenr=65536, device=sdcard.iso >>> - >>> csum 0xb8e15dd7 [match] > [snip] >>> 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed". >> It's not plain "btrfs-find-root" but "btrfs-find-root -o 5". >> >> And you should use btrfs-progs v4.17.1, not the old v4.4. >> The ability to continue search even if chunk tree get corrupted is added >> in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of >> fixes and extra debug output. >> >> If you can't find any handy way to update btrfs-progs, you could use >> Archlinux iso as a rescue OS to use the latest btrfs-progs. > > Using Archlinux in fact is the easiest way to use version 4.17.1 > (Archlinux for 2018-11-01). > > Here's the output from "btrfs-find-root sdcard.iso": > > WARNING: cannot read chunk root, continue anyway > Superblock thinks the generation is 1757933 > Superblock thinks the level is 0 > > Here's the output using "btrfs-find-root -o 5 sdcard.iso": > > WARNING: cannot read chunk root, continue anyway > Superblock doesn't contain generation info for root 5 > Superblock doesn't contain the level info for root 5 No other output at all? That means the whole 8M range of system chunk get corrupted. Thus really no way to get any meaningful data out of the filesystem, unfortunately. Thanks, Qu > >> For 3), I could easily add such feature btrfs-restore, or just use >> manually patching your superblock to continue. >> So as soon as your "btrfs-find-root -o 5" gets some valid output, I >> could continue the work. >> > Thank you. > signature.asc Description: OpenPGP digital signature
Re: Salvage files from broken btrfs
On 02.11.2018 at 15:45 Qu Wenruo wrote: > On 2018/11/2 下午10:30, M. Klingmann wrote: >> On 31.10.2018 at 01:03 Qu Wenruo wrote: >>> My plan for such recovery is: >>> >>> 1) btrfs ins dump-super to make sure system chunk array is valid >>> 2) btrfs-find-root to find any valid chunk tree blocks >>> 3) pass that chunk tree bytenr to btrfs-restore >>>Unfortunately, btrfs-restore doesn't support specifying chunk root >>>yet. But it's pretty easy to add such support. >>> >>> So, please provide the "btrfs ins dump-super -Ffa" output to start with. >> Following your plan, I did 1) and 2). >> As 2) failed (see below), is there anything I can do to find the tree >> bytenr to supply btrfs-restore with it? >> >> 1) Here's the output given by "btrfs-show-super -Ffa": >> >> superblock: bytenr=65536, device=sdcard.iso >> - >> csum 0xb8e15dd7 [match] [snip] >> 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed". > It's not plain "btrfs-find-root" but "btrfs-find-root -o 5". > > And you should use btrfs-progs v4.17.1, not the old v4.4. > The ability to continue search even if chunk tree get corrupted is added > in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of > fixes and extra debug output. > > If you can't find any handy way to update btrfs-progs, you could use > Archlinux iso as a rescue OS to use the latest btrfs-progs. Using Archlinux in fact is the easiest way to use version 4.17.1 (Archlinux for 2018-11-01). Here's the output from "btrfs-find-root sdcard.iso": WARNING: cannot read chunk root, continue anyway Superblock thinks the generation is 1757933 Superblock thinks the level is 0 Here's the output using "btrfs-find-root -o 5 sdcard.iso": WARNING: cannot read chunk root, continue anyway Superblock doesn't contain generation info for root 5 Superblock doesn't contain the level info for root 5 > For 3), I could easily add such feature btrfs-restore, or just use > manually patching your superblock to continue. > So as soon as your "btrfs-find-root -o 5" gets some valid output, I > could continue the work. > Thank you. -- Mirko signature.asc Description: OpenPGP digital signature
Re: Salvage files from broken btrfs
On 2018/11/2 下午10:30, M. Klingmann wrote: > > On 31.10.2018 at 01:03 Qu Wenruo wrote: >> My plan for such recovery is: >> >> 1) btrfs ins dump-super to make sure system chunk array is valid >> 2) btrfs-find-root to find any valid chunk tree blocks >> 3) pass that chunk tree bytenr to btrfs-restore >>Unfortunately, btrfs-restore doesn't support specifying chunk root >>yet. But it's pretty easy to add such support. >> >> So, please provide the "btrfs ins dump-super -Ffa" output to start with. > Following your plan, I did 1) and 2). > As 2) failed (see below), is there anything I can do to find the tree > bytenr to supply btrfs-restore with it? > > 1) Here's the output given by "btrfs-show-super -Ffa": > > superblock: bytenr=65536, device=sdcard.iso > - > csum 0xb8e15dd7 [match] > bytenr 65536 > flags 0x1 > ( WRITTEN ) > magic _BHRfS_M [match] > fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c > label > generation 1757933 > root 889143296 > sys_array_size 226 > chunk_root_generation 932006 > root_level 0 > chunk_root 20987904 > chunk_root_level 0 > log_root 890109952 > log_root_transid 0 > log_root_level 0 > total_bytes 3053696 > bytes_used 16937803776 > sectorsize 4096 > nodesize 16384 > leafsize 16384 > stripesize 4096 > root_dir 6 > num_devices 1 > compat_flags 0x0 > compat_ro_flags 0x0 > incompat_flags 0x61 > ( MIXED_BACKREF | > BIG_METADATA | > EXTENDED_IREF ) > csum_type 0 > csum_size 4 > cache_generation 1757933 > uuid_tree_generation 149 > dev_item.uuid 90185cf6-b937-49bb-b191-91d08677ee22 > dev_item.fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c [match] > dev_item.type 0 > dev_item.total_bytes 3053696 > dev_item.bytes_used 3053696 > 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 > sys_chunk_array[2048]: > item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 0) > chunk length 4194304 owner 2 stripe_len 65536 > type SYSTEM num_stripes 1 > stripe 0 devid 1 offset 0 > dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 > item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520) > chunk length 8388608 owner 2 stripe_len 65536 > type SYSTEM|DUP num_stripes 2 This chunk looks pretty OK. And it's DUP, so it improves the possibility to recover. > stripe 0 devid 1 offset 20971520 > dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 > stripe 1 devid 1 offset 29360128 > dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 > backup_roots[4]: > backup 0: > backup_tree_root: 889143296 gen: 1757933 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 81152 gen: 1757933 level: 2 > backup_fs_root: 889716736 gen: 1757934 level: 2 > backup_dev_root: 307560448 gen: 1673227 level: 0 > backup_csum_root: 887898112 gen: 1757934 level: 2 > backup_total_bytes: 3053696 > backup_bytes_used: 16937803776 > backup_num_devices: 1 > > backup 1: > backup_tree_root: 882311168 gen: 1757930 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 879738880 gen: 1757931 level: 2 > backup_fs_root: 883097600 gen: 1757931 level: 2 > backup_dev_root: 307560448 gen: 1673227 level: 0 > backup_csum_root: 883212288 gen: 1757931 level: 2 > backup_total_bytes: 3053696 > backup_bytes_used: 16943640576 > backup_num_devices: 1 > > backup 2: > backup_tree_root: 881082368 gen: 1757931 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 879738880 gen: 1757931 level: 2 > backup_fs_root: 883654656 gen: 1757932 level: 2 > backup_dev_root: 307560448 gen: 1673227 level: 0 > backup_csum_root: 883703808 gen: 1757932 level: 2 > backup_total_bytes: 3053696 > backup_bytes_used: 16943722496 > backup_num_devices: 1 > > backup 3: > backup_tree_root: 887865344 gen: 1757932 level: 0 > backup_chunk_root: 20987904 gen: 932006 level: 0 > backup_extent_root: 81152 gen: 1757933 level: 2 > backup_fs_root: 888750080 gen: 1757933 level: 2 > backup_dev_root:
Re: Salvage files from broken btrfs
On 31.10.2018 at 01:03 Qu Wenruo wrote: > My plan for such recovery is: > > 1) btrfs ins dump-super to make sure system chunk array is valid > 2) btrfs-find-root to find any valid chunk tree blocks > 3) pass that chunk tree bytenr to btrfs-restore >Unfortunately, btrfs-restore doesn't support specifying chunk root >yet. But it's pretty easy to add such support. > > So, please provide the "btrfs ins dump-super -Ffa" output to start with. Following your plan, I did 1) and 2). As 2) failed (see below), is there anything I can do to find the tree bytenr to supply btrfs-restore with it? 1) Here's the output given by "btrfs-show-super -Ffa": superblock: bytenr=65536, device=sdcard.iso - csum 0xb8e15dd7 [match] bytenr 65536 flags 0x1 ( WRITTEN ) magic _BHRfS_M [match] fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c label generation 1757933 root 889143296 sys_array_size 226 chunk_root_generation 932006 root_level 0 chunk_root 20987904 chunk_root_level 0 log_root 890109952 log_root_transid 0 log_root_level 0 total_bytes 3053696 bytes_used 16937803776 sectorsize 4096 nodesize 16384 leafsize 16384 stripesize 4096 root_dir 6 num_devices 1 compat_flags 0x0 compat_ro_flags 0x0 incompat_flags 0x61 ( MIXED_BACKREF | BIG_METADATA | EXTENDED_IREF ) csum_type 0 csum_size 4 cache_generation 1757933 uuid_tree_generation 149 dev_item.uuid 90185cf6-b937-49bb-b191-91d08677ee22 dev_item.fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c [match] dev_item.type 0 dev_item.total_bytes 3053696 dev_item.bytes_used 3053696 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 sys_chunk_array[2048]: item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 0) chunk length 4194304 owner 2 stripe_len 65536 type SYSTEM num_stripes 1 stripe 0 devid 1 offset 0 dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520) chunk length 8388608 owner 2 stripe_len 65536 type SYSTEM|DUP num_stripes 2 stripe 0 devid 1 offset 20971520 dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 stripe 1 devid 1 offset 29360128 dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22 backup_roots[4]: backup 0: backup_tree_root: 889143296 gen: 1757933 level: 0 backup_chunk_root: 20987904 gen: 932006 level: 0 backup_extent_root: 81152 gen: 1757933 level: 2 backup_fs_root: 889716736 gen: 1757934 level: 2 backup_dev_root: 307560448 gen: 1673227 level: 0 backup_csum_root: 887898112 gen: 1757934 level: 2 backup_total_bytes: 3053696 backup_bytes_used: 16937803776 backup_num_devices: 1 backup 1: backup_tree_root: 882311168 gen: 1757930 level: 0 backup_chunk_root: 20987904 gen: 932006 level: 0 backup_extent_root: 879738880 gen: 1757931 level: 2 backup_fs_root: 883097600 gen: 1757931 level: 2 backup_dev_root: 307560448 gen: 1673227 level: 0 backup_csum_root: 883212288 gen: 1757931 level: 2 backup_total_bytes: 3053696 backup_bytes_used: 16943640576 backup_num_devices: 1 backup 2: backup_tree_root: 881082368 gen: 1757931 level: 0 backup_chunk_root: 20987904 gen: 932006 level: 0 backup_extent_root: 879738880 gen: 1757931 level: 2 backup_fs_root: 883654656 gen: 1757932 level: 2 backup_dev_root: 307560448 gen: 1673227 level: 0 backup_csum_root: 883703808 gen: 1757932 level: 2 backup_total_bytes: 3053696 backup_bytes_used: 16943722496 backup_num_devices: 1 backup 3: backup_tree_root: 887865344 gen: 1757932 level: 0 backup_chunk_root: 20987904 gen: 932006 level: 0 backup_extent_root: 81152 gen: 1757933 level: 2 backup_fs_root: 888750080 gen: 1757933 level: 2 backup_dev_root: 307560448 gen: 1673227 level: 0 backup_csum_root: 32000 gen: 1757933 level: 2 backup_total_bytes: 3053696 backup_bytes_used: 16937803776 backup_num_devices: 1 superblock: bytenr=67108864, device=sdcard.iso - csum 0x
Re: Salvage files from broken btrfs
On 31.10.2018 at 05:56 Chris Murphy wrote: > On Tue, Oct 30, 2018 at 4:11 PM, Mirko Klingmann wrote: >> Hi all, >> >> my btrfs root file system on a SD card broke down and did not mount anymore. > It might mount with -o ro,nologreplay > > Typically an SD card will break in a way that it can't write, and > mount will just hang (with mmcblk errors). Mounting with both ro and > nologreplay will ensure no writes are needed, allowing the mount to > succeed. of course any changes that are in the log tree will be > missing so recent transactions may be unrecoverable but so far I've > had good luck recovering from broken SD cards this way. > No luck with these options. The error still persists with same output in "dmesg". Thanks for your effort... -- Mirko
Re: Salvage files from broken btrfs
On Tue, Oct 30, 2018 at 4:11 PM, Mirko Klingmann wrote: > Hi all, > > my btrfs root file system on a SD card broke down and did not mount anymore. It might mount with -o ro,nologreplay Typically an SD card will break in a way that it can't write, and mount will just hang (with mmcblk errors). Mounting with both ro and nologreplay will ensure no writes are needed, allowing the mount to succeed. of course any changes that are in the log tree will be missing so recent transactions may be unrecoverable but so far I've had good luck recovering from broken SD cards this way. -- Chris Murphy
Re: Salvage files from broken btrfs
On 2018/10/31 上午4:11, Mirko Klingmann wrote: > Hi all, > > my btrfs root file system on a SD card broke down and did not mount anymore. > > In retrospective, I think it reached its endurance, so I know that there > is nothing to repair. All I want to do is to salvage some configuration > and data files from the remains left in my ISO file copy. The SD card is > no longer readable, so all I have is the 30GB "dd" copy of the btrfs > partition. > > I also tried some things on the ISO file I later found I shouldn't have > done with the "btrfs" tools, which I think broke the file system in it > even more. Not exactly. For your case, your best friend would be btrfs-restore + some way to recover chunk tree. Unless you want to do all salvage manually. > > So at this stage, this is the "dmesg" output when trying to mount the > ISO file, which then fails: > > [ 249.239883] BTRFS: device fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c > devid 1 transid 1757933 /dev/loop2 > [ 249.241504] BTRFS info (device loop2): disk space caching is enabled > [ 249.275950] BTRFS error (device loop2): bad tree block start 0 20987904 > [ 249.280936] BTRFS error (device loop2): bad tree block start 0 20987904 > [ 249.280946] BTRFS error (device loop2): failed to read chunk root > [ 249.336291] BTRFS error (device loop2): open_ctree failed > > Output of "uname -a": > > Linux desinfect 4.13.0-39-generic #44~16.04.1-Ubuntu SMP Thu Apr 5 > 16:43:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > > Output of "btrfs --version": > > btrfs-progs v4.4 > > When reading the ISO file with "Active@ Disk Editor" (a hex file editor) > I find a super block at offset 0x1 that looks like this: That's the primary super block. BTW, you could use just 'grep' to locate btrfs superblock: # grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" It's better to use "btrfs ins dump-super -fFa" to show the superblock info in a human readable way. > > B8E15DD74235AA4F77214E7397F07FE0E9A3CE9C010001005F42485266535F4DEDD21A40FF34004040010E35E023076092F1030006000110004000400010E200A6380E00610100E0230700E02307100010001090185CF6B93749BBB19191D08677EE224235AA4F77214E7397F07FE0E9A3CE9C > > The super block at offset 0x400 is zeroed out. > > When looking at the addresses of chunk root (0x1404000), root of tree > root (0x34FF4000) and log tree root (0x350E) in the first super > block they are all zeroed out as well. So I think I understand why the > error "failed to read chunk root" crops up. Not a big problem really. We can still find the chunk root just using the system chunk array (and some time) easily, since normally system chunks are small and we can afford checking all tree blocks in that range. That's why I'm recommended to use "btrfs ins dump-super" to inspect the superblock, as that allow us to inspect system chunk array. IIRC btrfs-find-root is pretty good at such job, if that works. > > If I try to "restore" using "btrfs restore sdcard.iso /outdir" I get > this output: > > checksum verify failed on 20987904 found E4E3BDB6 wanted > checksum verify failed on 20987904 found E4E3BDB6 wanted > checksum verify failed on 20987904 found E4E3BDB6 wanted > checksum verify failed on 20987904 found E4E3BDB6 wanted > bytenr mismatch, want=20987904, have=0 > Couldn't read chunk root > Could not open root, trying backup super > No valid Btrfs found on sdcard.iso > Could not open root, trying backup super > Superblock bytenr is larger than device size > Could not open root, trying backup super My plan for such recovery is: 1) btrfs ins dump-super to make sure system chunk array is valid 2) btrfs-find-root to find any valid chunk tree blocks 3) pass that chunk tree bytenr to btrfs-restore Unfortunately, btrfs-restore doesn't support specifying chunk root yet. But it's pretty easy to add such support. So, please provide the "btrfs ins dump-super -Ffa" output to start with. > > And, finally, I can see "/etc" someplace near "fstab" in the ISO which > looks like a directory listing as well as content of files I remember, > which tells me, that the data I still in there somewhere. > > So, what can I do to get the files I need out of this blob. I am willing > to follow data pointers as described in > https://btrfs.wiki.kernel.org/index.php/On-disk_Format in the hex editor > and copy the data from there. If there is something that a hex editor is really needed, it means we should add a new function in btrfs-progs. :) Thanks, Qu > > Can anyone give me any pointers into the ISO file (maybe starting from > the super block) to help me extract the
Salvage files from broken btrfs
Hi all, my btrfs root file system on a SD card broke down and did not mount anymore. In retrospective, I think it reached its endurance, so I know that there is nothing to repair. All I want to do is to salvage some configuration and data files from the remains left in my ISO file copy. The SD card is no longer readable, so all I have is the 30GB "dd" copy of the btrfs partition. I also tried some things on the ISO file I later found I shouldn't have done with the "btrfs" tools, which I think broke the file system in it even more. So at this stage, this is the "dmesg" output when trying to mount the ISO file, which then fails: [ 249.239883] BTRFS: device fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c devid 1 transid 1757933 /dev/loop2 [ 249.241504] BTRFS info (device loop2): disk space caching is enabled [ 249.275950] BTRFS error (device loop2): bad tree block start 0 20987904 [ 249.280936] BTRFS error (device loop2): bad tree block start 0 20987904 [ 249.280946] BTRFS error (device loop2): failed to read chunk root [ 249.336291] BTRFS error (device loop2): open_ctree failed Output of "uname -a": Linux desinfect 4.13.0-39-generic #44~16.04.1-Ubuntu SMP Thu Apr 5 16:43:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Output of "btrfs --version": btrfs-progs v4.4 When reading the ISO file with "Active@ Disk Editor" (a hex file editor) I find a super block at offset 0x1 that looks like this: B8E15DD74235AA4F77214E7397F07FE0E9A3CE9C010001005F42485266535F4DEDD21A40FF34004040010E35E023076092F1030006000110004000400010E200A6380E00610100E0230700E02307100010001090185CF6B93749BBB19191D08677EE224235AA4F77214E7397F07FE0E9A3CE9C The super block at offset 0x400 is zeroed out. When looking at the addresses of chunk root (0x1404000), root of tree root (0x34FF4000) and log tree root (0x350E) in the first super block they are all zeroed out as well. So I think I understand why the error "failed to read chunk root" crops up. If I try to "restore" using "btrfs restore sdcard.iso /outdir" I get this output: checksum verify failed on 20987904 found E4E3BDB6 wanted checksum verify failed on 20987904 found E4E3BDB6 wanted checksum verify failed on 20987904 found E4E3BDB6 wanted checksum verify failed on 20987904 found E4E3BDB6 wanted bytenr mismatch, want=20987904, have=0 Couldn't read chunk root Could not open root, trying backup super No valid Btrfs found on sdcard.iso Could not open root, trying backup super Superblock bytenr is larger than device size Could not open root, trying backup super And, finally, I can see "/etc" someplace near "fstab" in the ISO which looks like a directory listing as well as content of files I remember, which tells me, that the data I still in there somewhere. So, what can I do to get the files I need out of this blob. I am willing to follow data pointers as described in https://btrfs.wiki.kernel.org/index.php/On-disk_Format in the hex editor and copy the data from there. Can anyone give me any pointers into the ISO file (maybe starting from the super block) to help me extract the data I need? Cheers, Mirko
