doc/linux/DINIT-AS-INIT.md

   1 ## Dinit as init: using Dinit as your Linux system's init
   2
   3 You can use Dinit, in conjunction with other software, to boot your system and
   4 replace your current init system (which on most main distributions is now
   5 Systemd, Sys V init, or OpenRC).
   6
   7 Be warned that a modern Linux system is complex and changing your init system
   8 will require some effort and preparation. It is not a trivial task to take a
   9 system based on a typical Linux distribution that uses some particular init
  10 system and make it instead boot with Dinit. You need to set up suitable
  11 service description files for your system; at present there are no automated
  12 conversion tools for converting service descriptions or startup scripts from
  13 other systems. For example service files, please check the `services`
  14 subdirectory.
  15
  16 Once you have service descriptions ready, you can test Dinit by adding
  17 "init=/sbin/dinit" (for example) to the kernel command line when booting.
  18 To have Dinit run as your system init (once you are satisfied that the service
  19 descriptions are correct and that the system is bootable via Dinit), replace
  20 your system's `/sbin/init` with a link to the `dinit` executable.
  21
  22 *Note*: if your system boots via an "initrd" (initial ramdisk image), you
  23 might need to either adjust the ramdisk image to include `dinit` or switch
  24 to mounting the root filesystem directly; consult kernel, bootloader and
  25 distribution documentation for details.
  26
  27 The additional software required can be broken into _essential_ and
  28 _optional_ packages, which are detailed in following sections.
  29
  30
  31 # General notes
  32
  33 It is common to use "devtmpfs" on /dev, and the kernel can actually mount it
  34 there before it even starts the init process, which can be quite handy; for
  35 one thing it means that a range of device nodes will be available by default
  36 (including /dev/console, which dinit may need to display any output, as well
  37 as the block device used for the root mount, which must be available in
  38 order to perform the initial fsck). You must configure your kernel
  39 appropriately for this to happen.
  40
  41 (actually, it seems that Dinit manages output without /dev/console; probably
  42 the kernel is giving it appropriate stdin/out/err file descriptors. I'm not
  43 sure if this was the case for older kernels).
  44
  45 The /dev filesystem on linux after boot is usually managed by a "device node
  46 manager", such as Udev (which is now distributed only with Systemd) or
  47 Eudev. Even this is technically optional - you can still populate your root
  48 filesystem with device nodes directly - but I highly recommend using an
  49 automated system.
  50
  51 Various other virtual filesystems are mounted as standard on Linux these
  52 days. They include:
  53
  54 - /sys - sysfs - representation of devices, buses, drivers etc; used by udev etc.
  55 - /sys/fs/cgroup - cgroupfs - control groups
  56 - /proc - procfs - information about running processes, and various kernel
  57   interfaces
  58 - /dev/shm - tmpfs - used for shared memory
  59 - /dev/pts - devpts - pseudoterminal devices
  60 - /run - tmpfs - storage for program state (replacement for /var/run); used by
  61   udev and some other programs
  62
  63 These filesystems (particularly /sys, /proc and /run) need to be mounted
  64 quite early as they will be used by early-boot processes.
  65
  66 Many Linux distributions are now built around Systemd. Much of what Systemd
  67 manages was previously managed by other utilities/daemons (syslogd, inetd,
  68 cron, cgmanager, etc) and these can still be used to provide their original
  69 functionality, although at the cost of the losing automated integration.
  70
  71 Some packages may rely on the "logind" functionality of Systemd for
  72 session/seat management. This same functionality is also provided by
  73 Elogind and ConsoleKit2, though I'm not sure to what degree nor level of
  74 compatibility.
  75
  76 In general I've found it quite possible to run a desktop system with Dinit
  77 in place of SystemD, but my needs are minimal. If you're running a
  78 full-fledged desktop environment like Gnome or KDE you may experience
  79 problems (which, I believe, should not be intractable, but which may require
  80 implementation/shims of Systemd APIs in some cases).
  81
  82 The basic procedure for boot (to be implemented by services) is as follows:
  83
  84 - mount early virtual filesystems
  85 - start device node manager
  86 - trigger device node manager (udevadm trigger --action=add) to add
  87   boot-time device nodes (possibly not necessary if using kernel-mounted
  88   devtmpfs)
  89 - run root filesystem check
  90 - remount root filesystem read-write
  91 - start syslog deamon
  92 - various miscellaneous tasks: seed the random number generator, configure the
  93   loopback interface, cleanup files in /tmp, /var/run and /var/lock
  94 - start other daemons as appropriate (dhcpcd, any networking daemons)
  95 - start getty instances on virtual terminals
  96
  97 The service description files and scripts in the `services` subdirectory
  98 provide a template for accomplishing the above, but may need some adjustment
  99 for your particular configuration.
 100
 101
 102 # Essential packages for building a Dinit-based system
 103
 104 Other than the obvious system C library and C++ library, you'll need a range
 105 of packages to create a functional Dinit-based system.
 106
 107 First, a device node manager. I recommend "Eudev".
 108
 109 - Eudev - the Gentoo fork of Udev; https://github.com/gentoo/eudev
 110 - Vdev - "a device file manager and filesystem" and a "work in progress";
 111   https://github.com/jcnelson/vdev
 112 - Mdev may also be an option; it is part of the "busybox" utility suite. I
 113   don't personally have any experience with it.
 114
 115 Then, a "getty" and "login" program. Both can be found in the util-linux
 116 package, at: https://www.kernel.org/pub/linux/utils/util-linux
 117
 118 Also provided in the util-linux package are standard utilities such as fsck
 119 and mount. You'll probably want e2fsprogs (or the equivalent for your chosen
 120 filesystem): http://e2fsprogs.sourceforge.net/
 121
 122 The syslog daemon from GNU Inetutils is basic, but functional - which makes
 123 it a good fit for a Dinit-based system. https://www.gnu.org/software/inetutils
 124
 125 You will need a shell script interpreter / command line, for which you have
 126 a range of options. A common choice is GNU Bash, but many distributions are
 127 using Dash as the /bin/sh shell because it is significantly faster (affecting
 128 boot time).
 129
 130 - Bash: https://www.gnu.org/software/bash
 131 - Dash: http://gondor.apana.org.au/~herbert/dash
 132
 133
 134 # Optional packages for building a Dinit-based system
 135
 136 **elogind**, to act as seat/session manager (extracted from Systemd's logind):
 137 https://github.com/elogind/elogind
 138
 139 Alternatively, **ConsoleKit2**:
 140 https://github.com/ConsoleKit2/ConsoleKit2
 141
 142 **cgmanager**, the control group manager; you probably want this if you use
 143 ConsoleKit2, and maybe if you want to use containers:
 144 https://github.com/lxc/cgmanager
 145
 146 (However, I believe that cgmanager works with the old v1 cgroups interface.
 147 I expect that v2 cgroups together with cgroup namespaces as found in newer
 148 kernels will render it obsolete).
 149
 150 The above use **Dbus**:
 151 https://dbus.freedesktop.org/