Hi Helmut, On 8 January 2016 at 12:47, Helmut Grohne <[email protected]> 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 [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
