:: [DNG] OFFLIST (from debian-user): N…
Inizio della pagina
Delete this message
Reply to this message
Autore: Steve Litt
Data:  
To: Zebediah C. McClure, Erwan David
CC: dng, Martin Read
Oggetto: [DNG] OFFLIST (from debian-user): No-systemd Debian
Hi all,

Martin's right: Long term, your best way to get no-systemd Debian is to
use Devuan, and Devuan's a very worthwhile community to join and
contribute to. In my opinion, Devuan got most of the smart people
actually capable of traversing the Init landscape, leaving a
technological void in the Debian community.

Join the Devuan mailing list. Get your feet wet.

But of course Devuan is alpha test software right now, and you need your
no-systemd Debian today, not in a few months when Devuan supercedes
Debian.

Systemd-free Jessie quite doable, with various combinations of the
following softwares:

* Suckless Init
* LittKit
* s6 *or* daemontools-encore
* Epoch
* runit

The preceding inits are all simple enough to have been written by one
person, and they're all simple enough for a mere mortal to understand
how they work, not just their cockpit controls. None of the preceding
requires the monstrosity init scripts required by sysvinit and OpenRC.

Erwin, you mentioned needing to get your computer booted to ssh
readiness, which I assume implies a serial tty plus sshd in the
background, from which someone can ssh log in as root (or as another
user and then su -). Which in turn requires that /etc is readable. My
first thought on that would be to boot Suckless Init, which is PID1 and
only PID1, with no package management. Suckless Init passes off control
to /bin/rc.init, which gets /etc readable, then calls
LittKit plus daemontools-encore or s6 to perform process management
tasks. The initial-running service of s6 or daemontools-encore (I'll
just say s6 to mean either from now on) makes /etc readable, runs a
serial getty and sshd.

Getting /etc readable might not be as hard as you think. I'll bet that
your initramfs, which happens *before* any stage of what we all speak
of as init, loads the drivers for encrypted partitions.

Then you come in via ssh, log in as root, and do the following LittKit
command:

lk_runsvc real_init

In the preceding, real_init is a s6 service that brings up all the
other services, in the order you want them to come up.

Zebediah, you asked "What is the correct way to work towards not
having systemd be installed by default in stretch?"

I'm almost positive that will never happen. Most of us who wanted that,
and more importantly most of us who were capable of making it happen,
have gone elsewhere: Many to Devuan. The current vestiges of Debian are
as pro-systemd as Fedora or Arch: Any mention of alternatives is
considered trolling, as you've seen in this thread.

Which doesn't mean you can't boot to an alternate init. Just go
extra-distro, sans package manager, and install the very simple init
software available. You could use Epoch as your init: That's probably
easiest, and gets rid of the most systemd baggage. Be sure to stop and
restart dbus to run it without all the systemd accoutraments. Besides
Epoch, you could use runit, s6, or s6+LittKit+SucklessInit. You have
many, many choices.

I doubt you'll get rid of every vestige of systemd. Whatever their
motivation, the fact is that the systemd people have built thick
connections to most software outside of anything traditionally thought
of as an init system, and they continue to build more of these on a
weekly basis. They've also taken over many small pieces of independent
system software, udev for example, and welded them tightly and
inextricably to systemd. And don't forget the "upstreams", who have
delightedly followed the Pied Poettering into the land of systemd.
Running Gnome without any vestiges of systemd, on Jessie, would take
hours or days of work, if it's doable at all. Xfce is now highly
connected to systemd on most distros. LXDE and Openbox are still
independent, and I hope they stay that way. But if they don't, there
are always dwm, jwm, and several others who have absolutely no desire
to unite with "big software".

When using any of the simpler inits that I suggest, use /bin/bash as a
periscope. For instance, if you set init=/bin/bash within grub or lilo,
you'll see the system exactly as your initramfs leaves it. You can see
whether /etc is readable. You can see which mounts are in effect, and
whether they're read-write. As you get earlier parts of init to work
the way you want, you can drop to /bin/bash later, until you get the
whole thing running. Is it easy? No. But once you're done, you'll know
exactly how your system boots up, and you'll be able to exactly govern
your bootup. And in init discussions like the one currently going on
Debian-User, you'll be the smartest person in the room.

I'd recommend doing your first init experimentation on a Virtual Machine
(VM), because reboot cycles are much quicker, you can back up in
minutes, and you can incrementally improve. Later, when everything works
on a VM, load it on bare metal and get that to work.


Here are URLs for some of the software I've mentioned:

Suckless Init: https://duckduckgo.com/?q=suckless+init

LittKit: http://troubleshooters.com/projects/littkit/

daemontools-encore: http://untroubled.org/daemontools-encore/

s6: http://www.skarnet.org/software/s6/

runit: http://smarden.org/runit/

Epoch: http://universe2.us/epoch.html

And here are a couple links with guidance for alternative inits:

Manjaro experiments:
http://www.troubleshooters.com/linux/init/manjaro_experiments.htm

Suckless Init plus daemontools-encore:
http://www.troubleshooters.com/linux/diy/suckless_init_on_plop.htm

The material from the preceding two links sounds difficult, but the
thing is, once you've mastered it, you understand, to the bottom of
your soul, what init is and does, and you understand exactly how to
start up your computer exactly your way.

And please remember, Devuan gets closer to production quality every
day. Someday you won't have to jump through these hoops.

HTH,

SteveT

Steve Litt
June 2015 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key