[Nix-dev] systemd in initrd

[Alexander Kjeldaas]

On Fri, Aug 22, 2014 at 5:34 PM, Luca Bruno <lethalman88 at gmail.com> wrote:

> On 22/08/2014 17:28, Nicolas Pierron wrote:
> > I am just saying, that I do not see why we could not use the jobs
> > syntax on top of a string-dependency system which is used by the
> > activation script. Systemd solves job dependencies dynamically to
> > benefit from the kernel scheduling, while the activation scripts are
> > concatenated ahead to make a single & simple activation process. I
> > think there is no need to ""always"" bring the complexity of systemd
> > to the init process, this could be optional. What I suggest is to have
> > a 2 backends for the init process. The systemd one, and the
> > string-dependency one. Of course, the string-dependency backend would
> > have to assert (while building the system) about cases which cannot be
> > handled.
> So you want to parse systemd nixos modules in a restricted mode and
> concatenate them? Yes, that makes sense. However, I'm not sure whether
> that's less work than adding systemd to initrd or it ends up with extra
> complexity and hidden bugs in the translation.
> Additionally, once systemd is started, it's not stopped and then
> restarted after switching root. It will be reloaded.
>
> So it's correct that the complex dependency resolution of systemd is
> overkill, it's also true that systemd is a component that will be
> started anyway at some point.
>

How will actually building the initrd be improved?  I feel that the
dependency resolution is only half of the problem. Things like this is the
other half - manual copying of libraries and binaries to minimize initrd
size:

https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/luksroot.nix#L408

For my use I don't care whether initrd is large, but making systemd
services "portable" to initrd by copying their closures will probably
affect initrd size a lot more than systemd itself.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20140822/df5cdfa9/attachment.html