XPost: linux.debian.maint.boot

[ Adjusting recipients for the heads-up… ]

Salvatore Bonaccorso <[email protected]> (2024-12-07):

I would like to upload linux version 6.12.3-1 to unstable.

This is a new upstream version with, as usual, many changes.
This is a LTS release upstream[1] and *is* the version we aim to have
in trixie. So we would like to see moving from 6.11.y for unstable
ASAP even if this is an upload mostly directly after the upstream
merge window.

ACK.

The pending changes in the package are:

* libbpf: Add missing per-arch include path (fixes FTBFS on riscv64).
* [riscv64] Enable EFI_FB
* d/b/gencontrol.py: Fix generation of debian/tests/control
* linux-kbuild: Add scripts/module-common.c (Closes: #1087495)
* objtool: Fix compiler flags leaking to fixdep in cross-build
* linux-image: bug: Update list of related firmware packages
* [x86] add patches from maillist to fix intel_soc_pmic_bxtwc irq issues.
* [x86] enable INTEL_BXTWC_PMIC_TMU, TYPEC_WCOVE as module.
* [amd64] Enable Compute Acceleration Framework and drivers
(Closes: #1086054)
- drivers/accel: Enable DRM_ACCEL
- drivers/accel/habanalabs: Enable DRM_ACCEL_HABANALABS as module
- drivers/accel/ivpu: Enable DRM_ACCEL_IVPU as module
* [x86] Enable VIDEO_OV5670 as module
* [arm64] Enable Texas Instruments ADS8688 driver (TI_ADS8688) as a module.
* [amd64] Enable KVM support for XEN hypercalls
* fs/ntfs3: Enable NTFS3_FS as module (Closes: #998627)
* [arm64] drivers/clk/mediatek: Drop dead config options
COMMON_CLK_MT8195_AUDSYS and COMMON_CLK_MT8195_MSDC

We are not yet through the new symbols to see which features and
support we defintively would like to include, but there is time for
that yet.

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


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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmdVAuEACgkQ/5FK8MKz VSCEaA//SQp1lQSHN083mNNc8UvYv0z1npw0PZN7YIE9u+vjKQPiJMm6Mhvto/Fa aTg9sLjBf20M1C10283VtMYpVHjd1JzdkRC1j3ySSCauxrpEEJ24w/Q9Jn7Pt+nW P/DRTLTSpxUw3hvyTURMrWaLGwCNvqPbzySsAyMDG24IFalslzWc301EuRNU1Hnt FgdPnwzB99yOLesBwtV5/BJKDHhoyRTwDD6w/3MDQGt5uSQG2cAQ7zofkv7lG0KW 8r9JuWnR0IXkRA1xnvJBlHT45kFUivV9h4uzDfFvHvRGxNH9UQ4HLXs4tS1HPSay +YD7Yw8Z5z7v2WPR0V5AEczhbzlgHSdxc7F/jeOz2n5ZDvwUbINUXxk6dD98w/Oc RKLy/T7xLtxMiwisTRxCmGkS4uJfjTzq+l/p/BzjGY5qToL2bpH3pX6dJCwXCngf N8IuZ2MBnHHeZ2HgKgcRlKlYj8h+7R+Q9wNeqR/dUQXZoWQSiESuLc1zHCHFTtCt G1j5OnicQlwfVz461bQUlhVzXTMTzXLCe9UBPl2jLx43Tirw6tolYTixaEebWdsB A3slC2dNaiZeLAvHqrbyoDiNnYs3nXBeeUr7gBNIiEb0Xd54dVt8W6PxLVvf62t1 GLXow4VCYsU3Hy8k/aw4kT5pqW8v3sNng1qjNicj2B8VWNkIPhU=
=jcsP
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot

Cyril Brulebois <[email protected]> (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 ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmdVCqgACgkQ/5FK8MKz VSBJrA/8Cd6C6sBswkE9PZFmSOMjHskSzbeqNXP4TIRThmTdVHnrZoEIsa8j13tE 0IZL1Ayggde9kAaWNOVScV5gTUalGuTJXuGMJirQw7gH4qrs22PCL7R3PD+O5TMW Hs5qmaLRz9Yxl0W94FX0XpwimYRNKYPR1n7qgxPaSlkA89R7Yg+VxA3abCJXkLud /VO4djTM6M2RukV7hP/YtNoIWv1Mh9JlTjGIG1O3F6tRS+UXdpvKjZ5Om57NESLl 0ggTbntTyVB7OMZaGsKBWSxMydZ1VoxTXSQ/0ISVtFQBuoWKqIdfuz0s3mzL9MzN 00HcfNp2/u1FCtZfrtFNnn7XH2n53nhpfDDxMnHlPSNan9jHVVP2Y8Hi8g3wzJlW UhxqK+VS/pGSyDimeWrtO1IGz+6FPfxeBMNoeV+9+hz+/uX7vmUZYC5UnyfBySrd 3TvvewCHgJjaZdpcewyp1AIN8t23IRojouYsNeg/DBoOJiJ9cXDLugBa1kdQB5CD hdcM/7+QuEtHdU+fwbINhzNxmetl4mLEM9ZTXioZKNdVqNOfdw+9FbzxXVhhJs5y yFB9sSSB6YUkfzkWVsoBRI8s9Ub/7yoxo4rHTY8k9/FK6vjysQqpdZMIn4OaP2NX nS+4ZH8cIVcS85S7SDsaTWW8RPLAJl1PfZfgKuhVPqATWLVpfuU=
=LTUk
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot

On Sun, Dec 08, 2024 at 03:55:38AM +0100, Cyril Brulebois wrote:

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?

Exactly. They added that as global switch on knob.

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.

Can't we properly fix this now?

Bastian

--
Earth -- mother of the most beautiful women in the universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

On 08/12/2024 at 03:55, Cyril Brulebois wrote:

Cyril Brulebois <[email protected]> (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`).

FWIW this issue has already happened for a while with previous kernel
versions in virt-manager (QEMU) with QXL graphics (which works with
bookworm installer) and on real amd64 hardware with AMD, Intel, and
Nvidia graphics [1].

[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082741>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.maint.boot

Pascal Hambourg <[email protected]> (2024-12-08):

On 08/12/2024 at 03:55, Cyril Brulebois wrote:

Cyril Brulebois <[email protected]> (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 xorg-server on the testing-summary page, I've just tried that
again and that's no longer an issue.

FWIW this issue has already happened for a while with previous kernel versions in virt-manager (QEMU) with QXL graphics (which works with bookworm installer) and on real amd64 hardware with AMD, Intel, and Nvidia graphics [1].

[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082741>

The important part being:

Changes:
xorg-server (2:21.1.15-2) unstable; urgency=medium
.
* New upstream release.
* patches: Fix pci detection on recent linux. (Closes: #1075713)

With thanks to Timo for including this patch in that upload, and of
course to Tj who really put quite some efforts into debugging this.


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

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmdnruMACgkQ/5FK8MKz VSDuyg/+L5fi2ORCTBvxrPzREwe4G/6Fks7FxM0eTM+ABxjWayGLjndGVlE7kXRk zYOLMMjv5cP7asPsUle2Ntr840eiOT0yLlN+4QodJeugFn13ki53xl7CkSKZ/wjk 5mJPLud4edV+ZNoGGiphkKK6dbj319qHvjTbMfZ7aKPcdc2aqnBOG8W6jKF4ChEj xtELJBDlKTqufbFeUqTgKIk+sjH8X/hHx74rT9IYZx28ErB0mWsbqLAu0+yrv8S6 6nFOFDd3uZcdURMMdY44r+DwvgtZ2fTiaZBZtcKovqJsA7E6qmbkgRkcC0bAL4nS wBOq76s6bpV7Fo9Fs0GSHWirtJRhi9oMIUTCnklKDE97+bYoYCSEwJGT5AZ7O9q+ k+xGWniw8J6Um+FJbDTfRTZA6bw8TpFtpNjGX9VJH7xa3NbYru87ti9RlJNqotNc 1QbOsdYISxGfXieSGb3xVSiJtB5wcv5lEJq5aQaCzo5EMgl/mkIds4O6REuKptbu uyojpVEYPBLH7wP3gU7aqz44pTphyJ/p3dPSQ/bvQnsLMrm6cEDgclFYn9jM5Bga gsttjLOWjEt1N3j9xxz35UlCEhGROPKNHF4LkVYmg6KhO7JvYkp9jIocs8HRh0Tg Fx+wteSXBOvveCNPuBrrlgAQoGc3oGmuU7PST5JHwoRA8eOBO3w=
=oNVr
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*