Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Adam Borowski]

On Thu, Jan 17, 2019 at 09:28:38PM +0000, Dmitry Bogatov wrote:
> > [Pierre Ynard]
> > My personal feelings here would be similar to Thorsten's, but what I
> > would put forward is that considering how critical a component of the
> > system init is, perhaps it's best to strive for robustness for now.
> 
> Wow. So strong reaction. Fine. Collegues, I understand your attitude.
> You have some setup, with separate / and /usr, without initramfs, and
> you do not want change anything.

That ship has long since sailed.  What's the point of making sysv-rc support
non-/usr early boot if the rest of the system doesn't?  It may still work on
some simple installs, but even that quite rapidly degrades as random
packages get changed to simplify this away.

>   Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
>   in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
>   mounted at /sbin/init invocation in Buster. I promise.

That's a waste of your time.  Both for and after Buster.

If someone insists to pretend / vs /usr on separate fs without initramfs
would be supported for Buster, I strongly recommend to revert that commit
for now, then move to a final position after Buster.  Any such transition is
risky, failures causing a machine to be unbootable, thus the cost of moving
twice is nasty.

> But what next? Assumption of mounted /usr simplify things.  You can take
> a look at #551555, but I do not think this is singular case. Two-part
> mount process complicates initscripts for, well, what?

I have yet to hear any use case.

> I do understand dislike of initramfs, but I do not understand why
> separate / and /usr. So,
> 
>  * what are benefits of setup without initramfs *and* with separate /usr
>    partition on *fresh installation*?

That you may hop onto a time machine with a modern install media but no
modern hardware?  I'm not aware of any widespread machines that have ~2GB of
fast local storage with the rest separate.  If there's a separate boot
media, it tends to have up to ~256MB tops, fit only for the kernel and
bootloader.  / can then sit on the same place as /usr.

Around a decade ago, Nokia installed _tiny_ boot disk and large eMMC into
N{7,8,9}00, but even then they found / vs /usr to be useless, and concocted
their own scheme.  Same happens for other setups from this millenium.

Another case: this cookie box I'm typing these words on:
https://angband.pl/tmp/rockcipa/cookies.jpg

It needs a SD card to boot before the NVME can be accessed.  You don't
really get SD cards below 16GB these days (and if you do, they're really
slow).  The whole system can comfortably fit on the SD card, but then, I
for some reason prefer /bin and /var to sit on the NVME rather than SD.

If someone could show us a case when early non-/usr boot makes sense, I'm
all ears.

>  * what are your arguments aganist usrmerge?

I'd reverse the question: what are your arguments _for_ usrmerge?  On the
lengthy flamewars on debian-devel I haven't heard any.  It moves files
around for no gain, actively breaking important things like building
packages.  Its proponents tend to conflate dropping early non-/usr boot
with symlinking /bin + /sbin + /lib.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄⠀⠀⠀⠀