Immediate fallouts from the big linux changes, and actions

[Cyril Brulebois]

Hi,

This is mostly for information: linux went through a lot of big changes,
initially staged in experimental, and uploaded to unstable as of linux
6.6.8-1. These impacted the installer in different ways. This is a
summary of the obvious impacts, there might be some others down the line
(just by glancing at hw-detect's massaging of module list by stripping
the .ko suffix).

- kernel-image-* packages are now shipping /boot/vmlinuz-* (or
/boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz
(respectively /boot/vmlinux). I didn't dive into all the changes but
I'm not sure whether that was on purpose or a side effect of the big
changes. In any case, on the short term, since the build system was
relying on a single file there, that should be moved out of the way,
I decided to unversion those files to restore the old names. If kernel
maintainers decide to go back to unversioned files, two reverts should
be enough:
https://salsa.debian.org/installer-team/debian-installer/-/commit/c17360e632b6f133d4b43a47461944b6203ed730
https://salsa.debian.org/installer-team/debian-installer/-/commit/865c66e497d8e809872bad04aa2269d2a9f889c8

- Modules are compressed now, so the drm workaround needed an updated to
cope with the extra .xz suffix:
https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea

- I'm skipping two commits regarding the new way the ABI is written
down, that's in line with what was announced initially.

- YIL: If you don't see anything move in the graphical installer (no
keyboard, no mouse), if your video is garbled, and if you can't load a
NIC module in the text installer, you might have a totally broken
support for kernel modules in your installer. This required adjusting
src:xz-utils to get a liblzma udeb and src:kmod to enable xz support
in its udebs; “thankfully” the former is NMU-maintained, plus the ftp
team speed-reviewed it from NEW; thankfully Marco ACK'd my NMU-ing
kmod so that we unbreak things ASAP. Everything should be sorted out
in unstable. Plus an extra commit to be extra careful between the
kmod upload and the cronned daily builds (which were going to start
before the 01:52Z dinstall):
https://tracker.debian.org/news/1489255/accepted-xz-utils-545-02-source-amd64-all-into-unstable/
https://tracker.debian.org/news/1489268/accepted-xz-utils-545-03-source-into-unstable/
https://salsa.debian.org/md/kmod/-/merge_requests/13
https://tracker.debian.org/news/1489283/accepted-kmod-3020230601-21-source-into-unstable/
https://salsa.debian.org/installer-team/debian-installer/-/commit/c65bdb8128bc68cb566b302feb46267e5c177eb4

- Finally, the armel build fails because it can't find its kernel. The
marvell flavour seems to have been dropped entirely (at least that's
how I read the linux changelog for 6.6.3-1~exp1:
https://tracker.debian.org/news/1482751/accepted-linux-663-1exp1-source-into-experimental/

I didn't investigate the last point and I'd appreciate it if porters
could double check that we really want to drop marvell at this point,
and maybe submit (or commit) patches to drop it from the installer:
https://salsa.debian.org/installer-team/debian-installer

Various netboot and netboot-gtk checks on amd64 seem very positive
after those changes, but I haven't built a netinst image and checked
on actual hardware with the combination of Secure Boot + firmware
packages + reloading of kernel modules. The latter should primarily work
by using module *names* and firmware *paths* as seen in kernel logs, so
having different module *paths* shouldn't make a difference, but that's
just my gut feeling based on my recollection (so nobody should trust
me on this), and seeing how \.ko$ stripping appears in some other files,
I cannot be certain until it's been actually tested.

Feel free to reply to this thread if you spot other fallouts. Of course,
as usual, the best way to report installer bugs is to file them against
the relevant component, X-Debbugs-Cc-ing this list; but leaving an
explicit reference in this thread wouldn't hurt.


Cheers,

[Bastian Blank]

Post by Cyril Brulebois
- kernel-image-* packages are now shipping /boot/vmlinuz-* (or
/boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz
(respectively /boot/vmlinux).

This was even dependent on architecture. A lot of secondary
architectures already had various suffixes.

Post by Cyril Brulebois
- Modules are compressed now, so the drm workaround needed an updated to
https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea

This now hardcodes .xz. And I'm not really sure what this does and why
this can't be fixed in the kernel packages.

Post by Cyril Brulebois
- Finally, the armel build fails because it can't find its kernel. The
marvell flavour seems to have been dropped entirely (at least that's
https://tracker.debian.org/news/1482751/accepted-linux-663-1exp1-source-into-experimental/

Yes, the kermel was broken and the checks for this disabled since quite
some time.

Bastian

[Cyril Brulebois]

Post by Bastian Blank

Post by Cyril Brulebois
- kernel-image-* packages are now shipping /boot/vmlinuz-* (or
/boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz
(respectively /boot/vmlinux).

This was even dependent on architecture. A lot of secondary
architectures already had various suffixes.

Looking at kernel-image-* 6.5.13-1 for release archs, I'm only seeing
mips64el (-6.5.0-5-5kc-malta, -6.5.0-5-loongson-3, -6.5.0-5-mips64r2el
suffixes), and its build targets didn't hit the codepath I had to patch
for the general case.

Anyway, since you're not reacting with “oops, we didn't mean to”, I'm
going to count this as a deliberate change.

Post by Bastian Blank

Post by Cyril Brulebois
- Modules are compressed now, so the drm workaround needed an updated to
https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea

This now hardcodes .xz. And I'm not really sure what this does and why
this can't be fixed in the kernel packages.

Because that's a workaround for a problem that's not in the kernel and
that remains to be fully investigated.


Cheers,