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 <erwanalia...@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