[2019-01-11 20:35] Petter Reinholdtsen <p...@hungry.com> > [Dmitry Bogatov] > >> No objections, but note there used to be several scripts in rcS.d/ > >> depending on /usr/ being mounted, and these need to be moved from S to > >> (2 3 4 5) first. > > > > As far as I can tell, we can assume /usr being mounted (if it is > > separate from /) at time /sbin/init is launched. > > Even on diskless workstations and thin clients using LTSP? It is the > use case I know about, but it is years since I tracked its status, so I > do not know if it is still an issue there.
According to description of LTSP, it all depends on initramfs provided. So, again, if you insist that / and /usr both remote and separate, you'd have to slightly adjust your initramfs. 1. Thin-clients boot via a protocol called PXE (Pre-eXecution Environment) 2. PXE requests an IP address from a local DHCP server. 3. The DHCP server passes additional parameters to the thin-client and downloads a Linux initramfs filesystem image via TFTP into a RAM disk on the client itself. 4. The thin-client then boots the downloaded Linux initramfs image, detects hardware, and connects to the LTSP server's X session (normally handled by ldm). > > Another issue is that definition of $remote_fs is *all* file systems are > > mounted. And there is some scripts, which 'Default-Start: S', depending > > on $remote_fs. Seems to get this issue resolved, we need to get > > following list of packages to get rid of dependency on $remote_fs or > > move to (2 3 4 5) runlevels. Correct? > > I can not confirm the list, but yes, every script in rcS.d/ depending on > $remote_fs will have to move to (2 3 4 5). Traditionally (as in > Solaris/SysV systems) mounting /usr/ was done in rc[2345].d/, but this > was for some strange reason never done in Debian. I tried to move > $remote_fs there, but ran out of steem before I managed to convince > enough maintainers to do the switch. Okay. I will initate discussion on debian-devel@ in preparation of mass bug filling.