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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Pierre Ynard-2
Hello, and thanks a lot for your work on the sysvinit package!

>    * Move /etc/init.d/{rc,rcS} scripts out of /etc, retaining
>      symbolic link for compatibility (Closes: #132542)

https://salsa.debian.org/debian/sysvinit/commit/0766e7195229ee5563bc4ff3b6bf0a4b350c780d

> +debian/src/sysv-rc/rc  /usr/libexec/sysvinit
> +debian/src/sysv-rc/rcS /usr/libexec/sysvinit

You've moved them to /usr/libexec/ that doesn't exist on Debian, not
/lib/init/ ?...

--
Pierre Ynard

Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
On Sun, 13 Jan 2019, Pierre Ynard wrote:

> You've moved them to /usr/libexec/ that doesn't exist on Debian, not
> /lib/init/ ?...

/usr/libexec/ is now allowed on Debian, but anything under /usr
does not seem to be the right place for things used by init,
unless these are late enough that /usr is always mounted when
they are used.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Bogatov-3
In reply to this post by Pierre Ynard-2

[2019-01-13 08:31] Pierre Ynard <[hidden email]>
> Hello, and thanks a lot for your work on the sysvinit package!

I am happy to know, that this work is important not only to me.

> >    * Move /etc/init.d/{rc,rcS} scripts out of /etc, retaining
> >      symbolic link for compatibility (Closes: #132542)
>
> https://salsa.debian.org/debian/sysvinit/commit/0766e7195229ee5563bc4ff3b6bf0a4b350c780d
>
> > +debian/src/sysv-rc/rc  /usr/libexec/sysvinit
> > +debian/src/sysv-rc/rcS /usr/libexec/sysvinit
>
> You've moved them to /usr/libexec/ that doesn't exist on Debian, not
> /lib/init/ ?...

Luckily, it does exists. Since recent Debian Policy (4.1.5?), Debian at
last adopted FHS-3.0, which have /usr/libexec:

        $ dpkg -L debian-policy
        [...]
        /usr/share/doc/debian-policy/fhs
        /usr/share/doc/debian-policy/fhs/fhs-3.0.html
        /usr/share/doc/debian-policy/fhs/fhs-3.0.pdf.gz
        /usr/share/doc/debian-policy/fhs/fhs-3.0.txt.gz
        [...]

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Bogatov-3
In reply to this post by Thorsten Glaser-6

[2019-01-13 17:10] Thorsten Glaser <[hidden email]>
> On Sun, 13 Jan 2019, Pierre Ynard wrote:
>
> > You've moved them to /usr/libexec/ that doesn't exist on Debian, not
> > /lib/init/ ?...
>
> /usr/libexec/ is now allowed on Debian, but anything under /usr
> does not seem to be the right place for things used by init,
> unless these are late enough that /usr is always mounted when
> they are used.

As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 2014):

        * Mount /usr if present in the /etc/fstab on the mounted rootfs
          (Closes: #652459)

Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
On Tue, 15 Jan 2019, Dmitry Bogatov wrote:

> As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 2014):

The latter is okay for systems booted with initramfs. But I
recall that it was decided some not too long time ago that
people not using it should ensure their /usr is available
by themselves.

I do not agree with usrmerge, and I fully expect to be able
to use Debian without that systemd-originating concept.

But I agree it’s “probably” late enough, although nice to
be considerate to people whose systems aren’t.

Reply | Threaded
Open this post in threaded view
|

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

KatolaZ-3
On Tue, Jan 15, 2019 at 05:35:46PM +0100, Thorsten Glaser wrote:

> On Tue, 15 Jan 2019, Dmitry Bogatov wrote:
>
> > As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> > coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 2014):
>
> The latter is okay for systems booted with initramfs. But I
> recall that it was decided some not too long time ago that
> people not using it should ensure their /usr is available
> by themselves.
>
> I do not agree with usrmerge, and I fully expect to be able
> to use Debian without that systemd-originating concept.
>
> But I agree it’s “probably” late enough, although nice to
> be considerate to people whose systems aren’t.
>
I would second Thorsten's remark. Let's avoid to be harsh, if there is
no reason about it.

My2Cents

KatolaZ

--
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ]
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Pierre Ynard-2
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.

Also, what is the policy about /usr/libexec/ regarding
architecture-dependent and -independent executables?

--
Pierre Ynard

Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
On Thu, 17 Jan 2019, Pierre Ynard wrote:

