Re: [f2fs-dev] Corrupt F2FS partition - fsck is useless

2018-08-28 Thread Luke Dashjr
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=0x55782800 , nid=nid@entry=3, 
node_blk=node_blk@entry=0x557d6fe0, 
ftype=ftype@entry=F2FS_FT_DIR, ntype=ntype@entry=TYPE_INODE, 
ni=ni@entry=0x7fffd660) at fsck.c:392
#1  0xd853 in fsck_chk_fs (sbi=, 
blk_cnt=0x7fffd6ec) at fsck.c:997
#2  0x675c in do_fsck (sbi=0x55782800 ) at main.c:565
#3  main (argc=, argv=) 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 =
> >> 
> >>
> >> ++
> >>
> >> | 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 [0x2200 : 8704]
> >> main_blkaddr[0x2c00 : 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   

Re: [f2fs-dev] Corrupt F2FS partition - fsck is useless

2018-08-28 Thread Luke Dashjr
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
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


Re: [f2fs-dev] Corrupt F2FS partition - fsck is useless

2018-08-24 Thread Luke Dashjr
x 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] [0x392c : 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 
>
> 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 
> > 0x9911 in memcpy (__len=18446744072369571950,
> > __src=0x557d644c, __dest=0x7fffd2d0)
> > at /usr/include/bits/string_fortified.h:34
> > #1  convert_encrypted_name (
> > name=name@entry=0x557d644c
> > "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=0x7fffd2d0 "3\036\021\004\035=]\035",
> > enc_name=)
> > at fsck.c:1132
> > #2  0x555639d9 in print_inode_info (sbi=0x557817e0 ,
> > node=0x557d63f0, name=1) at mount.c:183
> > #3  0x5556424f in print_node_info (sbi=,
> > node_block=, verbose=)
> > at mount.c:277
> > #4  0x555620c2 in dump_node (sbi=sbi@entry=0x557817e0
> > , nid=nid@entry=2875, force=force@entry=1)
> > at dump.c:520
> > #5  0xf58f in fsck_verify (sbi=) at
> > fsck.c:2568 #6  0x679b in do_fsck (sbi=0x557817e0
> > ) at main.c:569 #7  main (argc=, argv= > 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?

[f2fs-dev] Corrupt F2FS partition - fsck is useless

2018-08-23 Thread Luke Dashjr
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  0x9911 in memcpy (__len=18446744072369571950, 
__src=0x557d644c, __dest=0x7fffd2d0)
at /usr/include/bits/string_fortified.h:34
#1  convert_encrypted_name (
name=name@entry=0x557d644c 
"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=0x7fffd2d0 "3\036\021\004\035=]\035", enc_name=)
at fsck.c:1132
#2  0x555639d9 in print_inode_info (sbi=0x557817e0 , 
node=0x557d63f0, name=1) at mount.c:183
#3  0x5556424f in print_node_info (sbi=, 
node_block=, verbose=)
at mount.c:277
#4  0x555620c2 in dump_node (sbi=sbi@entry=0x557817e0 , 
nid=nid@entry=2875, force=force@entry=1)
at dump.c:520
#5  0xf58f in fsck_verify (sbi=) at fsck.c:2568
#6  0x679b in do_fsck (sbi=0x557817e0 ) at main.c:569
#7  main (argc=, argv=) 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