NACK/Cmnt: [SRU][N][PATCH 0/1] Include scsi_debug/nvmet-tcp in linux-modules instead of linux-modules-extra

[Stefan Bader]

On 23.04.24 20:19, Daan De Meyer wrote:
> Buglink: https://bugs.launchpad.net/bugs/2063233
> 
> SRU Justification
> 
> [Impact]
> 
> The scsi_debug.ko and nvmet-tcp.ko modules are currently shipped in
> linux-modules-extra. This makes it hard to pull them in via the linux-virtual
> package, it can only come from the linux-generic one that also pulls in the
> firmware and everything else needed for baremetal, and that serves no purpose in
> a qemu VM. This stops VMs using these kernels from using these modules. These
> modules are required to run the systemd integration tests which we are trying to
> run in VMs on Github Actions (https://github.com/systemd/systemd/pull/32439).
> 
> [Fix]
> 
> Please consider moving these modules to linux-modules.
> 
> These are already enabled in the 'main' kernel config, and in other distros. In
> Debian/Archlinux/Fedora these are core modules that are built by default. e.g.
> in Fedora both modules are part of the kernel-modules-core package.
> 
> [Test]
> 
> 1. pull built linux-modules packages for architectures with do_extras_package
>     set to true;
> 2. extract the deb and check if the kernel module files exists:
> 
>     $ dpkg-deb -R linux-modules-*.deb .
>     $ find . -name scsi_debug.ko\*
>     $ find . -name nvmet-tcp.ko\*
> 
> [Regression Potential]
> 
> Moving a module from a less-common to a more-common package should not have any
> negative side effects. The main effect will be a little more disk space used by
> the more common package, whether the module is in use or not. There will also be
> more functionality available in the default installation, which means a slightly
> increased surface and possibility of new bugs in case it gets used.
> 
> Daan De Meyer (1):
>    Include scsi_debug/nvmet-tcp in linux-modules instead of
>      linux-modules-extra
> 
>   debian.master/control.d/generic.inclusion-list | 2 ++
>   1 file changed, 2 insertions(+)
> 

Sorry for this really late response. It was sitting around and always 
getting pushed down the stack by other things. We have been pondering 
about that. The initial idea with virtual was to have a minimalistic 
option for VMs for broad generic use case. One or two modules more of 
course do not change the footprint that much. But then the next special 
case comes along and so on. Also scsi_debug feels a bit like it might be 
something too "poweful" to have around for safety (security) reasons.

There is, however a middle-ground. It is admittedly a little too well 
hidden in naming schemes. The virtual installation has a meta package 
available which installs and updates the modules in the modules-extra 
package (without pulling in additional external dependencies). It's name 
is "linux-image-extra-virtual[-hwe-24.04]".

So by doing an

apt install linux-virtual linux-image-extra-virtual
or
apt install linux-virtual-hwe-24.04 linux-image-extra-virtual-hwe-24.04

you would get the generic kernel with all modules but without the additional
dependencies installed and kept up-to-date.

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 48643 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240730/a780442f/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240730/a780442f/attachment-0001.sig>