> Also, what is the policy about /usr/libexec/ regarding
> architecture-dependent and -independent executables?

We can use multiarch subdirectories, the same as in /usr/lib/,
for example /usr/libexec/x86_64-linux-gnux32/ for x32. That
was announced when Policy changed.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Bogatov-3
In reply to this post by Thorsten Glaser-6

[2019-01-15 17:35] Thorsten Glaser <[hidden email]>

> On Tue, 15 Jan 2019, Dmitry Bogatov wrote:
>
> > As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> > coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 2014):
>
> The latter is okay for systems booted with initramfs. But I
> recall that it was decided some not too long time ago that
> people not using it should ensure their /usr is available
> by themselves.
>
> I do not agree with usrmerge, and I fully expect to be able
> to use Debian without that systemd-originating concept.
>
> But I agree it’s “probably” late enough, although nice to be
> considerate to people whose systems aren’t.

> [Pierre Ynard]
> Also, what is the policy about /usr/libexec/ regarding
> architecture-dependent and -independent executables?

FHS uses term "binaries". I believe scripts qualify too, since /lib is
explicitly for "shared libraries and kernel modules".  Installation of
{rc, rcS} into either /lib or /etc is violation of FHS.

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

  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.

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 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*?
 * what are your arguments aganist usrmerge?

PS. No offense intended to anybody. Sorry, if my previous emails felt
rude.

Reply | Threaded
Open this post in threaded view
|

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

Adam Borowski-3
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.
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

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

KatolaZ-3
In reply to this post by Dmitry Bogatov-3
On Thu, Jan 17, 2019 at 09:28:38PM +0000, Dmitry Bogatov wrote:

>
> [2019-01-15 17:35] Thorsten Glaser <[hidden email]>
> > On Tue, 15 Jan 2019, Dmitry Bogatov wrote:
> >
> > > As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> > > coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 2014):
> >
> > The latter is okay for systems booted with initramfs. But I
> > recall that it was decided some not too long time ago that
> > people not using it should ensure their /usr is available
> > by themselves.
> >
> > I do not agree with usrmerge, and I fully expect to be able
> > to use Debian without that systemd-originating concept.
> >
> > But I agree it’s “probably” late enough, although nice to be
> > considerate to people whose systems aren’t.
>
> > [Pierre Ynard]
> > Also, what is the policy about /usr/libexec/ regarding
> > architecture-dependent and -independent executables?
>
> FHS uses term "binaries". I believe scripts qualify too, since /lib is
> explicitly for "shared libraries and kernel modules".  Installation of
> {rc, rcS} into either /lib or /etc is violation of FHS.
>
> > [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.
>
>   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.
>
> 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 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*?
>  * what are your arguments aganist usrmerge?
>
> PS. No offense intended to anybody. Sorry, if my previous emails felt
> rude.
>
I don't think this is the place to discuss the pros and cons of
separate / and /usr, TBH. And at this point in time is not even so
straightforward to "assume a mounted /usr", IMHO.

If we cannot put the script under /lib/init, let's leave it under
/etc/init.d, or, maybe better, let's put it under /bin, and link it
from /etc/init.d. After all, it's an executable that is needed at boot
time, so having it under /bin looks totally right, and linking it from
/etc/init.d helps avoiding unexpected breakages upon upgrades.

My2Cents

KatolaZ

--
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ]
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
On Fri, 18 Jan 2019, KatolaZ wrote:

> > FHS uses term "binaries". I believe scripts qualify too, since /lib is

I believe that s/binaries/executables/ applied to FHS helps interpreting.

> >  * what are your arguments aganist usrmerge?

Please let’s not go there. Just accept that this idea, originating
from the systemd people at Fedora/Freedesktop, is NOT welcome to
classical Unix people.

> /etc/init.d, or, maybe better, let's put it under /bin, and link it

No, not /bin. If it must be in one of these, /sbin would apply,
but I’d personally say /lib/init/ is a good place except if the
local administrator is supposed to change them.

> from /etc/init.d. After all, it's an executable that is needed at boot
> time, so having it under /bin looks totally right, and linking it from

/bin is also supposed to be in the normal user’s path. libexec
sounds the most right, but AIUI we don’t have that under / and
for just two more files, /lib/init/ (which already exists and
contains stuff needed for initscripts) does the job just fine.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Reply | Threaded
Open this post in threaded view
|

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

