Cyril Brulebois <k...@debian.org> (2024-12-08):
> FWIW the X server no longer starts when d-i is built against 6.12.3, it
> loops with “no screens found”. This is the gtk mini.iso, standard QEMU
> in stable, and 2G of RAM (i.e. `kvm -cdrom netboot/gtk/mini.iso -m 2G`).
> 
> Seeing how today's daily build[1] (against the last 6.11.y) is still
> fine, I don't think this is a matter of “kibi's system is effed up”…
> 
>   1. 
> https://d-i.debian.org/daily-images/amd64/20241208-00:13/netboot/gtk/mini.iso

Alright. We have a workaround (one day©®™ I'll find time to actually
debug that other issue) which kicks in depending on the presence of
drm.ko (initially), then drm.ko.xz (once modules got compressed), to
ship more DRM modules in some d-i images.

But linux-image-6.12.3-amd64 only ships *.ko now, which makes the
workaround ineffective. Dropping the .xz suffix in the few relevant
places of build/Makefile makes the d-i build include the extra DRM
modules again, and X is happy to start.

D-igression: That being said, I'm not sure why X wouldn't start without
the DRM workaround (which is there to avoid running into hardware
detection issues leading to a corrupt display in some circumstances).
Maybe that's been papering over another bug for a long time (one might
remember fbdev got a few back and forth regarding some changes that were
breaking ppc64el, not sure where that landed in the end).

Back to the matter at hand: was dropping compression intended? I'm not
seeing anything matching “compress” in debian/changelog when diffing
debian/6.11.10-1..debian/6.12.3-1 in linux.git…

I see upstream seems to have renamed something:

    -## choice: Module compression mode
    +## choice: Module compression type
     CONFIG_MODULE_COMPRESS_XZ=y
     ## end choice

but that seems to be about setting a different title… Looking at
v6.11..v6.12 upstream (very briefly), it looks like MODULE_COMPRESS
should be set, which it is not at the moment?

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c7ff693fa2094ba0a9d0a20feb4ab1658eff9c33

On the d-i side, I'll just commit the .xz removal for now (making the
DRM workaround effective again), which can be reverted if and when the
kernel gets compression support again.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

Reply via email to