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

Sat Jun 2 14:07:31 PDT 2018

you ROCK michael...
thank you...

message ends.
___________________

On Sat, Jun 2, 2018 at 9:54 AM, Michael Paoli <
Michael.Paoli at cal.berkeley.edu> wrote:

> 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.
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> Related Information <br>
> http://www.shallowsky.com/blog/<br>
> http://explainshell.com/ <br>
>

-- 

*~the quieter you become, the more you are able to hear...*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20180602/8e0a3d08/attachment-0001.html>