Simon McVittie <smcv@debian.org> (2023-02-19): > Are d-i alphas and weekly builds built differently? Is it perhaps the > case that alphas are built from testing udebs, while weeklies are built > from unstable udebs? Let's quote <https://www.debian.org/devel/debian-installer/index.en>: - Or install the current weekly snapshot of Debian testing which uses the same version of the installer as the last release: > Current weekly snapshots - If you prefer to use the latest and greatest, either to help us test a future release of the installer or because of hardware problems or other issues, try one of these daily built images which contain the latest available version of installer components. > Current daily snapshots We're in the first case: https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/ > I don't know how to list the versions of the installed udebs and > mke2fs doesn't seem to have a --version option You can check /var/lib/dpkg/status (or look at the MANIFEST.udebs file in the d-i tree if you know where udebs came from). Here, e2fsprogs-udeb is at 1.47.0-1, which explains the problem. But the installer is clearly not “the same versions of the installer as the last release” since it features linux 6.1.8-1… Cc-ing debian-cd@ for input; quoting the rest of your reply in full. > I had expected that weekly builds are expected to be able to install > testing. If that expectation is correct, then that means weekly builds > need to be built from udebs that will create a filesystem that is > considered acceptable by testing user-space (and bootloaders and kernels, > but this bug report is about user-space). > > > Closing this bug report as it's not a practical issue with the version > > just released, and since it shouldn't be an issue with later releases > > given grub2 in testing should cope just fine. > > Note that my bug report is not about whether grub2 in testing copes > with the filesystem created by d-i: when I installed from the 2023-02-09 > weekly build, grub successfully loaded my kernel and initramfs, so that > part at least seems fine. The issue I was having is that the *initramfs* > from the testing system I installed did not cope. > > If I'm right about weeklies being built from unstable udebs, then I > think this will continue to be a problem *for weekly builds* until either: > a version of e2fsprogs that can fsck filesystems with metadata_csum_seed > and orphan_file migrates to testing; or e2fsprogs stops enabling those > features on at least the filesystems created in d-i (optionally all new > filesystems, but this particular bug report is about d-i only). Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature