Removing Systemd from Debian (and still running a desktop)

Copyright (C) 2015 Luke Kenneth Casson Leighton
Created: 15 Feb 2015
Edited: 17 Feb 2015

Update 17Feb2005: nosystemd repository already available.

    It's come to my attention, and I am delighted to be able to inform
    people who may be concerned about the non-maintainability of the
    hacks outlined in this report, that there is already a debian
    developer who has provided easy-to-install packages that achieve
    the exact same effect, and, furthermore, that the same developer
    has also packaged up openrc.  More information is available here:

    * https://lists.debian.org/debian-devel/2015/02/msg00189.html
    * http://forums.debian.net/viewtopic.php?f=20&t=119836
    
    For people wishing to simply have all presence of systemd removed,
    the following may be added to /etc/apt/sources.list, and an
    upgrade performed:

        deb http://angband.pl/debian/ nosystemd main

    Honestly, it is fantastic and a great relief to see this document
    rendered redundant within 48 hours.  The next phases are to make
    Adam's work more widely known as an interim stop-gap measure, and
    after that to advocate the ideas raised both by Adam and Russ
    on debian-devel recently, namely to ensure that libsystemd0 is
    dynamically-loaded and its use (and all its dependencies) made
    entirely optional through run-time detection instead of the current
    all-or-nothing compile-time switches that are causing such immense
    amounts of friction in the Software Libre world, today.


Update 15Feb2015, 20:30hrs: SUCCESS!

    root@bigmac:~# apt-get remove libsystemd0
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages will be REMOVED:
      libsystemd0
    0 upgraded, 0 newly installed, 1 to remove and 1257 not upgraded.
    After this operation, 183 kB disk space will be freed.
    Do you want to continue? [Y/n] y
    (Reading database ... 225653 files and directories currently installed.)
    Removing libsystemd0:amd64 (215-11) ...
    root@bigmac:~# 


Update 15Feb2015, 23:00hrs

We have one success report which did not require the modifications below
to disable udev.  If replicable this would be far preferable, as disabling
udev is quite disruptive.


Introduction

This is a work-in-progress report on getting a functional Debian GNU/Linux
system that does not have systemd or any systemd libraries installed, yet
(with some inconvenience) is still functional.  The process is not without
risk, may require (required, as of 5am on 14th Feb 2015) some recovery
procedures, and will almost certainly require ongoing maintenance that may be
unattractive for some users.  The recovery procedures utilised are also
documented.

PLEASE NOTE: In reading this document, you agree implicity to accept full
and total responsibility for your own actions and decisions.  If you are
not prepared to take responsibility for your own life, please cease and
desist from reading this web site immediately, go away, and take up some
high adrenaline sport that helps you to grow some balls before considering
returning.

Summary of the process so far (not recommended):

