Bug#796603: keyboard-configuration: Has init script in runlevel S but no matching service file

Felipe Sateler fsateler at debian.org
Sun Oct 11 15:22:16 BST 2015


On 11 October 2015 at 05:18, Martin Pitt <mpitt at debian.org> wrote:
> Felipe Sateler [2015-10-10 10:59 -0300]:
>> On IRC it was pointed out that --save is not necessary under systemd:
>> /usr must always be mounted.
>
> This isn't related to systemd itself -- if you have a separate /usr,
> it will be mounted as part of local-fs.target of course, but you can't
> depend on it in services that don't depend on local-fs.target (or have
> RequiresMountsFor=/usr).

AFAICS, none of the services provided by systemd have such a
RequiresMountsFor, at the very most they have After=local-fs.target.
Which means (for example) tmpfiles will not work if /usr is remote
mounted but not on the initrd.

> This is related to initramfs-tools, which nowadays mounts /usr already
> (independent of the init system in use). I guess that's what you mean,
> but I wanted to clarify this.

Well, not exactly. This depends on the initrd, but systemd itself
still assumes /usr is available (almost) always. Unlike /var, which is
explicitly pulled in by basic.target, /usr if remote will not stop
anything from moving forward, so you might end up after sysinit with
/usr not mounted.

>
>> If /usr is actually guaranteed to be available, then we should drop
>> --save from both the init script and service file.
>
> We got bug reports against systemd from people who removed
> initramfs-tools and still have a separate /usr. If this is an use case
> (personally I don't think it is) we can't make this assumption.

I don't think we should consider that a valid use case. If we can
reduce the number of possible configurations, there is less likelihood
that things will regress. Also, removing this use case would
facilitate the move towards everything-in-usr.

-- 

Saludos,
Felipe Sateler




More information about the Pkg-systemd-maintainers mailing list