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

[Felipe Sateler]

On 11 October 2015 at 14:26, Martin Pitt <mpitt at debian.org> wrote:
> Hey Felipe,
>
> Felipe Sateler [2015-10-11 11:22 -0300]:
>> > 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.
>
> Right. Sorry, I didn't intend to say that we should actually add this,
> just the conditions under which one can assume /usr.
>
> Nothing in sysinit.target (or rcS) ought to assume /usr, and
> everything after sysinit.target (or, more precisely, local-fs.target)
> can already assume it -- that's why we rarely have an explicit
> RequiresMountsFor=/usr.

Ah, but you can't. If /usr is remote, it won't be pulled in by
local-fs.target. And because basic.target does not add /usr to the
RequiresMountsFor=, it means that stuff with DefaultDependencies=yes
could be started without having /usr mounted.

>
>> Well, not exactly. This depends on the initrd, but systemd itself
>> still assumes /usr is available (almost) always.
>
> Where else?

Unless systemd is adding some implicit dependencies, systemd-binfmt
and systemd-modules-load are also affected by this problem.

> We've got a fair number of bug reports when we introduced
> new libraries which were only in /usr, so I take it a lot of people
> actually test it in that configuration. And even people who don't run
> with an initramfs, so I take it in most cases this actually
> (surprisingly!) works.

Surprising, indeed. But I guess the configuration most likely to fail
(remote /usr not mounted in initrd) is not so tested.

>
>> > 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.
>
> Full ack. In Debian we have a tendency to support every weird corner
> configuration for eternity just because it accidentally happened to
> work once. :-/ But combinatorial explosion, as you say.

Yes, I guess that is true :( Usually proposing such changes leads to a
lot of flak.

-- 

Saludos,
Felipe Sateler