Re: Bug#1088605: installation-reports: No installable kernel was found in the defined APT sources

Cyril Brulebois <[email protected]> Sun, 8 Dec 2024 00:38:09 +0100

Newsgroups	gmane.linux.debian.devel.cd
Organization	Debian
Message-ID	<[email protected]>

Cyril Brulebois <[email protected]> (2024-12-07):
> Right now I'm seeing modules for 10 kernel ABIs, that can't help.

After a quick look, I suppose we could extract the kernel ABI(s) from
MANIFEST.udebs, matching kernel-image-(.+)\s, and focusing on including
only the relevant modules. Most architectures have a single kernel-image
but not all of them (mips64el notably).

Additionally, given how critical it is to have linux-image-* available
on netinst images, I think we should break the build if no such packages
make it into those images.

We have a lot of #ifdefs in tools/generate_di+k_list and some archs have
multiple linux-image-* metapackages pulled, so maybe it'd be safer to
check against the intermediary list I mentioned before (list.mid),
making sure all linux-image-* packages it contains made it onto the
disk? But a simple “no linux-image-* packages at all? surely broken!”
heuristic would already be a net win?

> I lost count of how critical it is to have firmware-nvidia-graphics
> available (I thought it wasn't of much use, and was initially expected
> not to move to nff for bookworm, which it did eventually anyway), but
> that one alone steals 30+ MB of space before linux-image-*.

Leaving that aside for now.

> I haven't looked deeper at this point, maybe we have some other kinds of
> “duplication” (not sure the t64 thing is over at this point, but I could
> imagine how we might pull t64 and pre-t64 libraries until everything is
> successfully rebuilt against the t64 ones).

Leaving that aside for now.


Cheers,
-- 
Cyril Brulebois ([email protected])            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

signature.asc (application/pgp-signature, 833 B)