* Corrupt F2FS partition - fsck is useless
@ 2018-08-24 4:31 Luke Dashjr
2018-08-24 13:08 ` Chao Yu
2018-08-28 7:37 ` Jaegeuk Kim
0 siblings, 2 replies; 9+ messages in thread
From: Luke Dashjr @ 2018-08-24 4:31 UTC (permalink / raw)
To: linux-f2fs-devel
One of my phones recently decided to corrupt its /data partition. I managed to
copy it to my PC before wiping the phone completely, but efforts to mount or
otherwise recover data from it have proven futile.
Mounting fails with dmesg showing:
[433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
[433918.995566] F2FS-fs (loop0): Failed to read root inode
[433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
[433919.003598] F2FS-fs (loop0): Failed to read root inode
f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
(NOTE: fsck output at https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz )
#0 0x0000555555559911 in memcpy (__len=18446744072369571950,
__src=0x5555557d644c, __dest=0x7fffffffd2d0)
at /usr/include/bits/string_fortified.h:34
#1 convert_encrypted_name (
name=name@entry=0x5555557d644c "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
[\227\266\221R1\332\331!
\004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\352\032i\222]\326Ӌ\027^\030\226\005&\006|
\333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006g\034u]\003\002)\005!
\200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\214\b!
\361\241\213\370\336
{\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", enc_name=<optimized
out>)
at fsck.c:1132
#2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>,
node=0x5555557d63f0, name=1) at mount.c:183
#3 0x000055555556424f in print_node_info (sbi=<optimized out>,
node_block=<optimized out>, verbose=<optimized out>)
at mount.c:277
#4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 <gfsck>,
nid=nid@entry=2875, force=force@entry=1)
at dump.c:520
#5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at fsck.c:2568
#6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 <gfsck>) at main.c:569
#7 main (argc=<optimized out>, argv=<optimized out>) at main.c:726
If I tell it NOT to recover lost+found, it completes, but mounting still
fails:
(NOTE: fsck output https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz )
[434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint
[434361.825628] F2FS-fs (loop0): Failed to read root inode
[434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
[434361.840620] F2FS-fs (loop0): Failed to read root inode
Any ideas on how to get at least some data recovered from this?
(Particularly the encryption key(s) Android stores at /data/misc/vold/*.key)
Thanks,
Luke
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Corrupt F2FS partition - fsck is useless 2018-08-24 4:31 Corrupt F2FS partition - fsck is useless Luke Dashjr @ 2018-08-24 13:08 ` Chao Yu 2018-08-24 14:38 ` Luke Dashjr 2018-08-28 7:37 ` Jaegeuk Kim 1 sibling, 1 reply; 9+ messages in thread From: Chao Yu @ 2018-08-24 13:08 UTC (permalink / raw) To: Luke Dashjr, linux-f2fs-devel Hi Luke, I think the problem here is that we don't even start to traverse and check all directories and files due to we encounter root inode sanity check failure. [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30] footer.ino[0x30333238] Could you dump root node info with below command: dump.f2fs -i 3 -d 1 <your_device_path> Thanks, On 2018/8/24 12:31, Luke Dashjr wrote: > One of my phones recently decided to corrupt its /data partition. I managed to > copy it to my PC before wiping the phone completely, but efforts to mount or > otherwise recover data from it have proven futile. > > Mounting fails with dmesg showing: > > [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3, > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690] > [433918.995566] F2FS-fs (loop0): Failed to read root inode > [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3, > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690] > [433919.003598] F2FS-fs (loop0): Failed to read root inode > > f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found: > > (NOTE: fsck output at https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) > #0 0x0000555555559911 in memcpy (__len=18446744072369571950, > __src=0x5555557d644c, __dest=0x7fffffffd2d0) > at /usr/include/bits/string_fortified.h:34 > #1 convert_encrypted_name ( > name=name@entry=0x5555557d644c "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4 > [\227\266\221R1\332\331! > \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\352\032i\222]\326Ӌ\027^\030\226\005&\006| > \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006g\034u]\003\002)\005! > \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\214\b! > \361\241\213\370\336 > {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352 > 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666, > new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", enc_name=<optimized > out>) > at fsck.c:1132 > #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>, > node=0x5555557d63f0, name=1) at mount.c:183 > #3 0x000055555556424f in print_node_info (sbi=<optimized out>, > node_block=<optimized out>, verbose=<optimized out>) > at mount.c:277 > #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 <gfsck>, > nid=nid@entry=2875, force=force@entry=1) > at dump.c:520 > #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at fsck.c:2568 > #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 <gfsck>) at main.c:569 > #7 main (argc=<optimized out>, argv=<optimized out>) at main.c:726 > > If I tell it NOT to recover lost+found, it completes, but mounting still > fails: > > (NOTE: fsck output https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) > [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint > [434361.825628] F2FS-fs (loop0): Failed to read root inode > [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint > [434361.840620] F2FS-fs (loop0): Failed to read root inode > > Any ideas on how to get at least some data recovered from this? > (Particularly the encryption key(s) Android stores at /data/misc/vold/*.key) > > Thanks, > > Luke > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless 2018-08-24 13:08 ` Chao Yu @ 2018-08-24 14:38 ` Luke Dashjr 2018-08-24 15:59 ` Chao Yu 0 siblings, 1 reply; 9+ messages in thread From: Luke Dashjr @ 2018-08-24 14:38 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel Info: Debug level = 1 Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 12597656 (6151 MB) Info: MKFS version "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016" Info: FSCK version from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" Info: superblock features = 0 : Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000 +--------------------------------------------------------+ | Super block | +--------------------------------------------------------+ magic [0xf2f52010 : 4076150800] major_ver [0x 1 : 1] volum_name [] minor_ver [0x 2 : 2] log_sectorsize [0x 9 : 9] log_sectors_per_block [0x 3 : 3] log_blocksize [0x c : 12] log_blocks_per_seg [0x 9 : 9] segs_per_sec [0x 1 : 1] secs_per_zone [0x 1 : 1] checksum_offset [0x 0 : 0] block_count [0x 13ffe0 : 1310688] section_count [0x 9e9 : 2537] segment_count [0x 9fe : 2558] segment_count_ckpt [0x 2 : 2] segment_count_sit [0x 2 : 2] segment_count_nat [0x c : 12] segment_count_ssa [0x 5 : 5] segment_count_main [0x 9e9 : 2537] segment0_blkaddr [0x 200 : 512] cp_blkaddr [0x 200 : 512] sit_blkaddr [0x 600 : 1536] nat_blkaddr [0x a00 : 2560] ssa_blkaddr [0x 2200 : 8704] main_blkaddr [0x 2c00 : 11264] root_ino [0x 3 : 3] node_ino [0x 1 : 1] meta_ino [0x 2 : 2] cp_payload [0x 0 : 0] version Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018 Info: total FS sectors = 10485504 (5119 MB) Info: CKPT version = 1f339f +--------------------------------------------------------+ | Checkpoint | +--------------------------------------------------------+ checkpoint_ver [0x 1f339f : 2044831] user_block_count [0x 127a00 : 1210880] valid_block_count [0x bfc23 : 785443] rsvd_segment_count [0x 30 : 48] overprov_segment_count [0x ac : 172] free_segment_count [0x 30 : 48] alloc_type[CURSEG_HOT_NODE] [0x 0 : 0] alloc_type[CURSEG_WARM_NODE] [0x 0 : 0] alloc_type[CURSEG_COLD_NODE] [0x 0 : 0] cur_node_segno[0] [0x 4bc : 1212] cur_node_segno[1] [0x 552 : 1362] cur_node_segno[2] [0x 912 : 2322] cur_node_blkoff[0] [0x bc : 188] cur_node_blkoff[1] [0x 79 : 121] cur_node_blkoff[2] [0x 169 : 361] alloc_type[CURSEG_HOT_DATA] [0x 0 : 0] alloc_type[CURSEG_WARM_DATA] [0x 0 : 0] alloc_type[CURSEG_COLD_DATA] [0x 0 : 0] cur_data_segno[0] [0x 576 : 1398] cur_data_segno[1] [0x 665 : 1637] cur_data_segno[2] [0x 66e : 1646] cur_data_blkoff[0] [0x 0 : 0] cur_data_blkoff[1] [0x 0 : 0] cur_data_blkoff[2] [0x 0 : 0] ckpt_flags [0x 4 : 4] cp_pack_total_block_count [0x 3 : 3] cp_pack_start_sum [0x 1 : 1] valid_node_count [0x 5e52 : 24146] valid_inode_count [0x 5c97 : 23703] next_free_nid [0x 35c78 : 220280] sit_ver_bitmap_bytesize [0x 40 : 64] nat_ver_bitmap_bytesize [0x 180 : 384] checksum_offset [0x ffc : 4092] elapsed_time [0x183e8f20f43 : 1666060521283] sit_nat_version_bitmap[0] [0x 9 : 9] [dump_node: 500] Node ID [0x3] [dump_node: 501] nat_entry.block_addr [0x11fa0e] [dump_node: 502] nat_entry.version [0x0] [dump_node: 503] nat_entry.ino [0x3] [dump_node: 510] node_blk.footer.ino [0x30333238] [dump_node: 511] node_blk.footer.nid [0x30352c30] [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or indirect node. [0] [0x3933332c : 959656748] [1] [0x3633322c : 909324844] [2] [0x30303030 : 808464432] [3] [0x3134312c : 825504044] [4] [0x2c303639 : 741357113] [5] [0x3636322d : 909521453] [6] [0x2c363331 : 741749553] [7] [0x31303432 : 825242674] [8] [0x2c303030 : 741355568] [9] [0x472c3532 : 1194079538] [10] [0x2c646f6f : 744779631] Invalid (i)node block Info: checkpoint state = 4 : compacted_summary sudden-power-off Done. On Friday 24 August 2018 13:08:30 Chao Yu wrote: > Hi Luke, > > I think the problem here is that we don't even start to traverse and check > all directories and files due to we encounter root inode sanity check > failure. > > [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30] > footer.ino[0x30333238] > > Could you dump root node info with below command: > > dump.f2fs -i 3 -d 1 <your_device_path> > > Thanks, > > On 2018/8/24 12:31, Luke Dashjr wrote: > > One of my phones recently decided to corrupt its /data partition. I > > managed to copy it to my PC before wiping the phone completely, but > > efforts to mount or otherwise recover data from it have proven futile. > > > > Mounting fails with dmesg showing: > > > > [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3, > > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424 > >82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to read > > root inode > > [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3, > > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424 > >82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to read > > root inode > > > > f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found: > > > > (NOTE: fsck output at > > https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0 > > 0x0000555555559911 in memcpy (__len=18446744072369571950, > > __src=0x5555557d644c, __dest=0x7fffffffd2d0) > > at /usr/include/bits/string_fortified.h:34 > > #1 convert_encrypted_name ( > > name=name@entry=0x5555557d644c > > "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4 > > [\227\266\221R1\332\331! > > \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\3 > >52\032i\222]\326Ӌ\027^\030\226\005&\006| > > \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006 > >g\034u]\003\002)\005! > > \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di > >\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\21 > >4\b! \361\241\213\370\336 > > {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352 > > 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666, > > new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", > > enc_name=<optimized out>) > > at fsck.c:1132 > > #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>, > > node=0x5555557d63f0, name=1) at mount.c:183 > > #3 0x000055555556424f in print_node_info (sbi=<optimized out>, > > node_block=<optimized out>, verbose=<optimized out>) > > at mount.c:277 > > #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 > > <gfsck>, nid=nid@entry=2875, force=force@entry=1) > > at dump.c:520 > > #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at > > fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 > > <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized > > out>) at main.c:726 > > > > If I tell it NOT to recover lost+found, it completes, but mounting still > > fails: > > > > (NOTE: fsck output > > https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) [434361.813196] > > F2FS-fs (loop0): Found nat_bits in checkpoint > > [434361.825628] F2FS-fs (loop0): Failed to read root inode > > [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint > > [434361.840620] F2FS-fs (loop0): Failed to read root inode > > > > Any ideas on how to get at least some data recovered from this? > > (Particularly the encryption key(s) Android stores at > > /data/misc/vold/*.key) > > > > Thanks, > > > > Luke > > > > ------------------------------------------------------------------------- > >----- Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Linux-f2fs-devel mailing list > > Linux-f2fs-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless 2018-08-24 14:38 ` Luke Dashjr @ 2018-08-24 15:59 ` Chao Yu 2018-08-28 9:28 ` Chao Yu 0 siblings, 1 reply; 9+ messages in thread From: Chao Yu @ 2018-08-24 15:59 UTC (permalink / raw) To: Luke Dashjr; +Cc: linux-f2fs-devel On 2018/8/24 22:38, Luke Dashjr wrote: > Info: Debug level = 1 > Info: Segments per section = 1 > Info: Sections per zone = 1 > Info: sector size = 512 > Info: total sectors = 12597656 (6151 MB) > Info: MKFS version > "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) (gcc > version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016" > Info: FSCK version > from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 > (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" > to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 > (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" > Info: superblock features = 0 : > Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000 > > +--------------------------------------------------------+ > | Super block | > +--------------------------------------------------------+ > magic [0xf2f52010 : 4076150800] > major_ver [0x 1 : 1] > volum_name [] > minor_ver [0x 2 : 2] > log_sectorsize [0x 9 : 9] > log_sectors_per_block [0x 3 : 3] > log_blocksize [0x c : 12] > log_blocks_per_seg [0x 9 : 9] > segs_per_sec [0x 1 : 1] > secs_per_zone [0x 1 : 1] > checksum_offset [0x 0 : 0] > block_count [0x 13ffe0 : 1310688] > section_count [0x 9e9 : 2537] > segment_count [0x 9fe : 2558] > segment_count_ckpt [0x 2 : 2] > segment_count_sit [0x 2 : 2] > segment_count_nat [0x c : 12] > segment_count_ssa [0x 5 : 5] > segment_count_main [0x 9e9 : 2537] > segment0_blkaddr [0x 200 : 512] > cp_blkaddr [0x 200 : 512] > sit_blkaddr [0x 600 : 1536] > nat_blkaddr [0x a00 : 2560] > ssa_blkaddr [0x 2200 : 8704] > main_blkaddr [0x 2c00 : 11264] > root_ino [0x 3 : 3] > node_ino [0x 1 : 1] > meta_ino [0x 2 : 2] > cp_payload [0x 0 : 0] > version Linux version 4.17.11-gentoo (root@ishibashi) > (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 > 04:07:16 UTC 2018 > Info: total FS sectors = 10485504 (5119 MB) > Info: CKPT version = 1f339f > > +--------------------------------------------------------+ > | Checkpoint | > +--------------------------------------------------------+ > checkpoint_ver [0x 1f339f : 2044831] > user_block_count [0x 127a00 : 1210880] > valid_block_count [0x bfc23 : 785443] > rsvd_segment_count [0x 30 : 48] > overprov_segment_count [0x ac : 172] > free_segment_count [0x 30 : 48] > alloc_type[CURSEG_HOT_NODE] [0x 0 : 0] > alloc_type[CURSEG_WARM_NODE] [0x 0 : 0] > alloc_type[CURSEG_COLD_NODE] [0x 0 : 0] > cur_node_segno[0] [0x 4bc : 1212] > cur_node_segno[1] [0x 552 : 1362] > cur_node_segno[2] [0x 912 : 2322] > cur_node_blkoff[0] [0x bc : 188] > cur_node_blkoff[1] [0x 79 : 121] > cur_node_blkoff[2] [0x 169 : 361] > alloc_type[CURSEG_HOT_DATA] [0x 0 : 0] > alloc_type[CURSEG_WARM_DATA] [0x 0 : 0] > alloc_type[CURSEG_COLD_DATA] [0x 0 : 0] > cur_data_segno[0] [0x 576 : 1398] > cur_data_segno[1] [0x 665 : 1637] > cur_data_segno[2] [0x 66e : 1646] > cur_data_blkoff[0] [0x 0 : 0] > cur_data_blkoff[1] [0x 0 : 0] > cur_data_blkoff[2] [0x 0 : 0] > ckpt_flags [0x 4 : 4] > cp_pack_total_block_count [0x 3 : 3] > cp_pack_start_sum [0x 1 : 1] > valid_node_count [0x 5e52 : 24146] > valid_inode_count [0x 5c97 : 23703] > next_free_nid [0x 35c78 : 220280] > sit_ver_bitmap_bytesize [0x 40 : 64] > nat_ver_bitmap_bytesize [0x 180 : 384] > checksum_offset [0x ffc : 4092] > elapsed_time [0x183e8f20f43 : 1666060521283] > sit_nat_version_bitmap[0] [0x 9 : 9] > > > [dump_node: 500] Node ID [0x3] > [dump_node: 501] nat_entry.block_addr [0x11fa0e] > [dump_node: 502] nat_entry.version [0x0] > [dump_node: 503] nat_entry.ino [0x3] > [dump_node: 510] node_blk.footer.ino [0x30333238] > [dump_node: 511] node_blk.footer.nid [0x30352c30] > [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or > indirect node. > [0] [0x3933332c : 959656748] > [1] [0x3633322c : 909324844] > [2] [0x30303030 : 808464432] > [3] [0x3134312c : 825504044] > [4] [0x2c303639 : 741357113] > [5] [0x3636322d : 909521453] > [6] [0x2c363331 : 741749553] > [7] [0x31303432 : 825242674] > [8] [0x2c303030 : 741355568] > [9] [0x472c3532 : 1194079538] > [10] [0x2c646f6f : 744779631] It looks like this block contains normal characters instead of fields of regular inode structure, so I think root inode's block or nat_entry.blkaddr may be corrupted. Let me think about the way to rebuild root inode. Thanks, > Invalid (i)node block > > Info: checkpoint state = 4 : compacted_summary sudden-power-off > > Done. > > > On Friday 24 August 2018 13:08:30 Chao Yu wrote: >> Hi Luke, >> >> I think the problem here is that we don't even start to traverse and check >> all directories and files due to we encounter root inode sanity check >> failure. >> >> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30] >> footer.ino[0x30333238] >> >> Could you dump root node info with below command: >> >> dump.f2fs -i 3 -d 1 <your_device_path> >> >> Thanks, >> >> On 2018/8/24 12:31, Luke Dashjr wrote: >>> One of my phones recently decided to corrupt its /data partition. I >>> managed to copy it to my PC before wiping the phone completely, but >>> efforts to mount or otherwise recover data from it have proven futile. >>> >>> Mounting fails with dmesg showing: >>> >>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3, >>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424 >>> 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to read >>> root inode >>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3, >>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424 >>> 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to read >>> root inode >>> >>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found: >>> >>> (NOTE: fsck output at >>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0 >>> 0x0000555555559911 in memcpy (__len=18446744072369571950, >>> __src=0x5555557d644c, __dest=0x7fffffffd2d0) >>> at /usr/include/bits/string_fortified.h:34 >>> #1 convert_encrypted_name ( >>> name=name@entry=0x5555557d644c >>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4 >>> [\227\266\221R1\332\331! >>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\3 >>> 52\032i\222]\326Ӌ\027^\030\226\005&\006| >>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006 >>> g\034u]\003\002)\005! >>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di >>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\21 >>> 4\b! \361\241\213\370\336 >>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352 >>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666, >>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", >>> enc_name=<optimized out>) >>> at fsck.c:1132 >>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>, >>> node=0x5555557d63f0, name=1) at mount.c:183 >>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>, >>> node_block=<optimized out>, verbose=<optimized out>) >>> at mount.c:277 >>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 >>> <gfsck>, nid=nid@entry=2875, force=force@entry=1) >>> at dump.c:520 >>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at >>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 >>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized >>> out>) at main.c:726 >>> >>> If I tell it NOT to recover lost+found, it completes, but mounting still >>> fails: >>> >>> (NOTE: fsck output >>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) [434361.813196] >>> F2FS-fs (loop0): Found nat_bits in checkpoint >>> [434361.825628] F2FS-fs (loop0): Failed to read root inode >>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint >>> [434361.840620] F2FS-fs (loop0): Failed to read root inode >>> >>> Any ideas on how to get at least some data recovered from this? >>> (Particularly the encryption key(s) Android stores at >>> /data/misc/vold/*.key) >>> >>> Thanks, >>> >>> Luke >>> >>> ------------------------------------------------------------------------- >>> ----- Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Linux-f2fs-devel mailing list >>> Linux-f2fs-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless 2018-08-24 15:59 ` Chao Yu @ 2018-08-28 9:28 ` Chao Yu 2018-08-28 9:47 ` Luke Dashjr 0 siblings, 1 reply; 9+ messages in thread From: Chao Yu @ 2018-08-28 9:28 UTC (permalink / raw) To: Chao Yu, Luke Dashjr; +Cc: linux-f2fs-devel Hi Luke, Do you have tried Sheng Yong's patch? BTW, before recovering root inode, it needs to backup your entire image. On 2018/8/24 23:59, Chao Yu wrote: > On 2018/8/24 22:38, Luke Dashjr wrote: >> Info: Debug level = 1 >> Info: Segments per section = 1 >> Info: Sections per zone = 1 >> Info: sector size = 512 >> Info: total sectors = 12597656 (6151 MB) >> Info: MKFS version >> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) (gcc >> version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016" >> Info: FSCK version >> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 >> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" >> to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 >> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" >> Info: superblock features = 0 : >> Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000 >> >> +--------------------------------------------------------+ >> | Super block | >> +--------------------------------------------------------+ >> magic [0xf2f52010 : 4076150800] >> major_ver [0x 1 : 1] >> volum_name [] >> minor_ver [0x 2 : 2] >> log_sectorsize [0x 9 : 9] >> log_sectors_per_block [0x 3 : 3] >> log_blocksize [0x c : 12] >> log_blocks_per_seg [0x 9 : 9] >> segs_per_sec [0x 1 : 1] >> secs_per_zone [0x 1 : 1] >> checksum_offset [0x 0 : 0] >> block_count [0x 13ffe0 : 1310688] >> section_count [0x 9e9 : 2537] >> segment_count [0x 9fe : 2558] >> segment_count_ckpt [0x 2 : 2] >> segment_count_sit [0x 2 : 2] >> segment_count_nat [0x c : 12] >> segment_count_ssa [0x 5 : 5] >> segment_count_main [0x 9e9 : 2537] >> segment0_blkaddr [0x 200 : 512] >> cp_blkaddr [0x 200 : 512] >> sit_blkaddr [0x 600 : 1536] >> nat_blkaddr [0x a00 : 2560] >> ssa_blkaddr [0x 2200 : 8704] >> main_blkaddr [0x 2c00 : 11264] >> root_ino [0x 3 : 3] >> node_ino [0x 1 : 1] >> meta_ino [0x 2 : 2] >> cp_payload [0x 0 : 0] >> version Linux version 4.17.11-gentoo (root@ishibashi) >> (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 >> 04:07:16 UTC 2018 >> Info: total FS sectors = 10485504 (5119 MB) >> Info: CKPT version = 1f339f >> >> +--------------------------------------------------------+ >> | Checkpoint | >> +--------------------------------------------------------+ >> checkpoint_ver [0x 1f339f : 2044831] >> user_block_count [0x 127a00 : 1210880] >> valid_block_count [0x bfc23 : 785443] >> rsvd_segment_count [0x 30 : 48] >> overprov_segment_count [0x ac : 172] >> free_segment_count [0x 30 : 48] >> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0] >> alloc_type[CURSEG_WARM_NODE] [0x 0 : 0] >> alloc_type[CURSEG_COLD_NODE] [0x 0 : 0] >> cur_node_segno[0] [0x 4bc : 1212] >> cur_node_segno[1] [0x 552 : 1362] >> cur_node_segno[2] [0x 912 : 2322] >> cur_node_blkoff[0] [0x bc : 188] >> cur_node_blkoff[1] [0x 79 : 121] >> cur_node_blkoff[2] [0x 169 : 361] >> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0] >> alloc_type[CURSEG_WARM_DATA] [0x 0 : 0] >> alloc_type[CURSEG_COLD_DATA] [0x 0 : 0] >> cur_data_segno[0] [0x 576 : 1398] >> cur_data_segno[1] [0x 665 : 1637] >> cur_data_segno[2] [0x 66e : 1646] >> cur_data_blkoff[0] [0x 0 : 0] >> cur_data_blkoff[1] [0x 0 : 0] >> cur_data_blkoff[2] [0x 0 : 0] >> ckpt_flags [0x 4 : 4] >> cp_pack_total_block_count [0x 3 : 3] >> cp_pack_start_sum [0x 1 : 1] >> valid_node_count [0x 5e52 : 24146] >> valid_inode_count [0x 5c97 : 23703] >> next_free_nid [0x 35c78 : 220280] >> sit_ver_bitmap_bytesize [0x 40 : 64] >> nat_ver_bitmap_bytesize [0x 180 : 384] >> checksum_offset [0x ffc : 4092] >> elapsed_time [0x183e8f20f43 : 1666060521283] >> sit_nat_version_bitmap[0] [0x 9 : 9] >> >> >> [dump_node: 500] Node ID [0x3] >> [dump_node: 501] nat_entry.block_addr [0x11fa0e] >> [dump_node: 502] nat_entry.version [0x0] >> [dump_node: 503] nat_entry.ino [0x3] >> [dump_node: 510] node_blk.footer.ino [0x30333238] >> [dump_node: 511] node_blk.footer.nid [0x30352c30] >> [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or >> indirect node. >> [0] [0x3933332c : 959656748] >> [1] [0x3633322c : 909324844] >> [2] [0x30303030 : 808464432] >> [3] [0x3134312c : 825504044] >> [4] [0x2c303639 : 741357113] >> [5] [0x3636322d : 909521453] >> [6] [0x2c363331 : 741749553] >> [7] [0x31303432 : 825242674] >> [8] [0x2c303030 : 741355568] >> [9] [0x472c3532 : 1194079538] >> [10] [0x2c646f6f : 744779631] > > It looks like this block contains normal characters instead of fields of regular > inode structure, so I think root inode's block or nat_entry.blkaddr may be > corrupted. > > Let me think about the way to rebuild root inode. > > Thanks, > >> Invalid (i)node block >> >> Info: checkpoint state = 4 : compacted_summary sudden-power-off >> >> Done. >> >> >> On Friday 24 August 2018 13:08:30 Chao Yu wrote: >>> Hi Luke, >>> >>> I think the problem here is that we don't even start to traverse and check >>> all directories and files due to we encounter root inode sanity check >>> failure. >>> >>> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30] >>> footer.ino[0x30333238] >>> >>> Could you dump root node info with below command: >>> >>> dump.f2fs -i 3 -d 1 <your_device_path> >>> >>> Thanks, >>> >>> On 2018/8/24 12:31, Luke Dashjr wrote: >>>> One of my phones recently decided to corrupt its /data partition. I >>>> managed to copy it to my PC before wiping the phone completely, but >>>> efforts to mount or otherwise recover data from it have proven futile. >>>> >>>> Mounting fails with dmesg showing: >>>> >>>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3, >>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424 >>>> 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to read >>>> root inode >>>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3, >>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424 >>>> 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to read >>>> root inode >>>> >>>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found: >>>> >>>> (NOTE: fsck output at >>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0 >>>> 0x0000555555559911 in memcpy (__len=18446744072369571950, >>>> __src=0x5555557d644c, __dest=0x7fffffffd2d0) >>>> at /usr/include/bits/string_fortified.h:34 >>>> #1 convert_encrypted_name ( >>>> name=name@entry=0x5555557d644c >>>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4 >>>> [\227\266\221R1\332\331! >>>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\3 >>>> 52\032i\222]\326Ӌ\027^\030\226\005&\006| >>>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006 >>>> g\034u]\003\002)\005! >>>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di >>>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\21 >>>> 4\b! \361\241\213\370\336 >>>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352 >>>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666, >>>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", >>>> enc_name=<optimized out>) >>>> at fsck.c:1132 >>>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>, >>>> node=0x5555557d63f0, name=1) at mount.c:183 >>>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>, >>>> node_block=<optimized out>, verbose=<optimized out>) >>>> at mount.c:277 >>>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 >>>> <gfsck>, nid=nid@entry=2875, force=force@entry=1) >>>> at dump.c:520 >>>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at >>>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 >>>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized >>>> out>) at main.c:726 >>>> >>>> If I tell it NOT to recover lost+found, it completes, but mounting still >>>> fails: >>>> >>>> (NOTE: fsck output >>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) [434361.813196] >>>> F2FS-fs (loop0): Found nat_bits in checkpoint >>>> [434361.825628] F2FS-fs (loop0): Failed to read root inode >>>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint >>>> [434361.840620] F2FS-fs (loop0): Failed to read root inode >>>> >>>> Any ideas on how to get at least some data recovered from this? >>>> (Particularly the encryption key(s) Android stores at >>>> /data/misc/vold/*.key) >>>> >>>> Thanks, >>>> >>>> Luke >>>> >>>> ------------------------------------------------------------------------- >>>> ----- Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Linux-f2fs-devel mailing list >>>> Linux-f2fs-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Linux-f2fs-devel mailing list >> Linux-f2fs-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless 2018-08-28 9:28 ` Chao Yu @ 2018-08-28 9:47 ` Luke Dashjr 2018-08-28 10:34 ` Chao Yu 0 siblings, 1 reply; 9+ messages in thread From: Luke Dashjr @ 2018-08-28 9:47 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel Yes, I did my best to rebase it: https://paste.pound-python.org/show/nWshXUd5QSLbj5ZCugPy/ Unfortunately, it aborts: [ASSERT] (sanity_check_nid: 391) --> nid[0x3] ino is 0 #0 sanity_check_nid (sbi=sbi@entry=0x555555782800 <gfsck>, nid=nid@entry=3, node_blk=node_blk@entry=0x5555557d6fe0, ftype=ftype@entry=F2FS_FT_DIR, ntype=ntype@entry=TYPE_INODE, ni=ni@entry=0x7fffffffd660) at fsck.c:392 #1 0x000055555555d853 in fsck_chk_fs (sbi=<optimized out>, blk_cnt=0x7fffffffd6ec) at fsck.c:997 #2 0x000055555555675c in do_fsck (sbi=0x555555782800 <gfsck>) at main.c:565 #3 main (argc=<optimized out>, argv=<optimized out>) at main.c:725 Luke On Tuesday 28 August 2018 09:28:57 Chao Yu wrote: > Hi Luke, > > Do you have tried Sheng Yong's patch? > > BTW, before recovering root inode, it needs to backup your entire image. > > On 2018/8/24 23:59, Chao Yu wrote: > > On 2018/8/24 22:38, Luke Dashjr wrote: > >> Info: Debug level = 1 > >> Info: Segments per section = 1 > >> Info: Sections per zone = 1 > >> Info: sector size = 512 > >> Info: total sectors = 12597656 (6151 MB) > >> Info: MKFS version > >> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) > >> (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016" > >> Info: FSCK version > >> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 > >> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC > >> 2018" to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version > >> 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 > >> UTC 2018" Info: superblock features = 0 : > >> Info: superblock encrypt level = 0, salt = > >> 00000000000000000000000000000000 > >> > >> +--------------------------------------------------------+ > >> > >> | Super block | > >> > >> +--------------------------------------------------------+ > >> magic [0xf2f52010 : 4076150800] > >> major_ver [0x 1 : 1] > >> volum_name [] > >> minor_ver [0x 2 : 2] > >> log_sectorsize [0x 9 : 9] > >> log_sectors_per_block [0x 3 : 3] > >> log_blocksize [0x c : 12] > >> log_blocks_per_seg [0x 9 : 9] > >> segs_per_sec [0x 1 : 1] > >> secs_per_zone [0x 1 : 1] > >> checksum_offset [0x 0 : 0] > >> block_count [0x 13ffe0 : 1310688] > >> section_count [0x 9e9 : 2537] > >> segment_count [0x 9fe : 2558] > >> segment_count_ckpt [0x 2 : 2] > >> segment_count_sit [0x 2 : 2] > >> segment_count_nat [0x c : 12] > >> segment_count_ssa [0x 5 : 5] > >> segment_count_main [0x 9e9 : 2537] > >> segment0_blkaddr [0x 200 : 512] > >> cp_blkaddr [0x 200 : 512] > >> sit_blkaddr [0x 600 : 1536] > >> nat_blkaddr [0x a00 : 2560] > >> ssa_blkaddr [0x 2200 : 8704] > >> main_blkaddr [0x 2c00 : 11264] > >> root_ino [0x 3 : 3] > >> node_ino [0x 1 : 1] > >> meta_ino [0x 2 : 2] > >> cp_payload [0x 0 : 0] > >> version Linux version 4.17.11-gentoo > >> (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP > >> PREEMPT Sun Jul 29 04:07:16 UTC 2018 > >> Info: total FS sectors = 10485504 (5119 MB) > >> Info: CKPT version = 1f339f > >> > >> +--------------------------------------------------------+ > >> > >> | Checkpoint | > >> > >> +--------------------------------------------------------+ > >> checkpoint_ver [0x 1f339f : 2044831] > >> user_block_count [0x 127a00 : 1210880] > >> valid_block_count [0x bfc23 : 785443] > >> rsvd_segment_count [0x 30 : 48] > >> overprov_segment_count [0x ac : 172] > >> free_segment_count [0x 30 : 48] > >> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0] > >> alloc_type[CURSEG_WARM_NODE] [0x 0 : 0] > >> alloc_type[CURSEG_COLD_NODE] [0x 0 : 0] > >> cur_node_segno[0] [0x 4bc : 1212] > >> cur_node_segno[1] [0x 552 : 1362] > >> cur_node_segno[2] [0x 912 : 2322] > >> cur_node_blkoff[0] [0x bc : 188] > >> cur_node_blkoff[1] [0x 79 : 121] > >> cur_node_blkoff[2] [0x 169 : 361] > >> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0] > >> alloc_type[CURSEG_WARM_DATA] [0x 0 : 0] > >> alloc_type[CURSEG_COLD_DATA] [0x 0 : 0] > >> cur_data_segno[0] [0x 576 : 1398] > >> cur_data_segno[1] [0x 665 : 1637] > >> cur_data_segno[2] [0x 66e : 1646] > >> cur_data_blkoff[0] [0x 0 : 0] > >> cur_data_blkoff[1] [0x 0 : 0] > >> cur_data_blkoff[2] [0x 0 : 0] > >> ckpt_flags [0x 4 : 4] > >> cp_pack_total_block_count [0x 3 : 3] > >> cp_pack_start_sum [0x 1 : 1] > >> valid_node_count [0x 5e52 : 24146] > >> valid_inode_count [0x 5c97 : 23703] > >> next_free_nid [0x 35c78 : 220280] > >> sit_ver_bitmap_bytesize [0x 40 : 64] > >> nat_ver_bitmap_bytesize [0x 180 : 384] > >> checksum_offset [0x ffc : 4092] > >> elapsed_time [0x183e8f20f43 : 1666060521283] > >> sit_nat_version_bitmap[0] [0x 9 : 9] > >> > >> > >> [dump_node: 500] Node ID [0x3] > >> [dump_node: 501] nat_entry.block_addr [0x11fa0e] > >> [dump_node: 502] nat_entry.version [0x0] > >> [dump_node: 503] nat_entry.ino [0x3] > >> [dump_node: 510] node_blk.footer.ino [0x30333238] > >> [dump_node: 511] node_blk.footer.nid [0x30352c30] > >> [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or > >> indirect node. > >> [0] [0x3933332c : 959656748] > >> [1] [0x3633322c : 909324844] > >> [2] [0x30303030 : 808464432] > >> [3] [0x3134312c : 825504044] > >> [4] [0x2c303639 : 741357113] > >> [5] [0x3636322d : 909521453] > >> [6] [0x2c363331 : 741749553] > >> [7] [0x31303432 : 825242674] > >> [8] [0x2c303030 : 741355568] > >> [9] [0x472c3532 : 1194079538] > >> [10] [0x2c646f6f : 744779631] > > > > It looks like this block contains normal characters instead of fields of > > regular inode structure, so I think root inode's block or > > nat_entry.blkaddr may be corrupted. > > > > Let me think about the way to rebuild root inode. > > > > Thanks, > > > >> Invalid (i)node block > >> > >> Info: checkpoint state = 4 : compacted_summary sudden-power-off > >> > >> Done. > >> > >> On Friday 24 August 2018 13:08:30 Chao Yu wrote: > >>> Hi Luke, > >>> > >>> I think the problem here is that we don't even start to traverse and > >>> check all directories and files due to we encounter root inode sanity > >>> check failure. > >>> > >>> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30] > >>> footer.ino[0x30333238] > >>> > >>> Could you dump root node info with below command: > >>> > >>> dump.f2fs -i 3 -d 1 <your_device_path> > >>> > >>> Thanks, > >>> > >>> On 2018/8/24 12:31, Luke Dashjr wrote: > >>>> One of my phones recently decided to corrupt its /data partition. I > >>>> managed to copy it to my PC before wiping the phone completely, but > >>>> efforts to mount or otherwise recover data from it have proven futile. > >>>> > >>>> Mounting fails with dmesg showing: > >>>> > >>>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3, > >>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016 > >>>>424 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to > >>>> read root inode > >>>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3, > >>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016 > >>>>424 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to > >>>> read root inode > >>>> > >>>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found: > >>>> > >>>> (NOTE: fsck output at > >>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0 > >>>> 0x0000555555559911 in memcpy (__len=18446744072369571950, > >>>> __src=0x5555557d644c, __dest=0x7fffffffd2d0) > >>>> at /usr/include/bits/string_fortified.h:34 > >>>> #1 convert_encrypted_name ( > >>>> name=name@entry=0x5555557d644c > >>>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4 > >>>> [\227\266\221R1\332\331! > >>>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\35 > >>>>2\3 52\032i\222]\326Ӌ\027^\030\226\005&\006| > >>>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\ > >>>>006 g\034u]\003\002)\005! > >>>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264 > >>>>-di > >>>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\20 > >>>>2\21 4\b! \361\241\213\370\336 > >>>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352 > >>>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666, > >>>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", > >>>> enc_name=<optimized out>) > >>>> at fsck.c:1132 > >>>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 > >>>> <gfsck>, node=0x5555557d63f0, name=1) at mount.c:183 > >>>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>, > >>>> node_block=<optimized out>, verbose=<optimized out>) > >>>> at mount.c:277 > >>>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 > >>>> <gfsck>, nid=nid@entry=2875, force=force@entry=1) > >>>> at dump.c:520 > >>>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at > >>>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 > >>>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized > >>>> out>) at main.c:726 > >>>> > >>>> If I tell it NOT to recover lost+found, it completes, but mounting > >>>> still fails: > >>>> > >>>> (NOTE: fsck output > >>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) > >>>> [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint > >>>> [434361.825628] F2FS-fs (loop0): Failed to read root inode > >>>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint > >>>> [434361.840620] F2FS-fs (loop0): Failed to read root inode > >>>> > >>>> Any ideas on how to get at least some data recovered from this? > >>>> (Particularly the encryption key(s) Android stores at > >>>> /data/misc/vold/*.key) > >>>> > >>>> Thanks, > >>>> > >>>> Luke > >>>> > >>>> ---------------------------------------------------------------------- > >>>>--- ----- Check out the vibrant tech community on one of the world's > >>>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >>>> _______________________________________________ > >>>> Linux-f2fs-devel mailing list > >>>> Linux-f2fs-devel@lists.sourceforge.net > >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > >> > >> ------------------------------------------------------------------------ > >>------ Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> Linux-f2fs-devel mailing list > >> Linux-f2fs-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > > ------------------------------------------------------------------------- > >----- Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Linux-f2fs-devel mailing list > > Linux-f2fs-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless 2018-08-28 9:47 ` Luke Dashjr @ 2018-08-28 10:34 ` Chao Yu 0 siblings, 0 replies; 9+ messages in thread From: Chao Yu @ 2018-08-28 10:34 UTC (permalink / raw) To: shengyong (A); +Cc: Luke Dashjr, linux-f2fs-devel Hi Sheng, Could you have a look at this? We need to skip calling sanity_check_nid again in fsck_chk_fs? On 2018/8/28 17:47, Luke Dashjr wrote: > Yes, I did my best to rebase it: > > https://paste.pound-python.org/show/nWshXUd5QSLbj5ZCugPy/ > > Unfortunately, it aborts: > > [ASSERT] (sanity_check_nid: 391) --> nid[0x3] ino is 0 > > #0 sanity_check_nid (sbi=sbi@entry=0x555555782800 <gfsck>, nid=nid@entry=3, > node_blk=node_blk@entry=0x5555557d6fe0, > ftype=ftype@entry=F2FS_FT_DIR, ntype=ntype@entry=TYPE_INODE, > ni=ni@entry=0x7fffffffd660) at fsck.c:392 > #1 0x000055555555d853 in fsck_chk_fs (sbi=<optimized out>, > blk_cnt=0x7fffffffd6ec) at fsck.c:997 > #2 0x000055555555675c in do_fsck (sbi=0x555555782800 <gfsck>) at main.c:565 > #3 main (argc=<optimized out>, argv=<optimized out>) at main.c:725 > > Luke > > > On Tuesday 28 August 2018 09:28:57 Chao Yu wrote: >> Hi Luke, >> >> Do you have tried Sheng Yong's patch? >> >> BTW, before recovering root inode, it needs to backup your entire image. >> >> On 2018/8/24 23:59, Chao Yu wrote: >>> On 2018/8/24 22:38, Luke Dashjr wrote: >>>> Info: Debug level = 1 >>>> Info: Segments per section = 1 >>>> Info: Sections per zone = 1 >>>> Info: sector size = 512 >>>> Info: total sectors = 12597656 (6151 MB) >>>> Info: MKFS version >>>> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) >>>> (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016" >>>> Info: FSCK version >>>> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 >>>> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC >>>> 2018" to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version >>>> 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 >>>> UTC 2018" Info: superblock features = 0 : >>>> Info: superblock encrypt level = 0, salt = >>>> 00000000000000000000000000000000 >>>> >>>> +--------------------------------------------------------+ >>>> >>>> | Super block | >>>> >>>> +--------------------------------------------------------+ >>>> magic [0xf2f52010 : 4076150800] >>>> major_ver [0x 1 : 1] >>>> volum_name [] >>>> minor_ver [0x 2 : 2] >>>> log_sectorsize [0x 9 : 9] >>>> log_sectors_per_block [0x 3 : 3] >>>> log_blocksize [0x c : 12] >>>> log_blocks_per_seg [0x 9 : 9] >>>> segs_per_sec [0x 1 : 1] >>>> secs_per_zone [0x 1 : 1] >>>> checksum_offset [0x 0 : 0] >>>> block_count [0x 13ffe0 : 1310688] >>>> section_count [0x 9e9 : 2537] >>>> segment_count [0x 9fe : 2558] >>>> segment_count_ckpt [0x 2 : 2] >>>> segment_count_sit [0x 2 : 2] >>>> segment_count_nat [0x c : 12] >>>> segment_count_ssa [0x 5 : 5] >>>> segment_count_main [0x 9e9 : 2537] >>>> segment0_blkaddr [0x 200 : 512] >>>> cp_blkaddr [0x 200 : 512] >>>> sit_blkaddr [0x 600 : 1536] >>>> nat_blkaddr [0x a00 : 2560] >>>> ssa_blkaddr [0x 2200 : 8704] >>>> main_blkaddr [0x 2c00 : 11264] >>>> root_ino [0x 3 : 3] >>>> node_ino [0x 1 : 1] >>>> meta_ino [0x 2 : 2] >>>> cp_payload [0x 0 : 0] >>>> version Linux version 4.17.11-gentoo >>>> (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP >>>> PREEMPT Sun Jul 29 04:07:16 UTC 2018 >>>> Info: total FS sectors = 10485504 (5119 MB) >>>> Info: CKPT version = 1f339f >>>> >>>> +--------------------------------------------------------+ >>>> >>>> | Checkpoint | >>>> >>>> +--------------------------------------------------------+ >>>> checkpoint_ver [0x 1f339f : 2044831] >>>> user_block_count [0x 127a00 : 1210880] >>>> valid_block_count [0x bfc23 : 785443] >>>> rsvd_segment_count [0x 30 : 48] >>>> overprov_segment_count [0x ac : 172] >>>> free_segment_count [0x 30 : 48] >>>> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0] >>>> alloc_type[CURSEG_WARM_NODE] [0x 0 : 0] >>>> alloc_type[CURSEG_COLD_NODE] [0x 0 : 0] >>>> cur_node_segno[0] [0x 4bc : 1212] >>>> cur_node_segno[1] [0x 552 : 1362] >>>> cur_node_segno[2] [0x 912 : 2322] >>>> cur_node_blkoff[0] [0x bc : 188] >>>> cur_node_blkoff[1] [0x 79 : 121] >>>> cur_node_blkoff[2] [0x 169 : 361] >>>> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0] >>>> alloc_type[CURSEG_WARM_DATA] [0x 0 : 0] >>>> alloc_type[CURSEG_COLD_DATA] [0x 0 : 0] >>>> cur_data_segno[0] [0x 576 : 1398] >>>> cur_data_segno[1] [0x 665 : 1637] >>>> cur_data_segno[2] [0x 66e : 1646] >>>> cur_data_blkoff[0] [0x 0 : 0] >>>> cur_data_blkoff[1] [0x 0 : 0] >>>> cur_data_blkoff[2] [0x 0 : 0] >>>> ckpt_flags [0x 4 : 4] >>>> cp_pack_total_block_count [0x 3 : 3] >>>> cp_pack_start_sum [0x 1 : 1] >>>> valid_node_count [0x 5e52 : 24146] >>>> valid_inode_count [0x 5c97 : 23703] >>>> next_free_nid [0x 35c78 : 220280] >>>> sit_ver_bitmap_bytesize [0x 40 : 64] >>>> nat_ver_bitmap_bytesize [0x 180 : 384] >>>> checksum_offset [0x ffc : 4092] >>>> elapsed_time [0x183e8f20f43 : 1666060521283] >>>> sit_nat_version_bitmap[0] [0x 9 : 9] >>>> >>>> >>>> [dump_node: 500] Node ID [0x3] >>>> [dump_node: 501] nat_entry.block_addr [0x11fa0e] >>>> [dump_node: 502] nat_entry.version [0x0] >>>> [dump_node: 503] nat_entry.ino [0x3] >>>> [dump_node: 510] node_blk.footer.ino [0x30333238] >>>> [dump_node: 511] node_blk.footer.nid [0x30352c30] >>>> [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or >>>> indirect node. >>>> [0] [0x3933332c : 959656748] >>>> [1] [0x3633322c : 909324844] >>>> [2] [0x30303030 : 808464432] >>>> [3] [0x3134312c : 825504044] >>>> [4] [0x2c303639 : 741357113] >>>> [5] [0x3636322d : 909521453] >>>> [6] [0x2c363331 : 741749553] >>>> [7] [0x31303432 : 825242674] >>>> [8] [0x2c303030 : 741355568] >>>> [9] [0x472c3532 : 1194079538] >>>> [10] [0x2c646f6f : 744779631] >>> >>> It looks like this block contains normal characters instead of fields of >>> regular inode structure, so I think root inode's block or >>> nat_entry.blkaddr may be corrupted. >>> >>> Let me think about the way to rebuild root inode. >>> >>> Thanks, >>> >>>> Invalid (i)node block >>>> >>>> Info: checkpoint state = 4 : compacted_summary sudden-power-off >>>> >>>> Done. >>>> >>>> On Friday 24 August 2018 13:08:30 Chao Yu wrote: >>>>> Hi Luke, >>>>> >>>>> I think the problem here is that we don't even start to traverse and >>>>> check all directories and files due to we encounter root inode sanity >>>>> check failure. >>>>> >>>>> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30] >>>>> footer.ino[0x30333238] >>>>> >>>>> Could you dump root node info with below command: >>>>> >>>>> dump.f2fs -i 3 -d 1 <your_device_path> >>>>> >>>>> Thanks, >>>>> >>>>> On 2018/8/24 12:31, Luke Dashjr wrote: >>>>>> One of my phones recently decided to corrupt its /data partition. I >>>>>> managed to copy it to my PC before wiping the phone completely, but >>>>>> efforts to mount or otherwise recover data from it have proven futile. >>>>>> >>>>>> Mounting fails with dmesg showing: >>>>>> >>>>>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3, >>>>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016 >>>>>> 424 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to >>>>>> read root inode >>>>>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3, >>>>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016 >>>>>> 424 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to >>>>>> read root inode >>>>>> >>>>>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found: >>>>>> >>>>>> (NOTE: fsck output at >>>>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0 >>>>>> 0x0000555555559911 in memcpy (__len=18446744072369571950, >>>>>> __src=0x5555557d644c, __dest=0x7fffffffd2d0) >>>>>> at /usr/include/bits/string_fortified.h:34 >>>>>> #1 convert_encrypted_name ( >>>>>> name=name@entry=0x5555557d644c >>>>>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4 >>>>>> [\227\266\221R1\332\331! >>>>>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\35 >>>>>> 2\3 52\032i\222]\326Ӌ\027^\030\226\005&\006| >>>>>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\ >>>>>> 006 g\034u]\003\002)\005! >>>>>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264 >>>>>> -di >>>>>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\20 >>>>>> 2\21 4\b! \361\241\213\370\336 >>>>>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352 >>>>>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666, >>>>>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", >>>>>> enc_name=<optimized out>) >>>>>> at fsck.c:1132 >>>>>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 >>>>>> <gfsck>, node=0x5555557d63f0, name=1) at mount.c:183 >>>>>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>, >>>>>> node_block=<optimized out>, verbose=<optimized out>) >>>>>> at mount.c:277 >>>>>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 >>>>>> <gfsck>, nid=nid@entry=2875, force=force@entry=1) >>>>>> at dump.c:520 >>>>>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at >>>>>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 >>>>>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized >>>>>> out>) at main.c:726 >>>>>> >>>>>> If I tell it NOT to recover lost+found, it completes, but mounting >>>>>> still fails: >>>>>> >>>>>> (NOTE: fsck output >>>>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) >>>>>> [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint >>>>>> [434361.825628] F2FS-fs (loop0): Failed to read root inode >>>>>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint >>>>>> [434361.840620] F2FS-fs (loop0): Failed to read root inode >>>>>> >>>>>> Any ideas on how to get at least some data recovered from this? >>>>>> (Particularly the encryption key(s) Android stores at >>>>>> /data/misc/vold/*.key) >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Luke >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> --- ----- Check out the vibrant tech community on one of the world's >>>>>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>>> _______________________________________________ >>>>>> Linux-f2fs-devel mailing list >>>>>> Linux-f2fs-devel@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>>> >>>> ------------------------------------------------------------------------ >>>> ------ Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Linux-f2fs-devel mailing list >>>> Linux-f2fs-devel@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>> >>> ------------------------------------------------------------------------- >>> ----- Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Linux-f2fs-devel mailing list >>> Linux-f2fs-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > > . > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless 2018-08-24 4:31 Corrupt F2FS partition - fsck is useless Luke Dashjr 2018-08-24 13:08 ` Chao Yu @ 2018-08-28 7:37 ` Jaegeuk Kim 2018-08-28 7:49 ` Luke Dashjr 1 sibling, 1 reply; 9+ messages in thread From: Jaegeuk Kim @ 2018-08-28 7:37 UTC (permalink / raw) To: Luke Dashjr; +Cc: linux-f2fs-devel On 08/24, Luke Dashjr wrote: > One of my phones recently decided to corrupt its /data partition. I managed to > copy it to my PC before wiping the phone completely, but efforts to mount or > otherwise recover data from it have proven futile. > > Mounting fails with dmesg showing: > > [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3, > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690] > [433918.995566] F2FS-fs (loop0): Failed to read root inode > [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3, > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690] > [433919.003598] F2FS-fs (loop0): Failed to read root inode > > f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found: > > (NOTE: fsck output at https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) > #0 0x0000555555559911 in memcpy (__len=18446744072369571950, > __src=0x5555557d644c, __dest=0x7fffffffd2d0) > at /usr/include/bits/string_fortified.h:34 > #1 convert_encrypted_name ( > name=name@entry=0x5555557d644c "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4 > [\227\266\221R1\332\331! > \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\352\032i\222]\326Ӌ\027^\030\226\005&\006| > \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006g\034u]\003\002)\005! > \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\214\b! > \361\241\213\370\336 > {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352 > 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666, > new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", enc_name=<optimized > out>) > at fsck.c:1132 > #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>, > node=0x5555557d63f0, name=1) at mount.c:183 > #3 0x000055555556424f in print_node_info (sbi=<optimized out>, > node_block=<optimized out>, verbose=<optimized out>) > at mount.c:277 > #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 <gfsck>, > nid=nid@entry=2875, force=force@entry=1) > at dump.c:520 > #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at fsck.c:2568 > #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 <gfsck>) at main.c:569 > #7 main (argc=<optimized out>, argv=<optimized out>) at main.c:726 > > If I tell it NOT to recover lost+found, it completes, but mounting still > fails: > > (NOTE: fsck output https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) > [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint > [434361.825628] F2FS-fs (loop0): Failed to read root inode > [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint > [434361.840620] F2FS-fs (loop0): Failed to read root inode > > Any ideas on how to get at least some data recovered from this? > (Particularly the encryption key(s) Android stores at /data/misc/vold/*.key) Are you using dm-crypt under f2fs? Did you decrypt the raw image? v3.10 is too much old, and I quit to backport recent patches as well. Is there a chance to upgrade the kernel? > > Thanks, > > Luke > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless 2018-08-28 7:37 ` Jaegeuk Kim @ 2018-08-28 7:49 ` Luke Dashjr 0 siblings, 0 replies; 9+ messages in thread From: Luke Dashjr @ 2018-08-28 7:49 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel On Tuesday 28 August 2018 07:37:35 Jaegeuk Kim wrote: > Are you using dm-crypt under f2fs? No. > v3.10 is too much old, and I quit to backport recent patches as well. > Is there a chance to upgrade the kernel? The 3.10 was the Android/LineageOS phone that couldn't even boot. I'm doing all the data recovery attempts on 4.17.11. Thanks, Luke ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-08-28 10:34 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-08-24 4:31 Corrupt F2FS partition - fsck is useless Luke Dashjr 2018-08-24 13:08 ` Chao Yu 2018-08-24 14:38 ` Luke Dashjr 2018-08-24 15:59 ` Chao Yu 2018-08-28 9:28 ` Chao Yu 2018-08-28 9:47 ` Luke Dashjr 2018-08-28 10:34 ` Chao Yu 2018-08-28 7:37 ` Jaegeuk Kim 2018-08-28 7:49 ` Luke Dashjr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).