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

[Daan De Meyer]

Hi Stefan,

> 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[-hw
> e-24.04]".

Aha, I had no clue this existed. This should do the trick nicely, thanks!

Cheers,

Daan De Meyer

On Tue, 30 Jul 2024 at 11:18, Stefan Bader <stefan.bader at canonical.com> wrote:
>
> 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
>