Pierre Ynard-2
In reply to this post by Adam Borowski-3
>     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

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Bogatov-3
In reply to this post by Thorsten Glaser-6

[2019-01-18 14:32] Thorsten Glaser <[hidden email]>
>  * what are your arguments aganist usrmerge?
>
> Please let’s not go there. Just accept that this idea, originating
> from the systemd people at Fedora/Freedesktop, is NOT welcome to
> classical Unix people.

Adam correctly pointed in his email, that usrmerge is off the topic.
I will not go there.

But you did not answer real question -- what are benefits of separate /
and /usr without initramfs? As I already mentioned, two-stage mount
complicates things. For what?

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Bogatov-3
In reply to this post by Adam Borowski-3

[2019-01-18 02:20] Adam Borowski <[hidden email]>
> > 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.

The same argument could be applied to many other things: systemd,
web-2.0, html emails, MS Office, GitLab/Hub. Still, I use runit init
system, text browser, text mail client and still send patches via
git-send-email.

I object when someone appears and try break my beautiful little
paradise.  And I definitely do not want to come and break someone's
else.

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

That is being responsible to my users. I do not consider it waste.

> >  * what are your arguments aganist usrmerge?
> I'd reverse the question: what are your arguments _for_ usrmerge?
> Its proponents tend to conflate dropping early non-/usr boot
> with symlinking /bin + /sbin + /lib.

If we dismiss two-stage mount (ship sailed, as you claim), having two
separate locations for binaries is not logical.  If you want to discuss
usrmerge further, please move to another list (or, if you wish, send in
private).

But, as you correctly mentioned, we are discussing early non-/usr boot
here.

Reply | Threaded
Open this post in threaded view
|

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

KatolaZ-3
In reply to this post by Dmitry Bogatov-3
On Sat, Jan 19, 2019 at 07:34:25PM +0000, Dmitry Bogatov wrote:

>
> [2019-01-18 14:32] Thorsten Glaser <[hidden email]>
> >  * what are your arguments aganist usrmerge?
> >
> > Please let’s not go there. Just accept that this idea, originating
> > from the systemd people at Fedora/Freedesktop, is NOT welcome to
> > classical Unix people.
>
> Adam correctly pointed in his email, that usrmerge is off the topic.
> I will not go there.
>
> But you did not answer real question -- what are benefits of separate /
> and /usr without initramfs? As I already mentioned, two-stage mount
> complicates things. For what?
Since you decided to go there: what are the benefits of forbidding it,
if any? I know it is currently not supported in Debian, but so far
sysadmins have the possibility of getting it to work, if they like,
and with relatively little effort. If we keep pushing more and more
stuff under /usr for no reason except the (quite feeble) ones
purported so far in debian-devel, we will make the prophecy become
automatically true.

There is no reason to make the life of "unaligned" sysadmins any
harder than it is now. The fact that you can't see a use case does not
mean that you should do anything in your power to make it impossible.

My2Cents

KatolaZ

--
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ]
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Adam Borowski-3
In reply to this post by Dmitry Bogatov-3
On Sat, Jan 19, 2019 at 07:34:26PM +0000, Dmitry Bogatov wrote:

> [2019-01-18 02:20] Adam Borowski <[hidden email]>
> > 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.
>
> The same argument could be applied to many other things: systemd,
> web-2.0, html emails, MS Office, GitLab/Hub. Still, I use runit init
> system, text browser, text mail client and still send patches via
> git-send-email.
>
> I object when someone appears and try break my beautiful little
> paradise.  And I definitely do not want to come and break someone's
> else.

That's not what my argument is -- what I mean, is that there's many more
components that need to stick strictly to files not on /usr during that
phase of the boot, sysv-rc being only a single one.  Efforts to keep it
working are a waste of time, not because you won't get to simplify things,
but because you would need to override a number of other maintainers.

Simple setups still work in Buster, but it's easy to run into something that
doesn't.  That'd be a nasty surprise for the user, thus it's better to make
the break faster and more obvious.  Then, pretty surely even such simple
setups won't work in Bullseye.

> > >   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.
>
> That is being responsible to my users. I do not consider it waste.

There's a cost to migrations like this: any move may break stuff.  For
example, it breaks that silly little init I used to have in my .sig (and
included in this mail), but people may refer to that file for reasons other
than mere fun.

There's an easy way for Buster: just drop the move, it serves no need.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start
⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax
⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child:
⠈⠳⣄⠀⠀⠀⠀ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall

