On 2015-04-23 at 17:15 +0200, Lennart Poettering wrote: > On Thu, 23.04.15 18:09, Ivan Shapovalov (intelfx...@gmail.com) wrote: > > > On 2015-04-23 at 16:48 +0200, Lennart Poettering wrote: > > > On Thu, 23.04.15 17:46, Ivan Shapovalov (intelfx...@gmail.com) > > > wrote: > > > > > > > On 2015-04-23 at 14:11 +0200, Lennart Poettering wrote: > > > > > On Thu, 26.02.15 02:46, Ivan Shapovalov (intelfx...@gmail.com > > > > > ) > > > > > wrote: > > > > > > > > > > > This is useful, for example, to create system accounts on > > > > > > an > > > > > > initramfs > > > > > > using the host's configuration. > > > > > > > > > > Hmm, but you can already do this, by specifiying the config > > > > > files on > > > > > the command line, no? > > > > > > > > Actually, this means duplicating the logic of determining of > > > > the > > > > directory list (/usr/lib vs /lib, ...). > > > > > > True, but it's not *that* complex in that case... > > > > Not really, because it is then also needed to do priority > > -overriding > > of the configuration snippets by hand. I would really like to > > avoid re > > -implementing this logic. > > > > There is an alternative to bind-mount all configuration directories > > into the destination root, but it's not "atomic" against killing of > > the process (if we get killed in between, stale bind mounts will > > remain). So I won't like to do this either. I'm sure that > > mkinitcpio > > maintainer in arch will not accept this solution as well. > > > > Any other options? > > Hmm, I don't really see the use for this I must say. That said, I > figure I would accept a patch that adds a new switch > --configuration-root= or so, similar to your original patch, but > leaves --root= as it is right now, and really only adds a new > --configuration-root= that if specified overrides the root directory > otherwise specified for the reading of the configuration files. > > If you add this tmpfiles should probably get something similar, to > make this match up nicely...
Actually, thinking about this once more, I've realized that my usecase is broken. I wanted to use systemd-sysusers to generate new passwd/group for the initcpio, but never realized that newly created UIDs and GIDs can mismatch the host ones (and we are copying files from the host). So, disregard this patch, there is indeed no usecase so far. -- Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
