mbox series

[SRU,N,0/1] Include scsi_debug/nvmet-tcp in linux-modules instead of linux-modules-extra

Message ID 20240423182009.1117677-1-daan.j.demeyer@gmail.com
Headers show
Series Include scsi_debug/nvmet-tcp in linux-modules instead of linux-modules-extra | expand

Message

Daan De Meyer April 23, 2024, 6:19 p.m. UTC
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(+)

Comments

Roxana Nicolescu May 24, 2024, 12:02 p.m. UTC | #1
On 23/04/2024 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(+)
>
Acked-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>
Tim Gardner May 24, 2024, 1:31 p.m. UTC | #2
On 4/23/24 12: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(+)
> 
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Stefan Bader July 30, 2024, 9:18 a.m. UTC | #3
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
Daan De Meyer July 30, 2024, 1:01 p.m. UTC | #4
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@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
>