On Thu, Feb 09, 2023 at 06:55:08PM +0100, Sven Joachim wrote:
> >>
> >> Thanks from me as well :-). To prevent e2fsprogs from migrating to
> >> testing before grub2 and breaking d-i, I am reassigning a copy of this
> >> bug back to e2fsprogs. It may be closed once grub2 2.06-8 enters
> >> Bookworm. Perhaps it would also be a good idea to add a versioned
> >> "Breaks: grub2-common (<< 2.06-8~)" to e2fsprogs.
> >
> > Perhaps we could just add a "Breaks: grub2-common (<< 2.06-8~)" to
> > e2fsprogs-udeb?
>
> That is not going to help, because IIUC grub-install is run from the
> target system that you are installing, and there is no
> grub2-common-udeb.
Right, but if the conflict in e2fsprogs-udeb prevents the installer
from pulling in an overly new version of e2fsprogs-udeb, that woul be
sufficient, no?
After all, you can install e2fsprogs 1.47, and install a newer version
of grub, and there is no problem --- unless you enable the the
csum-seed function on an already installed system. And you can't do
that, because you it's an incompat feature.
OTOH, with e2fsprogs 1.46 you can *ready* run the command "tune2fs -O
large_dir /dev/root" on a running system, and then when you reboot,
the system won't come back, because grub will see the large_dir
feature and freak out (unecessarily). But adding an conflict with
1.46 and grub makes no sense, since it's not _that_ likely that user
will deploy that particular foot-gun. (It happens with Arch and
Gentoo, but those users tend to be much more adventurous, aided and
abetted by Wiki pages that encourage users to help kernel developers
beta test new features. :-)
The reason why I really don't want to add the conflicts with e2fsprogs
1.47 is because for people who are using sid, there is aboslutely
nothing wrong with installing e2fsprogs 1.47. It's only if they use
the installer that sucks in e2fsprogs that there's a problem --- it's
not an inherent conflict with grub per se. If it were, then we
shouldn't allow installation of e2fsprogs 1.46 because grub2 upstream
is painfully slow in putting out releases --- and that's not
reasonable.
Now, what I *could* do is change the mke2fs.conf in e2fsprogs-udeb to
remove the default use of the csum-seed feature ---- but is it worth
it? Hopefully the new version of grub2 will come out soon, at which
point I would then need to revert the hacked mke2fs.conf --- and your
dup'ing this bug should prevent the installer from picking up
e2fsprogs 1.47 until the new version of grub gets released.
I'll note that grub is trying to use an independent implementation of
ext4, as opposed to using the upstream libraries such as libext2 for
ext2/3/4 and libxfs for XFS, combined with grub's very slow release
cycle, means that this kind of thing is going to be happening a *lot*.
It's something that I and Darrick Wong (the XFS maintainer) have
kvetched about a number of times on our weekly conference calls.
For example, recent grub commits that impact XFS that aren't in 2.06
include:
commit a4b495520e4dc41a896a8b916a64eda9970c50ea
Author: Erwan Velu <erwanaliasr1@gmail.com>
Date: Wed Aug 25 15:31:52 2021 +0200
fs/xfs: Fix unreadable filesystem with v4 superblock
The commit 8b1e5d193 (fs/xfs: Add bigtime incompat feature support)
introduced the bigtime support by adding some features in v3 inodes....
Holding back file system development because grub2 uptsream is super
slow doesn't seem like a reasonable way forward, so I really don't
want to set this precedent.
Thinking about this some more, I'd much rather have some kind of
explicit scheme, such as:
mkfs.xfs -T grub2-dumbdown /dev/XXX
Which disables various new file system features that aren't yet
supported by grub, but which users might very well want to use on
non-boot disks.
This could be done by doing something as simple as adding to mke2fs.conf:
[fs_types]
grub2-dumbdown = {
features = ^large_dir,^metadata_csum
}
Then we could teach the Debian installer to use the file system usage
type "grub2-dumbdown".
Of course, moving forward we'd have to update mke2fs.conf as grub
finally learns new features, and since mke2fs.conf is a config file,
people would have to edit it by hand post-install if they have
customized it in any way. Unless we add the above in
/etc/mke2fs.conf.d/grub2-dumbdown, and then teach mke2fs to understand
the /etc/mke2fs.conf.d directory...
- Ted