Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

On Tue, Feb 21, 2023 at 12:17:20PM +0000, Christopher Obbard wrote:
> Control: severity -1 important
> Control: retitle -1 e2fsprogs generates filesystems which cannot be
> mounted on systems with older e2fsprogs
> 
> It turns out for debos the situation is a bit different. Since debos
> uses packages on the host to prepare the partitions, new features in 
> e2fsprogs from unstable which are unsupported in the target suite
> causes the built system to not boot.
> 
> One such failure at boot-time of a Debian testing system is when
> systemd-fsck tries to check a filesystem, it fails to mount the device:
> 
>   /dev/mmcblk0p5 has unsupported feature(s): FEATURE_C12
> 
> So, in short we cannot run images built for suites with older e2fsprogs
> on a host system which has e2fsprogs >=1.47.0-1.
> 
> Fixing grub2 will not fix the issue for debos, so I have retitled the
> bug.
> 
> In debos with newer e2fsprogs, we can set the following flag on a
> partition to disable the feature which allows the system running older
> e2fsprogs to boot, but older e2fsprogs doesn't allow us to set this
> flag:
> 
>   features: [ "^orphan_file" ]
> 
> So to my mind, the bug is in e2fsprogs as it doesn't maintain backwards
> compatibility.

E2fsprogs is always going to be adding new features.  Even if I dumb
down /etc/mk2fs.conf to not enable this feature in Bookworm, it *will*
enable this new feature in the next release of Debian.  This is true
for all file systems; we add new features to improve user experience.

So packages that are creating file systems to be consumed by older
target OS's must either (a) be aware of these changes for all file
systems (for example XFS is enabling the "bigtime" feature by default
in Bookworm to fix y2038 bug by expanding the size of the timestamp in
their inodes), OR, (b) run the mke2fs from the target OS in build
chroot.

This might get tricky for some target OS's, such as for example, GNU
Hurd, but the Hurd *absolutely* needs to either use mkfs.ext4 from
Hurd, or if you are using the mke2fs from Linux, you'll need
"mkfs.ext2 -O hurd".

The assumption that mkfs's from file systems never change and provide
full backwards compatibility for all target OS's is very much an
anti-pattern.

Best regards,

						- Ted