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 |
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>
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>
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
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 >