[sf-lug] systemd 8-O ... ; -) Re: SF-LUG meeting notes + abt some lightweight distros

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] systemd 8-O ... ; -) Re: SF-LUG meeting notes  
> + abt some lightweight distros
> Date: Thu, 31 May 2018 17:34:55 -0700

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
> [snippity snippity snip]
>
>> But for a quite reasonable distribution (e.g. Debian :-)) that offers
>> lots of choice (Debian sure as heck does!), I'm definitely somewhere in
>> the:
>> Don't throw the baby out with the bath water!
>
> In fact, I found myself, a couple of years ago, arguing with a bunch of
> emotive anti-systemd people who kept claiming that it was outright
> impossible to use the then-Testing branch of Debian, 'Jessie', that was
> later released as Debian 8, without being 'forced' to rely on systemd.
>
> After some pointless back-and-forth, I switched tactics and proved by
> non-polemical data that the other folks were, and to my knowledge remain
> (post-Jessie) mistaken, by doing a test installation of 'Jessie' and
> then doing a dirt-simple and extremely obvious conversion to use the
> (IMO) very appealing init system 'OpenRC' -- and document that and all
> the ramifications on a Web page
> (http://linuxmafia.com/faq/Debian/openrc-conversion.html).
>
> The conversion was exactly thus:
>
> apt-get install openrc
> apt-get install sysvinit-core  #precaution, as the page explains
> reboot
>
> The page also details a couple of additional commands the admin can take
> if he/she wishes to insure that no future package dependencies will ever
> drag systemd back in -- a matter to which I'll return.  That would
> involve, in part, the 'ramifications' to which I alluded.

Yup, everything I've seen/heard/read - at least from reasonable sources,
indicates that installing Debian with other than systemd init system,
or changing its init system from systemd to some other init system
(notwithstanding some destktop environments, etc. that have gone the
way of having systemd dependencies) ... anyway, all reasonable indications
are it's pretty dang easy.

Okay, so now I'm tempted to see for myself just how dang easy it is to
install Debian without systemd.
So, let's see how many non-default things I have to do differently to do
an install using another init system rather than systemd.
Let's see ... first check relevant documentation - highly easy to
find, this seems quite suitable:
https://wiki.debian.org/systemd#Installing_without_systemd
Now I fire off an install,
booting from:
Debian GNU/Linux 9.4.0 "Stretch" - Official amd64 xfce-CD Binary-1  
20180310-11:21
... what do I have to do different to not do a systemd init install?
(and following reading what's quite clear/obvious on-screen ...):
Help
F3
installgui preseed/late_command="in-target apt-get install -y sysvinit-core"
(installgui is the default if one just presses <Enter> from the very start)

So ... that's all I did specifically do to have systemd not be the init
system.
And confirming ...
# ls -l /proc/1/exe
lrwxrwxrwx 1 root root 0 Jun  2 08:06 /proc/1/exe -> /sbin/init
$ ls -l /sbin/init
-rwxr-xr-x 1 root root 40728 Feb 12  2017 /sbin/init
$ dpkg -S /sbin/init
sysvinit-core: /sbin/init
And, ... what systemd packages are installed?
$ dpkg -l | awk 'if($1=="ii" && $2 ~ /systemd/)print $2;}'
libpam-systemd:amd64
libsystemd0:amd64
systemd
systemd-shim

$ apt-get -s --purge remove systemd
I see that would get rid of "only" ... 19 packages (we have 1368
packages installed).
So ... lets do that ...
# apt-get --purge remove systemd
Now only have 2 systemd packages left:
libsystemd0:amd64
systemd-shim
... looks trivial to remove systemd-shim, so:
# apt-get --purge remove systemd-shim
Now our only remaining systemd package is:
libsystemd0:amd64
Is it feasible to get rid of that?  I mean heck, we're already well
beyond not having systemd as our init system.  But if we want to go
further ...
$ apt-get -s --purge remove libsystemd0:amd64
$ apt-cache --installed rdepends libsystemd0:amd64
Doesn't look like we can rip that trace out.  And what is it, anyway?
Description-en: systemd utility library
  The libsystemd0 library provides interfaces to various sytemd components.

Doesn't sound too horrible, ... especially if it may mostly be a
"compatibility" layer.

Would also be good at this point, to do some configuration to reduce the
probability of accidentally bringing in systemd and/or undesired systemd
components/packages.  Among others, Rick Moen provided great information
on that:
> (http://linuxmafia.com/faq/Debian/openrc-conversion.html).
Notably Apt pinning, etc.

I do notice, going about it this particularly relatively default
method, we've got a whole lot of stuff that apt-get reports were
automatically installed by stuff we no longer have installed, and it
suggests apt autoremove to remove those ... but ... we'd likely want
many of those - at least if we want much of what we'd already installed.
So ... there would be better ways to go about installing this
(e.g. making a few more non-default selections).  So ... let's do that!
:-)

We repeat again, as before, except where we get to the
Software selections point in the install, we deselect everything
before we continue - yes that will be highly minimal ... but we'll
adjust that later.  And ... how many systemd packages does that leave
us with?  Just two:
$ dpkg -l | awk 'if($1=="ii" && $2 ~ /systemd/)print $2;}'
libsystemd0:amd64
systemd
So ... two systemd packages installed.
Looking at systemd ... nothing depending upon that presently, so:
# apt-get --purge remove systemd
That leaves only:
libsystemd0:amd64
Doesn't look like we can rip that trace out - and that's also much more
easy and clear to see in this much more minimal installed situation.

And likewise, at this point, may be highly desirable to do the bit of
Apt pinning configuration and such.

And, we can now fire up tasksel(8) to pick some large metapackages to
install if we want - it offers choices pretty similar to the
Software selection
choices in the initial installation.  Of course there are many other
ways we can chose what packages to install at this point.

And, for an even cleaner initial start ... preseed ... can we not only
have it install our non-systemd init system, but can we also have it
purge non-essential systemd bits at that same time?  Should be possible,
as apt-get can do remove/purge along with install in a single command -
just a bit of syntax adjustment.  Let's see ...
installgui preseed/late_command="in-target apt-get --purge install -y  
sysvinit-core systemd-"
... sweet that works nicely - only systemd package installed after that is:
libsystemd0:amd64
Also, at this point:
$ apt-get -s autoremove
Shows us it has nothing to autoremove.  So we should be good at this
point, probably do some Apt pinning as noted earlier, and then
add/install stuff from here and not get a bunch of stuff as autoremove
candidates that we likely actually want installed.