teg at jklm.no
Mon Mar 4 21:26:41 PST 2013
On Tue, Mar 5, 2013 at 4:09 AM, Harald Hoyer <harald.hoyer at gmail.com> wrote:
> please review
Could you comment on why this is necessary? It would be nice if we
could reuse as much as possible from the real root rather than making
initrd-spcific files, but perhaps it is not possible in this case?
I am aware of one problem that your patch solves (at least for this
When we switch root we use JOB_REPLACE to default.target. This means
that units which are pulled in by default.target, but already active
in the initrd (such as local-fs.target) will not be pulled in again,
so if they get new dependencies (in this case the entries from the
real /etc/fstab) these are not started. I was going to suggest solving
this by using JOB_ISOLATE when switching root, but didn't yet have the
chance to check if this causes any problems. Did you consider this, or
did you have a different reason for the patch?
The new target references the systemd.special manpag, but does not update it.
Why is it necessary to "start" initrd-fs.target in addition to Require it?
Hm, wouldn't this mean that any other storage related service we might
want to include in the initrd would have to be special-cased to deal
with initrd-fs rather than local-fs?
Why do you need the 'skip generation of sysroot.mount if exists'
logic? Shouldn't we just generate it in the correct generator
I think you changed the priority order of /proc/cmdline, /etc/fstab
and /sysroot/etc/fstab, could you comment on why it is the way it is?
I think /sysroot/etc/fstab should have the highest priority, as that
what will be used to remount the filesystems in the real root (I have
patches to do the remounting in the initrd to avoid doing any mounting
twice, but that's a separate issue), and that /etc/fstab should have
the lowest as it has to be set at initrd generation time. What do you
More information about the systemd-devel