[systemd-devel] [PATCH 1/2] add initrd-fs.target and root-fs.target

[Tom Gundersen]

On Mar 16, 2013 10:57 AM, "Zbigniew Jędrzejewski-Szmek" <zbyszek at in.waw.pl>
wrote:
>
> On Wed, Mar 13, 2013 at 05:06:01PM +0900, Tom Gundersen wrote:
> > On Wed, Mar 13, 2013 at 3:41 AM,  <harald at redhat.com> wrote:
> > > From: Harald Hoyer <harald at redhat.com>
> > >
> > > Instead of using local-fs*.target in the initrd, use root-fs.target
for
> > > sysroot.mount and initrd-fs.target for /sysroot/usr and friends.
> > >
> > > Using local-fs.target would mean to carry over the activated
> > > local-fs.target to the isolated initrd-switch-root.target and thus in
> > > the real root. Having local-fs.target already active after
> > > deserialization causes ordering problems with the real root services
and
> > > targets.
> > >
> > > We better isolate to targets for initrd-switch-root.target, which are
> > > only available in the initrd.
> >
> > Looks good.
> >
> > This means that we should probably stop reusing units at all in the
> > initramfs. In some cases I guess it works (udev/journal), but perhaps
> > we should avoid it also there for consistency?
> >
> > In particular any storage daemons will need initrd-specific versions
> > which are ordered against these new targets rather than
> > local-fs.target. I don't see a problem with this, just something we
> > need to be aware of.
> Sorry fot the belated comment, but isn't it possible to exploit the
> fact that dependencies on non-existent unints are ignored and use
> something like:
>
> WantedBy=local-fs.target initrd-fs.target
> Before=local-fs.target initrd-fs.target
>
> which should work both in the initrd and on the real system?
>
> Zbyszek

Yes, that would work. As long as we don't mind the same unit being possibly
activated twice: once in the real root and once in the init rd. I guess in
general it would cause similar problems as what this was meant to solve?

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130316/844f14a4/attachment.html>