According to the manual page of e2fsck (e2fsck(8) - Linux manual page), e2fsck will return 1 if there’e issues found in the filesystem but they have fixed.
On some firmwares Android will never cleanly umount the data which results in it being dirty until a proper e2fsck with fix option enabled (either via -y/-p or with user interaction) was run (which is automatically done during the Android bootup). This results in ceemmc early dying without actual installation while the partition table is already changed, and since resize2fs was not run yet, the data partition is corrupted (unmatched fs size and inode counts) and Android can’t be properly booted until the data partition was properly resized manually by the user.
Even if you re-run ceemmc right after it bailed out due to e2fsck returing 1, it will consider the fs-resize work is already done since the partition layout is already new, the CoreELEC installation can be done in this second attempt, if users fs-resize by themselvies before the attempt, since fs-resize on data partition was not properly done by ceemmc. And this manual fix must be done before actual reboot whether ceemmc would be tried for second attempt or not before reboot (after reboot, the underlying block’s size is already shrunk and fs on data partition is permanantly corrupted and fs-resize can’t be run properly any more)
Thank you for this hint, the return value of the tool is a bit mask and so we need to add a clever handling about it. We will check how this can be fixed.
Any return value other than 0b00000001 and 0b00000000 always mean failed operation or uncorrected error, or incomplete fix. I think checking return value against integer 0 and 1 is enough
0 - No errors
1 - File system errors corrected
2 - File system errors corrected, system should
4 - File system errors left uncorrected
8 - Operational error
16 - Usage or syntax error
32 - E2fsck canceled by user request
128 - Shared library error
So the return value must be masked by 0b00000011 and by bit n’1 a reboot, so exit is needed as well.
But it’s not a error. All other bits above n’2 do indicate a error and should lead to exit ceemmc.
The ‘File system errors corrected, system should
be rebooted’ one will only be raised if the fs being checked is mounted, which is usually the case for standard Linux distros where non-umountable fs falls to read-only to accept a fsck instead of being umounted, thus keeping services running instead of breaking them. I thought ceemmc would umount all related partitions first?
By ‘incomplete fix’ I’ve covered the case of reboot-needed fix, but that shouldn’t be possible to happen unless ceemmc would happily modify the emmc being used by other process, which is unlikely