Reply | Threaded
Open this post in threaded view
|

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

Pierre Ynard-2
> That's not what my argument is -- what I mean, is that there's many
> more components that need to stick strictly to files not on /usr
> during that phase of the boot, sysv-rc being only a single one.
> Efforts to keep it working are a waste of time, not because you won't
> get to simplify things, but because you would need to override a
> number of other maintainers.

No. I think what you're saying is backwards. My opinion is that what
really creates a waste of time, is all the maintainers and packages
launching a deliberate effort to shift files around to serve the /usr
merge cause. Just don't break it in the first place, and then there will
be no waste of time trying to keep it unbroken.

Also, sysv-rc is not "only a single" component, it's a critical MAJOR
boot component.

> Simple setups still work in Buster, but it's easy to run into
> something that doesn't. That'd be a nasty surprise for the user, thus
> it's better to make the break faster and more obvious.

Oh, so you're explaining that a situation falling short of ideal is
nasty, and also breaking things is good, especially breaking things for
the sake of clearly driving the point that they're broken.

What was I saying earlier again?

> This is the classic systemd philosophy argument that if portability
> cannot be fully guaranteed, it is counterproductive and harmful and
> ought to be eliminated.

> Personally I think it's quite a perversion of common software
> standards to reach a point where portability efforts are frowned upon
> and discouraged.

> Just stop that self-fulfilling prophecy, and it will work better.

> just not choosing the one option that deliberately breaks more stuff
> for the sake of establishing clearly what is broken and what isn't
> according to a controversial ideology.

I rest my case. Clearly we have very different opinions about software
development standards and responsibility for your work and to your
users. I just hope Debian will continue to uphold the values for which
I've been with it.

> Then, pretty surely even such simple setups won't work in Bullseye.

Does that mean that there are already plans to expand for Bullseye the
scope and clarity of that breakage ideology?

> There's a cost to migrations like this: any move may break stuff.
> There's an easy way for Buster: just drop the move, it serves no need.

The files have already been moved again to /lib/init. Is there an
assumption that they will have to be moved again away from /lib after
Buster?

Once again, simple setups, or any kind of setup still working is good.
Freedom and possibilities for the users to tweak their software into
what they choose, and to fix and improve their software to suit their
needs, is good. Please don't say things that feel as if users and use
cases that don't conform to a given ideology are better off rooted out.

--
Pierre Ynard

Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
In reply to this post by KatolaZ-3
On Sat, 19 Jan 2019, KatolaZ wrote:

> > But you did not answer real question -- what are benefits of separate /
> > and /usr without initramfs? As I already mentioned, two-stage mount
> > complicates things. For what?
>
> Since you decided to go there: what are the benefits of forbidding it,

Exactly.

The split /usr is, as I said, not a setup I’d run myself, but I can
see people using it, especially on machines upgraded from, say, slink.
Running without initramfs also has its uses. Remember that Debian
is not just used “out of the box” on a desktop, but also in highly
specialised embedded appliances upgraded once in a full moon (perhaps
more often with security fixes, one would hope), in remote locations
(which means upgrading must not fail as nobody has local access to
the hardware), and with historical constraints on system layout.

I mean, look at this:

-rw-r--r-- 1 root root 29197586 Jan 10 17:51 initrd.img-4.19.0-1-amd64
-rw-r--r-- 1 root root  5172512 Dez 30 10:04 vmlinuz-4.19.0-1-amd64

That’s bordering on insane, size-wise.

> if any? I know it is currently not supported in Debian, but so far
> sysadmins have the possibility of getting it to work, if they like,
> and with relatively little effort. If we keep pushing more and more

Exactly that. While it is not “officially” supported “out of the box”
we should not take that as a licence to make it more and more diffi‐
cult for those that *did* the extra step of letting it work in their
specific scenarios.

The pro-initramfs arguments are plug and play hardware, dynamic de‐
vice numbers, etc. but these often don’t apply to embedded appliances
(which is why I postulated that, on *some* systems, split /usr with‐
out initramfs MIGHT even work out-of-the-box on Debian… modulo the
kernel configuration, of course, but while I’m not running a custom
kernel on Debian, many do).

Thanks,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
In reply to this post by Pierre Ynard-2
On Sat, 19 Jan 2019, Pierre Ynard wrote:

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

Nah, dpkg-divert is the right tool for that.

.oO(did I just confirm that “some people” exist? oops…)

bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

12