Bug#1015295: linux-image-5.10.0-16-arm64: Unbootable system due to F2FS sanity_check_inode errors after upgrading kernel

["Lukasz K." <movrax@cryptolab.net>]

I have finally found some time to look into the matter.

> The referenced commit seems to have actually landed in 5.10.127
> upstream. So this probably needs more investigation. Can you for your
> device test upstrema kernels and test if 5.10.136 upstream fixes the
> issue? Can you bisect the breaking commit upstream between the two
> versions working in Debian and breaking?

I saw in linux-image-5.10.0-16-arm64 (5.10.127-1) changelog:
  - f2fs: fix to do sanity check for inline inode

According to user ghtm2 from kernel bugzilla, who used git bisect, this
was the one causing the issue (comment #5):
https://bugzilla.kernel.org/show_bug.cgi?id=216162#c5
"According to git bisect that I just ran,
198fd9faa271dd54dca6fc8eb6873f42dfd3b4d8 is the first bad commit.
"f2fs: fix to do sanity check for inline inode" [...]"

But 5.10.127-1 also includes another commit, which I did not notice:
  - f2fs: attach inline_data after setting compression

This one should fix the issue:
https://github.com/torvalds/linux/commit/4cde00d50707c2ef6647b9b96b2cb40b6eb24397

But for some reason in my case it did not.

Interestingly, the same user from bugzilla also reported that this
solution did not work in his case (comment #4):
https://bugzilla.kernel.org/show_bug.cgi?id=216162#c4
"[...] The mentioned patch is in the stable tree as of 5.18.8 and
doesn't fix this problem either."

>From the same bugzilla thread F2FS developers suggested using
f2fs-tools from "dev" branch:
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git/log/?h=dev

It did work for ghtm2, so I decided to give it a try, and it did work
in my case as well.

I saw a lot of messages of this kind:
[FIX] (fsck_chk_inode_blk: 728)  --> [0x505] i_flags=0x4 -> 0x0
[ASSERT] (fsck_chk_inode_blk:1182)  --> ino: 0x505 chksum:0xe7b707a8, but calculated one is: 0x3f6daf58
[FIX] (fsck_chk_inode_blk:1188)  --> ino: 0x505 recover, i_inode_checksum= 0xe7b707a8 -> 0x3f6daf58

But eventually it finished, and I was able to mount F2FS partitions
without errors on current Bullseye kernel (linux-image-5.10.0-17-arm64
[5.10.136-1]), and the system booted properly after rebooting.

I can only assume that under certain circumstances in-kernel run-time
solution is not able to fix the problem, and this has to be done
offline with fsck, but f2fs-tools has to be from "dev" branch (even
latest 1.15.0, not available in Debian [1.14.0], will not fix it).