* Install systemd-shim and sysvinit-core (these were already present)
* Download dbus, pulseaudio, policykit-1 and util-linux with apt sources
* Edit all debian/rules, debian/control and debian/*.install files
* Remove all mention of systemd
* Recompile all packages and install them
* Boot system into non-functional state due to udev not working
* Download daily hdmedia vmlinuz and initrd.gz for recovery purposes
* Recover non-bootable system through manual grub loading of vmlinuz
* Mount partitions manually and mv /etc/init.d/udev to /etc/init.d/udev.no
* Copy recovery initrd /dev entries to main partition temporarily
* Use lsmod in recovery mode to obtain list of loaded modules
* Add list of loaded modules to /etc/modules
* Reboot into a semi-working system with at least a command prompt
* Install the makedev package and run it manually
* Edit /etc/X11/xorg.conf to no longer use automatic module detection
* Further edit /etc/X11/xorg.conf to provide manual evdev sections

From this process a lot was learned that may aid others in avoiding the
(severe) inconvenience of ending up with a system that literally could
not even detect the existence of a keyboard.

Further work is required due to multiarch installation of both i386
as well as amd64 packages.  This will require following the build
process twice, the second time in an i386 debootstrapped chroot.
[update: instead of recompiling, the packages that were only available
for i386 were successfully installed in the schroot, and the i386
multiarch packages in the main system removed entirely]

IMPORTANT

First, some important caveats:

If the above scary list is not enough, it has to be spelled out that
this procedure is NOT for people who are unwilling to do
a lot of work and potentially risk losing absolutely everything.

PLEASE NOTE that the only reason why it was practical to consider this
process is because the author runs fvwm2, and manually starts Xorg sessions.
Gnome is not installed.  KDE (not even Trinity Desktop) is not installed.
If you have ANY applications that critically depend on libsystemd0
(which at the time of writing is quite a long list that may be investigated
using "apt-cache rdepends libsystemd0" and includes erlang-base, network-manager
libvirt0, syslog-ng-core, gvfs and many more), they will either need to
be patched and recompiled or REMOVED ENTIRELY.  The author has removed
udisk2, cups-daemon, acpi-fakekey, sane-utils and many more (as they are not
needed).  You may need, instead of removal, to follow the procedures below
and adapt them to modify any packages - entirely at your own risk.

PLEASE ALSO NOTE that the process by which the packages were
patched and recompiled is less than ideal, will require constant updating,
monitoring and maintenance, but is actually functional

Install sysvinit and systemd-shim

Although this is not precisely what has been done (because the system on which
systemd is being removed has beeen continuously apt-get upgraded since 2005),
there are some instructions here on making sure that sysvinit remains active:

* http://people.skolelinux.org/pere/blog/How_to_stay_with_sysvinit_in_Debian_Jessie.html
* http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation

In the instructions to remove systemd, only install sysvinit but do not
(yet) follow the removal of systemd itself.  You need to prepare the packages
below by removing the dependency on systemd and libsystemd0 (so that they are
not removed), then you can finish off by removing systemd.

You should double-check that your system boots successfully using sysvinit
before proceeding further.

Download debian packages to be manually edited

Before following these instructions please do some research on how to
build debian packages.  The instructions below are a quick summary and
reminder only.

First edit /etc/apt/sources.list and ensure that there are appropriate
entries for deb-src.  Follow up with an "apt-get update" and, if this
is a new system or is one on which you have never compiled debian packages
before, do "apt-get build-essential".

Second, do "apt-get source util-linux pulseaudio dbus policykit-1" followed
by "apt-get build-dep" on the same package list.

Thirdly, download the following patch and apply it with patch -p0.
Its primary purpose is to remove both indicating that systemd and libsystemd0
are dependencies, as well as compiling up the libraries and packages with
systemd support entirely disabled.  Lastly, additional modifications are
made so that the files which are no longer present are not attempted to
be added to the debian package (as this causes the package build to fail).

Update 15Feb2015 20:30hrs - it has been noted that pulseaudio debian/control
still contains mention of libsystemd.  Whilst waiting for a patch update
please edit pulseaudio-5.0/debian/control and remove the two mentions
of libsystemd dev packages manually.

Building the packages

Each of the packages may be recompiled by a cd into to the appropriate
subdirectory, and issuing the command "dpkg-buildpackage -rfakeroot -nc".
The build should not be done as root.

Preparing in case of recovery boot

The reason why this procedure was utilised instead of booting from a
CDROM is because, firstly, the procedure was carried out on a UEFI-bootable
macbook pro, and secondly, these files are, really, all that is needed to
boot and recover a system.

Download the initrd and vmlinux files from the following location:
Debian installer hd-media on ftp.debian.org
If using an i386 system rather than amd64, that location will be different.

Copy the two files to a FAT-formatted partition on removable USB media.

Double-checking that recovery boot works

This should be done before anything else (any modifications are made).
Reboot your system with the removable media inserted, and interrupt the
grub boot loader process.  Start a grub prompt (read and follow on-screen
instructions).

Next, run "insmod part_msdos".  Now comes a bit of exploration, using
ls to find out what drive grub thinks the removable media is.  type "ls",
press space, then a left bracket, then type "hd" and press the tab key.
A set of drives (hd0) (hd1) and possibly (hd2) and more if you have more
drives will be listed.  Start by pressing "0" then press tab: you are
looking for tab-completion to list available msdos partitions: if there
is only one on the removable media then you are likely to end up with this:

    ls (hd0,msdos1)

If that is the case, press return and check to see if vmlinuz and initrd.gz
are listed.  If they are not, continue to search for the appropriate
drive and partition.

Once found, type the following commands (adjust accordingly):

    linux (hd0,msdos1)/vmlinuz
    initrd (hd0,msdos1)/initrd.gz
    boot

You should now end up in the standard debian install, which you are not
going to do.  Set up a keyboard and stop there, then press Alt-F2.  You should
see a message "Press Return to activate a console".  Do exactly that.

You should now be able to mount partitions, depending on the complexity of
the setup that you have.  If you are not using lvm, this should be very
straightforward.  If you are using lvm, or RAID, or cryptsetup, then this
(oversimplistic) recovery procedure is not for you.  You probably already
have one that you prefer to use, but check that it works.

Preparation: removing dependency on udev from Xorg

Xorg now depends on udev auto-detection, which firstly needs to be disabled
and secondly the older method of adding Keyboard0 and Mouse0 entries needs
to be done (and tested).  This can be either set up before proceeding
or it can be done afterwards.  Given that there is no option for returning
to using udev after this procedure is activated it may be preferable to
set it up in advance.

The key entry in /etc/X11/xorg.conf that is needed is:

    Section "ServerFlags"
        Option "AutoAddDevices" "false"
    EndSection

This will disable the use of udev to detect devices.  As this autodetection
disables the mouse and kbd devices it is important to sort this out, else
Xorg will be started with no input devices at all.  The only way to
recover such a system is to ssh in and kill off X, or to reboot it
(assuming that X is not auto-starting).

Second you will need to research how to add appropriate screen and keyboard
entries to xorg.conf.  These sections are what is being used:

    Section "ServerLayout"
        Identifier     "X.org Configured"
        Screen      0  "Screen0" 0 0
        InputDevice    "Mouse0" "CorePointer"
        InputDevice    "Keyboard0" "CoreKeyboard"
    EndSection

    Section "Module"
        Load  "glx"
    EndSection

    Section "InputDevice"
        Identifier  "Keyboard0"
        Driver      "evdev"
        Option "Device" "/dev/input/event7"
    EndSection

    Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "auto"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5 6 7"
    EndSection

However what you require will vary.  You should research it in advance.
For example, even with auto-detection disabled, the kbd Driver was found not
to work.  The alternative method was to manually track down which entry
in /dev/input was the keyboard (by ssh'ing in remotely, and doing
hexdump /dev/input/eventN in turn then pressing keys on the local keyboard).

Update: here is a trick which helps identify the
input devices by walking through them and reporting the names listed
from /sys

If you have synaptics trackpads, you will need to research how to add these.
If you have a wacom tablet, you will need to research how to add it.  Everything
that you previously relied on auto-detection, you will now have to go back
to the method that was prevalent in the past: manual entries in xorg.conf.
The internet is your friend, here.

Preparation: install makedev, set up modules, take backups....

First most obvious thing: take a backup (if you need one).  If you have a
second system where the hard drive may be removed from the primary, test
that everything works beforehand by actually removing the hard drive and
putting it into the secondary.  Note: In the case of a macbook pro, however,
as it uses non-removable on-board NAND Flash, removing the drive is
impossible.  Under these circumstances you should prepare alternative
data recovery methods.

Second, install makedev with "apt-get install makedev".  It will not
activate (yet) however it will be needed later.

Thirdly, issue a "lsmod" command (consider outputting the results to a file)
then add every single module listed to /etc/modules (Note: there are probably
better, simpler, less manually-intensive ways to do this).  Bear in mind
that you should install (plug in) everything that you are going to need
in the future.

Fourthly, install systemd-shim with "apt-get install systemd-shim".

Fifthly, rename /etc/init.d/udev to /etc/init.d/udev.no

Sixthly, make a backup of the /dev/* directory structure created by
udev.  Bear in mind that makedev creates an absolutely basic structure,
and that when udev is no longer active, the changes that it applies
to nodes (permissions, ownership and group ownership) are no longer done.
So it is best to take a snapshot as you will need to manually copy it
to /dev, later.  Use cp -aux /dev /root/backup_of_dev

Seventhly, take a backup of the current known-good kernel and initial
ramdisk in /boot.  You may need them later, not least because the installation
of the recompiled packages will regenerate a systemd-unaware initial ramdisk
with insufficient modules added to even recognise the keyboard during the
boot process.

At this point you may wish to test that the system may still boot, but
bear in mind that Xorg is unlikely to work, and that if it goes wrong
you will quite possibly not even have access to a keyboard, let alone
internet access.  If you have a secondary system where internet etc. is
available, consider firing it up, check that it works, and use that to
read these (and other) instructions.

Installing the modified packages

In the directory which contains the source packages (where the apt-get source
command was issued) the build process will have created a long list of
deb packages.  You need to identify which of those you actually need.
Using "dpkg -l" | grep {packagename} is a good way.  For example, in
recompiling the pulseaudio package it created approximately 15 packages,
only 6 of which were actually installed.  You need to check what
you do and do not need.  You do not need - and should not attempt to install -
any udeb packages that have been created (it is best to delete these).

Note: some of these packages have dependencies that will need to be fixed.
You should research how to do that, in advance, and have access to a secondary
system in order to do so.  DO NOT attempt to reboot your system
until this manual process is completed.

As multiarch i386 and amd64 packages happened to have been installed
on the machine on which libsystem0 is being removed, it was found in some
cases to be necessary to apt-get install the i386 equivalent packages
prior to dpkg being happy with the amd64 .deb equivalents.  So, some
dbus i386 packages were installed for example (apt-get install libdbus-1:i386)
and a few other dependencies were brought up-to-date.  As the installation
of these packages was within a few minutes of the build (and a second
apt-get update was not done in between) it was guaranteed that the version
of the i386 binary package from debian was exactly the same as the
locally source-compiled amd64 package.  This is critical to have.

Finally, once all manually-rebuilt packages are installed, it is worthwhile
double-checking by issuing "apt-get -f install".  This should do nothing.

Reboot

If you have followed the preparation above, rebooting should actually work.
Regardless of what you did, and regardless of the state that your system is
now in, you are entirely on your own.  You agreed to take responsibility for
your own life, so you will not be contacting me to blame me for what happened.

That having been said, if you find your system to be unbootable, you can
follow some (or any other) recovery procedures to obtain a boot, examine
what happened and fix it.

First thing: if you get a "Waiting for /dev to be fully populated" message,
then you did not move /etc/init.d/udev out of the way.  If you did move it
out of the way and your system is still not functioning properly, try this:

* reboot and stop the grub boot process
* edit the linux kernel boot line and add " init=/bin/sh" at the end
  (look up how to do this properly - remember don't include the quotes!)
* once in run /sbin/MAKEDEV generic (this may take some time) OR
* consider copying over the backup of the /dev entries

Second thing: you should have double-checked (in advance) that Xorg worked
without udev, that the recovery process worked, that booting with sysvinit
worked and so on.  So, really, you really should have a working system at
this point.

Why am I doing this?

Why take such a huge risk with a live-running system on which my business
critically depends?

The introduction of systemd is an all-or-nothing polarising process
that has been forced onto people with absolutely zero consultation.
Clear, rational (and some irrational) and loud voices are informing
the developers in no uncertain terms that this all-or-nothing approach
is completely unacceptable, yet those voices - both reasonable and
unreasonable - are being completely ignored.

Many times it is quoted "Go away and edit the source yourself", which
is incredibly irresponsible, as many people now critically depdending on
GNU/Linux for their livelihoods simply do not have the time or expertise
to follow such "recommendations".  It would take them years to learn
what is needed, resulting in their business and livelihoods being neglected
whilst they endeavoured to get up-to-speed.

This situation very much reminds me of why I spent four years of my life
reverse-engineering NT Domains from 1996 to 1999 (work from which many
people - users, developers and distro companies - financially benefitted,
and I have yet to receive proper financial compensation for that work.
This has to be said, in this new era of Software Libre where it is finally
recognised that paying Software Libre Developers for work they have done
is a good idea).

So with Redhat paying Pottering to make these all-or-nothing
unilateral decisions, somebody has to make a clear statement that this
is unacceptable, and to help people to have a system that is functional
without systemd, even if some of the convenience introduced over the
past few years has to go.

And, just as I did with Samba-TNG when there was a polarising situation,
it is no good just "talking" (if you merely "talk", why should anyone
listen?), it is necessary to take action.  The action that I
decided to take is to hand-edit and recompile key packages, removing systemd
and libsystemd0 as a dependency, so that I can at least run some of the
software that I would otherwise be forced to completely remove.

In documenting that process (including its risks) I have made it clear
that it is possible to have a working Debian GNU/Linux Desktop
system without systemd (albeit an unusual one), and, not only that, but
it is felt that the unilateral introduction of systemd is so objectionable
that, regardless of how "good" it is *believed* to be, I absolutely will
not tolerate it being on my system.  Software Freedom is exactly that:
Freedom.  However, those people being paid to work on Software Libre
are, sadly, becoming completely ignorant of the responsibility and duty
that comes with the position that they are now in.

Improvements and Collaboration

I would very much love to hear from people who have followed this
procedure (or similar) and who have (tested) improvements to make, in the
form of patches to the HTML of this document.  In particular, whilst it
was convenient to remove cups-daemon and sane-utils as this particular
laptop is not used for printing, others reading this document may be
critically dependent on those two packages.  Patches which recompile
cups and sane to remove systemd would benefit many people.

Also, it is keenly recognised that there are much better ways to manage
recompiled debian packages, however the primary purpose of this work was
not to be concerned initially about future maintenance or convenience,
but to get systemd and libsystem0 off the laptop as quickly as possible
and still at least remain "functional".  If anyone has any suggestions
as to how to better compile these (and any other) packages (such as
extending the name of the .deb package so that it properly overrides
debian-maintained versions, pinning advice and so on), please do submit
them in the form of a patch to the HTML of this document or as a simple
separate section in free-form text or creole markdown that may be
easily added.

I may be reached at lkcl@lkcl.net or luke.leighton@gmail.com

Success Reports

I'd like to maintain a list, here, of people who have successfully followed
this report, and am happy to share (socially acceptable) brief comments.
The idea behind doing this is to demonstrate that there really is a strong
desire amongst intelligent individuals to not have systemd forced on them.
The best techical explanation (which includes advantages that systemd provides)
is on softpanorama.org, here.

If you would like to be included on this list, please provide your name,
a brief bit about you ("Debian Developer", "Experienced Systems Administrator",
"Instigator of the Software Freedom Movement"), the date that you successfully
followed these instructions (and on how many systems), and optionally a brief
comment that you feel would help other people.  Comments which can only be
charitably described as "having a poo on everyone's head" will only be
considered for inclusion if they happen to be incredibly funny.