Ubuntu Image

Using host e2fsprogs brings compatibility issues

Bug #2028564 reported by Nicolas Dechesne
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Image
In Progress
Medium
Paul Mars

Bug Description

I am using ubuntu-image to build arm64 image for Tegra, the target images are for 22.04.

I noticed that when booting my images cloud-init fails to resize the filesystem (I am using classic / pre-installed images).

After investigating the failure, I found out that resize2fs fails because of

/dev/sda2 has unsupported feature(s): FEATURE_C12
e2fsck: Get a newer version of e2fsck!

I remember that some of my previous images used to work, so looking further I realized that the images which don't work are built on a lunar host, and the images which work on a jammy host.

The filesystem generated with lunar have the 'orphan_file' feature enable. However the images is a jammy image which has an older version of e2fsprogs/e2fsck which is why we get the error message above.

See the output of dumpe2fs for the same image, generated either with Jammy or Lunar:

Jammy: Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

Lunar: Filesystem features: has_journal ext_attr resize_inode dir_index orphan_file filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

I think we want to make sure that ubuntu-image generates the filesystem with flags/features which are compatible with the target release of Ubuntu.

Related branches

~upils/ubuntu/+source/e2fsprogs:disable-orphan-file-feature
Nick Rosbrook (community): Needs Fixing
Bryce Harrington (community): Needs Information
git-ubuntu import: Pending requested
Diff: 42 lines (+12/-3)
2 files modified
debian/changelog (+7/-0)
debian/patches/default-no-metadata_csum_seed.patch (+5/-3)
Revision history for this message
Paul Mars (upils) wrote :

We previously encountered this kind of problem when the metadata_csum feature was added in e2fsprogs.

I think we could disable the orphan_file feature the same way, as long as we use the "-0 ^orphan_file" syntax (and not using a "-") to make sure we prevent a regression on this bug https://bugs.launchpad.net/snappy/+bug/1878374.

I will draft a PR to snapd (because now snapd is providing the package to deal with filesystems generation).

Paul Mars (upils)
Changed in ubuntu-image:
assignee: nobody → Paul Mars (upils)
importance: Undecided → Medium
tags: added: foundations-todo
Changed in ubuntu-image:
status: New → In Progress
Revision history for this message
Paul Mars (upils) wrote :

I dug a bit more and found we already had this issue when upgrading e2fsprogs to 1.47.0 in mantic [1]

At this time xnox fixed the issue by disabling this feature in the default conf of e2fsprogs and mentioned doing a SRU in jammy. I think that may be the best solution, instead of trying to handle this exception in snapd.

[1] https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/2025339

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

To elevate the issue to a higher (probably too high) level, this is not only a problem for ubuntu-image, it is a problem for curtin/MAAS as well (and maybe even subiquity one day). It would be nice if we didn't have to encode "which features do we have to disable when making an ext4 filesystem for focal on a jammy host" (etc etc) in several places. We might be able to do this by bundlling the mke2fs.conf files for each version somewhere and pointing to them with MKE2FS_CONFIG?

Revision history for this message
Paul Mars (upils) wrote :

I am not sure ubuntu-image (or here in fact snapd) should be responsible to handle this kind of specificities for each series, especially since they can become irrelevant when a package is SRUed.

For this reason I abandoned my PR on snapd to disable the orphan_file feature and I think doing a SRU of e2fsprogs 1.47.0 in lunar and jammy may be the best solution.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.