I have a 128gb micro sd formatted as ext4 10gb for app2sd 2nd ext4 partition ( p2 ) on my Android 6 phone . All my apps ( 80%) stay on that ext4 partition . Now app2sd cant load this partition - "unable to mount ....kgrinvalid file"
Also the 119 gb main fat ( exFat ) partition ( p1) used to hold my data is mounted as RO. I am rooted on a Sony experia Z3
A brief background :
Was shooting a movie on my phone and it froze restarted twice . After that no luck mounting the ext4 partition.
Questions :
-- How can I get an fsck done on the ext4 file system and let the allocation table know there are bad blocks
-- Is there some mechanism inbuilt in the card that detects bad blocks and corruption and will put the card in RO mode for 1 partition and other partition ext4 cannot be mounted on phone
-- Some place I read this means the card is on its last legs and after some write cycles it becomes RO. Some tech support suggested this happened. I am not prepared to believe . It's only 4 months old bought from Amazon and I CAN write to it ( as will confirm ahead in the rest of the story )
-- I have ADB driver and get to # prompt on adb. I can possibly mount p1 as RW . I can confirm on adb that P2 is seen but it will not mount it
-- How can I get app2sd to mount this and be back in biz.
What I did
on live linux CD
-- I am able to mount both p1 and p2 as RW ( after explicit command ) and only as Su. Normal user - its denied RO. SO on live
ubuntu I CAN RW to both
-- Backed up P2 and then tried to DEL and format P2 ( gparted + fdisk manually ) - NO LUCK. Both give message its successful but after refresh they will show the
SAME old partitions P1 and P2. Tried same on Window 7 - paragon partition manager - gives message it's successful but after refresh they will show old configuration P1 and P2.
---Fsck
it@it:~$ sudo fsck.ext4 -v /dev/sdc2
e2fsck 1.43.4 (31-Jan-2017)
app2sd: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? yes
fsck.ext4: unable to set superblock flags on app2sd
app2sd: ********** WARNING: Filesystem still has errors **********
-running the backup superblock fix does not help
it@it:~$ sudo mke2fs -n /dev/sdc2
mke2fs 1.43.4 (31-Jan-2017)
/dev/sdc2 contains a ext4 file system labelled 'app2sd'
last mounted on /data/sdext2 on Sun Jan 7 07:21:35 2018
Proceed anyway? (y,N) y
Creating filesystem with 2604538 4k blocks and 651520 inodes
Filesystem UUID: 53138787-e743-4160-9041-ac9613d44db8
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
I tried various superblocks - NO LUCK .
I used these guides - NO LUCK
1) Superblock restore from backup and
2 ) fsck.ext4 unable to set superblock flags after a bad unmount
it@it:~$ sudo e2fsck -b 1605632 -B 4096 /dev/sdc2
e2fsck 1.43.4 (31-Jan-2017)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
app2sd: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
e2fsck: unable to set superblock flags on app2sd
app2sd: ***** FILE SYSTEM WAS MODIFIED *****
app2sd: ********** WARNING: Filesystem still has errors **********
and I akso tried this with B=4096 which testdisk confirmed w:
mke2fs -S
-S Write superblock and group descriptors only. This is useful if all
of the superblock and backup superblocks are corrupted, and a last-
ditch recovery method is desired. It causes mke2fs to reinitialize
the superblock and group descriptors, while not touching the inode
table and the block and inode bitmaps. The e2fsck program should be
run immediately after this option is used, and there is no guarantee
that any data will be salvageable. It is critical to specify the
correct filesystem blocksize when using this option,
Here's some more stuff
Testdisk log
Partition table type (auto): Intel
Disk /dev/sdb - 127 GB / 119 GiB - Generic- SD/MMC
Partition table type: Intel
Interface Advanced
Geometry from i386 MBR: head=255 sector=63
test_FAT()
1 P FAT32 LBA 0 32 33 14247 69 30 228880384
sector_size 512
cluster_size 64
reserved 126
fats 2
dir_entries 0
sectors 0
media F8
fat_length 0
secs_track 16
heads 4
hidden 2048
total_sect 228880384
check_part_i386 failed for partition type 0C
get_geometry_from_list_part_aux head=255 nbr=2
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=255 nbr=2
1 P FAT32 LBA 0 32 33 14247 69 30 228880384
2 * Linux 14248 0 1 15544 254 63 20836305 [app2sd]
ext4 blocksize=4096 Large_file Sparse_SB Recover, 10668 MB / 10173 MiB
search_superblock
recover_EXT2: s_block_group_nr=0/79, s_mnt_count=83/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 2 (block=0, blocksize=4096)
block_group_nr 1
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 262144 (block=32768, blocksize=4096)
block_group_nr 3
recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=3/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 786432 (block=98304, blocksize=4096)
block_group_nr 5
recover_EXT2: "e2fsck -b 163840 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=5/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 1310720 (block=163840, blocksize=4096)
block_group_nr 7
recover_EXT2: "e2fsck -b 229376 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=7/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 1835008 (block=229376, blocksize=4096)
block_group_nr 9
recover_EXT2: "e2fsck -b 294912 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=9/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 2359296 (block=294912, blocksize=4096)
block_group_nr 25
recover_EXT2: "e2fsck -b 819200 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=25/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 6553600 (block=819200, blocksize=4096)
block_group_nr 27
recover_EXT2: "e2fsck -b 884736 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=27/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 7077888 (block=884736, blocksize=4096)
block_group_nr 49
recover_EXT2: "e2fsck -b 1605632 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=49/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 12845056 (block=1605632, blocksize=4096)
Linux 14248 0 1 15544 254 62 20836304 [app2sd]
superblock 0, blocksize=4096 [app2sd]
superblock 32768, blocksize=4096 [app2sd]
superblock 98304, blocksize=4096 [app2sd]
superblock 163840, blocksize=4096 [app2sd]
superblock 229376, blocksize=4096 [app2sd]
superblock 294912, blocksize=4096 [app2sd]
superblock 819200, blocksize=4096 [app2sd]
superblock 884736, blocksize=4096 [app2sd]
superblock 1605632, blocksize=4096 [app2sd]
To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device
search_superblock
recover_EXT2: s_block_group_nr=0/79, s_mnt_count=83/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 2 (block=0, blocksize=4096)
block_group_nr 1
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
Sample dump2fs log .
I cant simply attach the entire file on stack.
Partition table type (auto): Intel
Disk /dev/sdb - 127 GB / 119 GiB - Generic- SD/MMC
Partition table type: Intel
Interface Advanced
Geometry from i386 MBR: head=255 sector=63
test_FAT()
1 P FAT32 LBA 0 32 33 14247 69 30 228880384
sector_size 512
cluster_size 64
reserved 126
fats 2
dir_entries 0
sectors 0
media F8
fat_length 0
secs_track 16
heads 4
hidden 2048
total_sect 228880384
check_part_i386 failed for partition type 0C
get_geometry_from_list_part_aux head=255 nbr=2
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=255 nbr=2
1 P FAT32 LBA 0 32 33 14247 69 30 228880384
2 * Linux 14248 0 1 15544 254 63 20836305 [app2sd]
ext4 blocksize=4096 Large_file Sparse_SB Recover, 10668 MB / 10173 MiB
search_superblock
recover_EXT2: s_block_group_nr=0/79, s_mnt_count=83/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 2 (block=0, blocksize=4096)
block_group_nr 1
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 262144 (block=32768, blocksize=4096)
block_group_nr 3
recover_EXT2: "e2fsck -b 98304 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=3/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 786432 (block=98304, blocksize=4096)
block_group_nr 5
recover_EXT2: "e2fsck -b 163840 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=5/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 1310720 (block=163840, blocksize=4096)
block_group_nr 7
recover_EXT2: "e2fsck -b 229376 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=7/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 1835008 (block=229376, blocksize=4096)
block_group_nr 9
recover_EXT2: "e2fsck -b 294912 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=9/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 2359296 (block=294912, blocksize=4096)
block_group_nr 25
recover_EXT2: "e2fsck -b 819200 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=25/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 6553600 (block=819200, blocksize=4096)
block_group_nr 27
recover_EXT2: "e2fsck -b 884736 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=27/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 7077888 (block=884736, blocksize=4096)
block_group_nr 49
recover_EXT2: "e2fsck -b 1605632 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=49/79, s_mnt_count=0/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 12845056 (block=1605632, blocksize=4096)
Linux 14248 0 1 15544 254 62 20836304 [app2sd]
superblock 0, blocksize=4096 [app2sd]
superblock 32768, blocksize=4096 [app2sd]
superblock 98304, blocksize=4096 [app2sd]
superblock 163840, blocksize=4096 [app2sd]
superblock 229376, blocksize=4096 [app2sd]
superblock 294912, blocksize=4096 [app2sd]
superblock 819200, blocksize=4096 [app2sd]
superblock 884736, blocksize=4096 [app2sd]
superblock 1605632, blocksize=4096 [app2sd]
To repair the filesystem using alternate superblock, run
fsck.ext4 -p -b superblock -B blocksize device
search_superblock
recover_EXT2: s_block_group_nr=0/79, s_mnt_count=83/20, s_blocks_per_group=32768, s_inodes_per_group=32320
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2604538
recover_EXT2: part_size 20836304
Ext2 superblock found at sector 2 (block=0, blocksize=4096)
block_group_nr 1
recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
Loop through node list
Another try: grab all backup supernode list from testdisk log and loop through,
This is interesting: when I run esfsck -b <n> -B <N> /devpath I get same standard o/p below . No difference.
+ sudo e2fsck -b 163840 -B 4096 -y /dev/sdc2
e2fsck 1.43.4 (31-Jan-2017)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
app2sd: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
e2fsck: unable to set superblock flags on app2sd
app2sd: ***** FILE SYSTEM WAS MODIFIED *****
app2sd: ********** WARNING: Filesystem still has errors **********
But when I loop through that list loaded from a file ( testdisk.log) - for certain nodes it will give a long o/p like it did some repair - a blink of hope. After that, I did a Linux REISUB shutdown and efsck again . NO LUCK
efsck loop log with repair part.
For those block numbers where it atttempted repair - on command line I tried to set those very backup superblocks - but it does NOT help- back to square one!
+ for i in $(grep e2fsck testdisk.log | uniq | cut -d " " -f 4)
+ sudo e2fsck -b 229376 -B 4096 -y /dev/sdc2
e2fsck 1.43.4 (31-Jan-2017)
Superblock needs_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
app2sd: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Inode 69709 extent tree (at level 1) could be shorter. Fix? yes
Inode 97187 extent tree (at level 1) could be shorter. Fix? yes
Inode 98194 extent tree (at level 1) could be shorter. Fix? yes
Inode 98215 extent tree (at level 1) could be shorter. Fix? yes
Inode 98646 extent tree (at level 1) could be shorter. Fix? yes
Inode 99795 extent tree (at level 1) could be shorter. Fix? yes
Inode 100170 extent tree (at level 1) could be shorter. Fix? yes
Inode 100186 extent tree (at level 1) could be shorter. Fix? yes
Inode 100825 extent tree (at level 1) could be shorter. Fix? yes
Inode 129341 extent tree (at level 1) could be shorter. Fix? yes
Inodes that were part of a corrupted orphan linked list found. Fix? yes
Inode 129343 was part of the orphaned inode list. FIXED.
Inode 129344 was part of the orphaned inode list. FIXED.
Inode 129345 was part of the orphaned inode list. FIXED.
Inode 129371 extent tree (at level 1) could be shorter. Fix? yes
Inode 129414 extent tree (at level 1) could be shorter. Fix? yes
Inode 129418 extent tree (at level 1) could be shorter. Fix? yes
Inode 129437 extent tree (at level 1) could be shorter. Fix? yes
Inode 162145 extent tree (at level 1) could be shorter. Fix? yes
Inode 162147 extent tree (at level 1) could be shorter. Fix? yes
Inode 162151 extent tree (at level 1) could be shorter. Fix? yes
Inode 194325 extent tree (at level 1) could be shorter. Fix? yes
Inode 194408 extent tree (at level 1) could be shorter. Fix? yes
Inode 194464 extent tree (at level 1) could be shorter. Fix? yes
Deleted inode 195640 has zero dtime. Fix? yes
Deleted inode 196040 has zero dtime. Fix? yes
Inode 235473 is in use, but has dtime set. Fix? yes
Inode 235473 has imagic flag set. Clear? yes
Inode 235473 has a extra size (25959) which is invalid
Fix? yes
Inode 235474 has INLINE_DATA_FL flag on filesystem without inline data support.
Clear? yes
Inode 235473, i_size is 7019251879657894515, should be 0. Fix? yes
Inode 235473, i_blocks is 81858393236329, should be 0. Fix? yes
Inode 388501 extent tree (at level 1) could be shorter. Fix? yes
Inode 420685 extent tree (at level 1) could be shorter. Fix? yes
Inode 452971 extent tree (at level 1) could be shorter. Fix? yes
Inode 452978 extent tree (at level 1) could be shorter. Fix? yes
Inode 452981 extent tree (at level 1) could be shorter. Fix? yes
Inode 550513 extent tree (at level 1) could be shorter. Fix? yes
Inode 550523 extent tree (at level 1) could be shorter. Fix? yes
Inode 550524 extent tree (at level 1) could be shorter. Fix? yes
Inode 550525 extent tree (at level 1) could be shorter. Fix? yes
Inode 551843 extent tree (at level 1) could be shorter. Fix? yes
Inode 582085 has an invalid extent node (blk 593131, lblk 0)
Clear? yes
Inode 582085 extent tree (at level 1) could be shorter. Fix? yes
Inode 582085, i_blocks is 40, should be 0. Fix? yes
Inode 582132 extent tree (at level 1) could be shorter. Fix? yes
Pass 1E: Optimizing extent trees
Pass 2: Checking directory structure
Directory inode 97167, block #0, offset 0: directory corrupted
Salvage? yes
Missing '.' in directory inode 97167.
Fix? yes
Setting filetype for entry '.' in ??? (97167) to 2.
Missing '..' in directory inode 97167.
Fix? yes
Setting filetype for entry '..' in ??? (97167) to 2.
Directory inode 97176, block #0, offset 0: directory corrupted
Salvage? yes
Missing '.' in directory inode 97176.
Fix? yes
Setting filetype for entry '.' in ??? (97176) to 2.
Missing '..' in directory inode 97176.
Fix? yes
Setting filetype for entry '..' in ??? (97176) to 2.
Directory inode 97213, block #0, offset 0: directory corrupted
Salvage? yes
Missing '.' in directory inode 97213.
Fix? yes
Setting filetype for entry '.' in ??? (97213) to 2.
Missing '..' in directory inode 97213.
Fix? yes
Setting filetype for entry '..' in ??? (97213) to 2.
Directory inode 161950, block #0, offset 0: directory corrupted
Salvage? yes
Missing '.' in directory inode 161950.
Fix? yes
Setting filetype for entry '.' in ??? (161950) to 2.
Missing '..' in directory inode 161950.
Fix? yes
Setting filetype for entry '..' in ??? (161950) to 2.
Inode 235473 (/data/com.abhivyaktyapps.learn.sanskrit/app_Parse/CommandCache/CachedCommand_00000160cc4ef3d9_00000000_-1326099007) has invalid mode (0166654).
Clear? yes
If it's a total dead horse, then why can I mount and RW on live & Android
backs off
It looks like there is some kind of flag being set here if bad superblock or corrupt blocks are detected -to always load P1 as RO and P2 is not worth loading. How do I clear that flag ? I have # via ADB for my android phone. Why can I mount on android like to do on Live ?
