Meta-mender: issue flashing a Mender image with bmaptool

General Discussions
1

TL;DR: Removing metadata_csum from ext4 features produces a uefiimg disk image and associated bmap that cannot be flashed reliably with bmaptool. This can be fixed by restoring that feature.

Long version:
In meta-mender, the following patch removes metadata_csum from the available ext4 features: “meta-mender/meta-mender-core/recipes-devtools/e2fsprogs/patches/0001-Do-not-use-metadata_csum-feature-on-ext4-by-default.patch”

With this patch in place, you may produce a .uefiimg and .uefiimg.bmap pair (I did not test other formats, such as sdimg) that appears functional, but has a minor issue when flashed with bmaptool on a device. Indeed, the flash is successful and your OS boots, and everything appears fine. However, if you fsck your rootfs (or the data partition), a TON of inode errors will be reported by fsck. You may fix all of these and they won’t come back: these errors are due to bmaptool apparently making some assumptions about the data that is written (or not written, most likely).

Here are some examples of errors found by fsck (this is just a sample, there are thousands of these):
Inode 141 seems to contain garbage. Clear? yes
Inode 142 seems to contain garbage. Clear? yes
Inode 143 seems to contain garbage. Clear? yes
Inode 144 seems to contain garbage. Clear? yes
Inode 145 seems to have inline data but extent flag is set.
Fix? yes
Inode 145 has INLINE_DATA_FL flag on filesystem without inline data support.
Clear? yes
Inode 146 is in use, but has dtime set. Fix?

Note that flashing the .uefiimg alone to a device (using dd, or anything really) works fine: no errors are reported on any partition.

First possible fix:
I noticed that if I fill the target device with zeroes before flashing with bmaptool, it works fine: the filesystem integrity is perfect.

Second possible fix:
Remove the patch. The patch pointed out above was done (changeset c45085187ec79dc2a2dcbb2a2566fe509f0194f0 in meta-mender) at a time when tools such as fsck.ext4 and tune2fs did not handle the metadata_csum feature. Currently (on branch zeus at least), they do. On my project, I removed this patch. Everything works fine and the filesystem integrity is perfect.

I propose the second fix for the zeus branch of meta-mender. Should I make a PR?

1 Like
2

Thanks for the analysis. That does seem like the right fix. @kacf will be the ultimate decider on this.
Drew

3

Thanks for checking this, the second option sounds good, the original fix was more of a temporary measure. Please make a PR, but make sure you submit to the master branch though. We always do that first and then patches are cherry-picked monthly into the other branches.

1 Like
4

There you go: https://github.com/mendersoftware/meta-mender/pull/1076

5

Just to give a final update in case anyone is following this thread: 2 issues were discovered when metadata_csum is enabled (snapshots and binary delta updates, see PR for details), which I cannot resolve, so the PR was closed.

For my project, I will continue manually patching meta-mender at build time to preserve bmaptool functionality, as I do not use the affected features.

Thank you, @kacf!