On 11 October 2015 at 14:26, Martin Pitt <mp...@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 _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
