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數據不正常了，被異常的數據覆蓋了，如果不能分析出被覆蓋的數據屬於哪個應用的，那麼也無法判斷。
以上僅僅爲懷疑的方向，且無法直接的證據能夠定位到問題，歡迎補充~