[systemd-devel] [PATCH 0/3] using firstboot and sysusers to construct an initramfs

Ivan Shapovalov intelfx100 at gmail.com
Sat Mar 7 07:25:19 PST 2015


On 2015-03-07 at 15:01 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Mar 05, 2015 at 09:42:17PM +0300, Ivan Shapovalov wrote:
> > On 2015-03-05 at 19:16 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Thu, Mar 05, 2015 at 09:09:54PM +0300, Ivan Shapovalov wrote:
> > > > On 2015-02-26 at 02:53 +0300, Ivan Shapovalov wrote:
> > > > > On 2015-02-26 at 02:46 +0300, Ivan Shapovalov wrote:
> > > > > > Hi there.
> > > > > > 
> > > > > > These patches allow using firstboot and sysusers together to construct an
> > > > > > initramfs with a fully functional emergency.service and rescue.service.
> > > > > > 
> > > > > > Moreover, they allow to build a "clean" passwd for the initramfs and don't
> > > > > > resort to copying it from the host system (as it has been done in Arch's
> > > > > > mkinitcpio).
> > > > > > 
> > > > > > The first one allows sysusers to take configuration from the real root
> > > > > > but to apply it to a specified alternate root.
> > > > > > 
> > > > > > The next two patches fix an apparent integration problem between firstboot
> > > > > > and sysusers, as previously described here:
> > > > > > http://lists.freedesktop.org/archives/systemd-devel/2015-February/028355.html
> > > > > > 
> > > > > > All in all, with this series I'm able to do a simple
> > > > > > 
> > > > > > 	systemd-firstboot --root="$BUILDROOT" --root-password=""
> > > > > > 	systemd-sysusers --dest-root="$BUILDROOT"
> > > > > > 
> > > > > > and, after adding respective units and /sbin/sulogin to the initramfs,
> > > > > > to use "rd.systemd.unit=rescue.target" as a complete alternative to pre-systemd
> > > > > > arch-specific "break=premount" kernel parameter.
> > > > > >
> > > > > > [...]
> > > > > 
> > > > > Forgot to add Dave Reisner to Cc:.
> > > > > 
> > > > > Dave, what do you think about all this? If this is a bad idea, then I'm
> > > > > open for suggestions.
> > > > > I just miss these "break=..." from the pre-systemd era.
> > > > > 
> > > > 
> > > > Anyone?
> > > 2/3 and 3/3 look fine. For 1/3 I was wondering if it wouldn't be simpler
> > > to simply copy the sysuser files into the tree. The semantics are then
> > > clear. But right now, if there are sysuser files in the source root, and
> > > in the destination root, it becomes unclear how to sort and merge them.
> > 
> > Well, the intended semantics are pretty clear as well: simply ignore
> > configs everywhere except the --config-root. (Just like we ignore
> > configs in / when --root is given, for example.)
> Right, the semantics are clear as far as the patch goes and they fit your
> use case. But I think they would be less intuitive to users in general. 
> The main idea of sysusers (and tmpfiles) is that after wiping /etc the
> can be restored to "factory defaults". If the configuration is created
> using external files in --config-root, this property is lost.
> 
> Even if you don't intend / don't support wiping /etc, I still see value
> in seeing that certain parts of the configuration came from sysusers.
> 
> > Yes, copying/symlinking sysusers.d directories or individual files into
> > the initramfs build root is less intrusive from the code perspective.
> > But what if people add their own sysusers.d (people tend to have crazy
> > setups...)? That'll need to be worked around.
> I don't understand. If they do something crazy in the root they are building,
> that's ok.

I mean that the code which will do the building will have to work around
if sysusers.d directories already exist due to some user-imposed
craziness. But well, this is a minor issue. If you are sure that this
functionality has no place in sysusers - let it be so.

-- 
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150307/690acfd7/attachment.sig>


More information about the systemd-devel mailing list