Am Dienstag, dem 14.02.2023 um 10:45 +0000 schrieb Steve McIntyre: > On Tue, Feb 14, 2023 at 11:34:13AM +0100, Daniel Leidert wrote: > > Am Montag, dem 13.02.2023 um 21:35 -0500 schrieb Theodore Ts'o: > > ... > > > > But a generalized requirement that we be able to use debootstrap and > > > vmdb2 to be able to bootstrap an arbitrarily old distribution doesn't > > > seem to be reasonable. > > > > You are completyl wrong. This breaks a standard way of installing any > > system supported by deboostrap with a grub without a fix to deal with > > this version of e2fsprogs. This isn't just about vmdb2. > > > > What you are saying is ignorant. > > > > If this isn't cared about, then this version of e2fsprogs shouldn't > > make it into Bookworm. We are in the middle of a freeze and this breaks > > toolchains and a standard way (see [1]) of installing Debian. > > Sorry Daniel, but I have to (mostly!) agree with Ted here. If you're > creating an image of an older release using newer tools then you'll > need to be aware that sometimes the newer tools will create things > that don't work there. If there's a bug here, I would strongly argue > that it's in vmdb2. deboostrap (for example) includes some > release-specific knowledge to cope with issues like this.
debootstrap does nothing related to grub. So it is a bad example. Again I refer to [1]: If the host system contains the problematic e2fsprogs and the target system doesn't contain a grub with the fix [2], then this breaks installations. This breaks older systems *and* current systems. For example, I neither see the necessary grub patch in both Ubuntu 20.04 and 22.04 either. So they also cannot be installed using the deboostrap method and the toolchain in Sid (and Bookworm if e2fsprogs makes it there). [1] https://www.debian.org/releases/stable/amd64/apds03 [2] Even "our" grub only contains a patch and not an upstream version with support. So how can you even expect the target system to contain a fix and be able to handle the created filesystem?! Whe whole handling is completely wrong here. First, grub should have been fixed upstream. And the change in e2fsprogs should have been done only after "fixed" grub versions had settled. If we do it the other way around, we have to patch grub in affected distributions as well. And for Debian that means at least to patch Bullseye and any other release we want to be able to install from Bookworm. I even a lot of companies using Buster still. > If we don't allow for this kind of change, that wouldn't allow us to > *ever* make breaking changes in some packages, and that's just not > sustainable. I'm critizicing the way of handling that breaking change and the ignorance shown reagarding the impact, not that fact that there is a breaking change. And it breaks a lot! This doesn't affect just a few minor use cases. It affects the basic way of installing a clean Ubuntu or Debian (or derivative) on a remote server using the debootstrap method. And again: We are in the middle of a freeze here. And e2fsprogs pushes a breaking change that is not even handled by any existing grub upstream release, and is also not properly handled within Debian?! Daniel