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 0x10000 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" <device> It's better to use "btrfs ins dump-super -fFa" to show the superblock info in a human readable way. > > B8E15DD7000000000000000000000000000000000000000000000000000000004235AA4F77214E7397F07FE0E9A3CE9C000001000000000001000000000000005F42485266535F4DEDD21A00000000000040FF3400000000004040010000000000000E350000000000000000000000000000E02307000000006092F1030000000600000000000000010000000000000000100000004000000040000000100000E2000000A6380E0000000000000000000000000000000000000000006100000000000000000000000001000000000000000000E023070000000000E0230700000000100000001000000010000000000000000000000000000000000000000000000000000000000000000090185CF6B93749BBB19191D08677EE224235AA4F77214E7397F07FE0E9A3CE9C > > The super block at offset 0x4000000 is zeroed out. > > When looking at the addresses of chunk root (0x1404000), root of tree > root (0x34FF4000) and log tree root (0x350E0000) 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 00000000 > checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000 > checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000 > checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000 > 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 data I need? > > Cheers, > > Mirko > >
Attachment:
signature.asc
Description: OpenPGP digital signature
