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/>"
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<amaca...@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,
