Thank you for the answer. Good to know that it is a known issue and is being taken care of.
Regarding why I took that image. I just followed the official Debian webpages:
https://www.debian.org/CD/http-ftp/index.en.html
From there I clicked on "Official
CD/DVD images of the testing
distribution (regenerated
weekly)"
https://cdimage.debian.org/cdimage/weekly-builds/ -> amd64 -> iso-cd -> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
So from my perspective I wasn't using a "random" image, but rather an official one, as the web pages indicate.
Best regards,
Hi, Andrew, please use reply-all, to reply to the bug and to the bug submitter. A list-only reply doesn't quite help… Andrew M.A. Cater <amacater@einval.com> (2023-02-25):I have installed Debian testing (bookworm) from one of the latest ISO images (https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing- amd64-netinst.iso from 2023-02-21) and after an apparently succesfull installation the system cannot be booted.Enrique, thanks for the report. We've published an official release one week ago. I'm not sure why you're not using that instead of a random weekly build.This is a known issue - try using the Alpha 2 installer in which this issue is not present. The e2fsprogs mismatch with grub is likely to be fixed by reverting problematic versions.No, the problem here is that e2fsck is from testing, while the filesystem has been created by mke2fs from unstable, and the former doesn't know about a new feature turned on by the latter. Cheers,