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

[Pierre Ynard]

>     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.

Thank you.

> 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?

This is the classic systemd philosophy argument that if portability
cannot be fully guaranteed, it is counterproductive and harmful and
ought to be eliminated. Then it leads to absurd, complete reversals of
how things should be, such as udev (not even original systemd software)
imposing requirements on the kernel on any system where it's pulled
in (and unlike init, there's no alternative to it). Never mind that
"support" and "fully guaranteed" are fuzzy concepts whose goal posts can
be adjusted by the authority telling us what should be done. Personally
I think it's quite a perversion of common software standards to reach a
point where portability efforts are frowned upon and discouraged.

> It may still work on some simple installs, but even that quite rapidly
> degrades as random packages get changed to simplify this away.

It degrades as random packages get pushed into alignment with the
simplified state that systemd wants to achieve, which is itself based
on eliminating "harmful" portability. Just stop that self-fulfilling
prophecy, and it will work better.

> If someone insists to pretend / vs /usr on separate fs without initramfs
> would be supported for Buster

No, I don't think anybody is aiming at "pretending" "support". I think
what people are talking about here is just not breaking stuff, just not
choosing the one option (talking about the location of two files here)
that deliberately breaks more stuff for the sake of establishing clearly
what is broken and what isn't according to a controversial ideology.
Please don't make it sound like they are pretending things that you're
shooting down.

> 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.

First, #551555 is trying to solve a real problem with supporting many
different configurations; whereas putting init files on /usr solves and
supports nothing, it just potentially breaks things.

Assuming that /usr is mounted is one way to approach #551555; but
assuming that /usr isn't on NFS, or that mountnfs.sh won't need DNS,
would also simplify things - and would be less pervasive options. That
still doesn't mean they're good ideas. Of course, the only assumption
that could already be provided by a system-wide decision from the Debian
project when you start looking at this particular problem, is the /usr
one; so the solutions are skewed, but at least there is that option.

> Two-part mount process complicates initscripts for, well, what?

Note that the proposed solution to #551555 still requires shifting many
packages from rcS.d to rc2.d. Bootstrapping /usr is still a complicated
problem if you don't know in advance which set of tools and scripts will
need to do it.

Personally, I'm not talking about a two-part mount process. My
systems boot fine with a single mount pass, and so do plenty other
rationally designed boot setups mindful of that. If you leave them easy
possibilities, users can still tweak dependencies and scripts to get
their boot sequence just right.

And if anything, booting from initramfs then pivoting to / is the
two-part process I would personally try to avoid.

>   * what are benefits of setup without initramfs *and* with separate /usr
>       partition on *fresh installation*?

This systemd opinion itself names plenty of benefits for a separate /usr:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
These benefits are what /usr merge is trying to improve, further and
complete. The ideas behind them don't really relate to initramfs or
whether the installation is fresh.

> 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.

Wrong, 256MB is quite enough for my whole separate /, not just kernel
and bootloader.

> 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.

You've mentioned one specialized use case that didn't find interest in
a separate /usr. So what, what have you proven? I've worked too on some
deployment setups that had no benefit in separate partitioning, that
doesn't mean it's pointless in every case. The reasons are diverse and
the most interesting ones to me are other than hardware size.

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

Separate /usr makes sense, and booting directly from / makes sense too,
so both together make sense.

Freedom of choice to the user also makes sense in Debian, I think. If
the "early" part is about initramfs, how about I ask you how it makes
sense that I should go through an initramfs just to cope with two rc
files moved to /usr? It makes a lot more sense to me not to use it in
the first place since I don't need it.

It's easy to dismiss anything by asking why not just use an initramfs
since it offers more flexibility with no drawbacks, so it's always
better, right? LVM, virtualization also offer more flexibility, why
don't we use those all the time too then after all?...

If you need a litany of concrete cases, separate / and /usr make
sense whenever different read-only/read-write settings, immutability
constraints, persistence capabilities, filesystem type, LVM backing or
encryption setups are desired or required.

A read-only, immutable /usr allows it to be a shared resource: think
network mount or virtualization. This can decrease by one order of
magnitude the size required from storage and memory space by each system
instance.

A read-only /usr is easy to achieve, but a shared read-only or
non-persistent / can be very complex to manage, hence the typical
separation in that sort of case.

I even run my laptop with separate read-only /usr and /home, and I
toggle write-protect during upgrades or when saving files. Write
protection is a legitimate technology feature with a long time behind
it.

If you have a big data cluster, a separate /usr, identical on all nodes
and under revision control, can be great for release management.

Even when it comes to hardware, I'm not sure your considerations about
SD card sizes hold for all embedded systems. A separate /usr could be
stored on a ROM chip, maybe using squashfs; it could operate next to a
read-write rootfs on a smaller persistent memory chip, or uncompressed
from an image to RAM, in cases where there's not enough RAM to hold the
unseparated /usr.

And if you don't want to use an initramfs but still want to use device
mapping like LVM or encryption on most of your system (at least /usr),
then separating /usr is a very workable solution.

>   * what are your arguments aganist usrmerge?

If some people want the possibility to have their /bin, /sbin and /lib
symlinked away, and can have it, with an easy tool to do it, then
all the better for them. What I'm against is possibilities getting
taken away from me in order to simplify things at the service of the
/usr merge option. Because I disagree with my choice being taken away
in favor of another choice made by a particular software suite or
philosophy that I don't use or want; and because I don't see how making
things easier by shifting stuff to /usr is a proper technical solution.

What's going to happen with this is that some people will just say
"screw this", and copy the files they need by hand, out of packaging,
back into /lib or /bin. Then other people will reply: "They're shooting
themselves in the foot, let them rot and die!" And I don't see that as
any good outcome for the community.

-- 
Pierre Ynard