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

Reply via email to