Processed: Re: Bug#810367: kmod-static-nodes.service fails without a dependency on kmod

[Debian Bug Tracking System]

Processing control commands:

> severity -1 wishlist
Bug #810367 [src:systemd] kmod-static-nodes.service fails without a dependency 
on kmod
Severity set to 'wishlist' from 'normal'

-- 
810367: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810367
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#810367: kmod-static-nodes.service fails without a dependency on kmod

[Helmut Grohne]

Source: systemd
Version: 215-17+deb8u2

Hi Martin, Michael and other systemd folks,

in another attempt at exploring systemd, I noticed that you can install
a base system with systemd without installing kmod. This is useful for
minimizing an installation when your kernel does not support module
loading. It is also useful when systemd's own module loading
capabilities via libkmod are sufficient.

When doing so however, kmod-static-nodes.service loudly fails finding
kmod. I argue that this is a bug in the systemd packaging. Either that
service is optional. In this case it should gain a ConditionPathExists.
Or it is required for running the system. In which case systemd should
gain a runtime dependency on kmod. In the former scenario recommending
kmod still looks like a good idea to me.

In my embedded use case, the service actually creates an empty
/run/tmpfiles.d/kmod.conf and is thus not necessary for proper
operation. Thus I have a slight preference for the former solution. At
the same time I understand that the latter is easier to support.

I am reporting this bug against the jessie version, because I discovered
it there, but it applies to the unstable version as well. I do not think
this is worth fixing in jessie as it is a corner case and has trivial
workarounds.

Helmut

PS: For better serving the embedded, it would be nice if systemd could
provide a smaller installation size (i.e. making more components
optional). I understand splitting that systemd in more packages and
making some of them optional is considerable amount of work and I
have little suggestions on how to do that, but maybe you have. Maybe
logind or the some of the dbus support (as dbus is already optional)
could be moved somewhere else? Of course the default installation
should keep these components.

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Bug#810367: kmod-static-nodes.service fails without a dependency on kmod

[Felipe Sateler]

Hi Helmut,

On 8 January 2016 at 12:47, Helmut Grohne  wrote:
> Source: systemd
> Version: 215-17+deb8u2
>
> Hi Martin, Michael and other systemd folks,
>
> in another attempt at exploring systemd, I noticed that you can install
> a base system with systemd without installing kmod. This is useful for
> minimizing an installation when your kernel does not support module
> loading. It is also useful when systemd's own module loading
> capabilities via libkmod are sufficient.
>
> When doing so however, kmod-static-nodes.service loudly fails finding
> kmod. I argue that this is a bug in the systemd packaging. Either that
> service is optional. In this case it should gain a ConditionPathExists.
> Or it is required for running the system. In which case systemd should
> gain a runtime dependency on kmod. In the former scenario recommending
> kmod still looks like a good idea to me.

kmod-static-nodes.service already has:

ConditionPathExists=/lib/modules/%v/modules.devname

That is, you have a kernel installed that require static device node
creation. On my system I do:

% aptitude why kmod
i   linux-image-amd64  Depends linux-image-3.16.0-4-amd64
i A linux-image-3.16.0-4-amd64 Depends kmod | module-init-tools

(m-i-t is a transitional package for kmod).

So, evidently you have a self-built kernel. Is it reasonable to expect
self-compiled kernel users to satisfy the dependencies of the kernel
packages? I'm not sure there is a clear-cut answer for this. But if
you are compiling a kernel with module support, not installing kmod
looks very weird to me.

>
> In my embedded use case, the service actually creates an empty
> /run/tmpfiles.d/kmod.conf and is thus not necessary for proper
> operation. Thus I have a slight preference for the former solution. At
> the same time I understand that the latter is easier to support.

Or have your kernel not ship the modules.devname if it is empty. (BTW,
is it actually empty, or does it contain a comment? If it is empty,
then maybe we can change to ConditionFileNotEmpty).

>
> I am reporting this bug against the jessie version, because I discovered
> it there, but it applies to the unstable version as well. I do not think
> this is worth fixing in jessie as it is a corner case and has trivial
> workarounds.
>
> Helmut
>
> PS: For better serving the embedded, it would be nice if systemd could
> provide a smaller installation size (i.e. making more components
> optional). I understand splitting that systemd in more packages and
> making some of them optional is considerable amount of work and I
> have little suggestions on how to do that, but maybe you have. Maybe
> logind or the some of the dbus support (as dbus is already optional)
> could be moved somewhere else? Of course the default installation
> should keep these components.

The largest component is networkd, but it requires a lot of conffile
shuffling, so I'm not sure it is worth the effort. For my own use
cases, I actually want networkd everywhere, so that is not an itch I'm
particularly eager to scratch.




-- 

Saludos,
Felipe Sateler

___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers