Can't find ext4 filesystem（EXT4-fs:Bad magic number in super-block)
针对目前市面上主流的android系统的嵌入式设备，都是使用的emmc的flash存储，相应的使用的是ext4的文件系统，当ext4的system分区无法挂载的时候，我们改如何分析呢？何种操作导致的ext4分区无法挂载呢？
我们出问题的设备的启动log如下：
[ [email protected]] fs_mgr: Warning: unknown flag format [ [email protected]] fs_mgr: Warning: unknown flag format [ [email protected]] fs_mgr: Warning: unknown flag format [ [email protected]] EXT4-fs (mmcblk0p14): VFS: Can't find ext4 filesystem [ [email protected]] fs_mgr: Failed to mount an un-encryptable or wiped partition on/dev/block/system at /system options: (null) error: Invalid argument [ [email protected]] fs_mgr: MAKE_EXT4:/dev/block/data and return value is :255. [ [email protected]] fs_mgr: mount:/data ok and errno is :17. [ [email protected]] fs_mgr: MAKE_EXT4:/dev/block/cache and return value is :255. [ [email protected]] fs_mgr: mount:/cache ok and errno is :17. [ [email protected]] fs_mgr: mount:/impdata ok and errno is :17. [ [email protected]] fs_mgr: MAKE_EXT4:/dev/block/userdata and return value is :255. [ [email protected]] fs_mgr: mount:/userdata ok and errno is :17. [ [email protected]] fs_mgr: mount:/tclconfig ok and errno is :17. [ [email protected]] fs_mgr: mount:/tvos ok and errno is :17. [ [email protected]] init: fs_mgr_mount_all returned an error [ [email protected]] init: fs_mgr_mount_all returned unexpected error 255
EXT4-fs (mmcblk0p14): VFS: Can't find ext4 filesystem
分区步骤如下：
（1）目前正常的android系统无法启动，我们可以进入recovery下，把system分区数据dump出来
busybox dd if=/dev/block/system of=/udisk/system_dump.img
（2）采用e2fsck工具，对dump的system.img校验
e2fsck -f system.dump
e2fsck 1.43.3 (04-Sep-2016)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
Backing up journal inode block information.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (0, counted=23384).
Fix<y>? y
yes
Free inodes count wrong (0, counted=87694).
Fix<y>? yes
system.dump: ***** FILE SYSTEM WAS MODIFIED *****
system.dump: 2418/90112 files (0.0% non-contiguous), 337064/360448 blocks
从使用e2fsck的修复状态来看，system分区的super-block损坏了
（3）system分区的super-block的magic number不对了，但是Android系统的system分区挂载的ro只读的，也就是不可能被写成其他的数据，是不存在super-block损坏的，那么就考虑非正常的情况了。
3.1 android system被root了，那么就可能变成rw被写坏了
3.2 android recovery ota升级更新system分区掉电了，把system分区写坏了
3.3 emmc本身的问题，掉码了，导致super-block的关键数据丢了
3.4 android system运行中，冲内存了，覆盖了system分区的super-block数据。
（4）具体分析场景
是否root，我们需要查看system分区的最后一次write时间，使用winhex工具分析system分区的super-block
貌似是非正常数据，我们计算下，0x84F1EC4F = 2230447183秒 = 25815天 = 70.72年。1970.1.1 + 70 = 2040年，显然这个
时间为无效数据。所以，我们无法通过，system分区的最有一次write时间，判断系统是否root。
我们把修复后的system_dump.img映射成磁盘文件，对比system_dump里面的数据，是否跟正常的system分区里面的数据对比
对比数据分析，system分区的数据都在，目前可以初步认定系统没有被root。
是否OTA掉电，我们需要分析uboot，boot的编译时间，system分区的时间，目前我们查看，uboot boot recovery system分区的时间，都是20180918，且如果在更新system分区时，把system分区的super-block写坏就掉电，那么升级还未完成，升级包应该还在data分区，我们检查data分区，没有update.zip升级包存在，也是就不存在ota写坏system分区的可能。
是否为emmc flash本身掉码导致，针对仅仅一个现象，我们时无法判断，我们分析多块坏板，发现都是system分区的super block无法挂载，且仅仅只有super block损坏，后面的data block都是正常，也就是损坏的block仅仅为super block，不具有随机性，则我们不能判断为emmc 本身的问题，掉码时随机性的。
是否为应用冲内存，由于原本的的system分区的super block数据不正常了，被异常的数据覆盖了，如果不能分析出被覆盖的数据属于哪个应用的，那么也无法判断。
以上仅仅为怀疑的方向，且无法直接的证据能够定位到问题，欢迎补充~