Student Application for Debian GNU/Hurd Debianish initialization

Statement of the problem

Use of custom initialization scripts

Currently Debian/Hurd uses custom programs and scripts for early system bootstrapping. The programs and scripts are provided by the hurd package.

Life of a hurd system starts when the root filesystem translator starts /hurd/init. /hurd/init starts the proc and auth server and then executes /etc/hurd/runsystem.

The relevant scripts reside in /etc/hurd:

root@hurdbox ~ # ls -l /etc/hurd
total 12
-rwxr-xr-x 1 root root 2756 Apr  9  2012 rc*
lrwxr-xr-x 1 root root   27 Jan 16  2012 runsystem -> /etc/alternatives/runsystem*
-rwxr-xr-x 1 root root 4141 Dec  8  2011 runsystem.gnu*
root@hurdbox ~ # dpkg --search /etc/hurd
hurd: /etc/hurd

/etc/hurd/runsystem is started by /hurd/init and setups ttys and starts /etc/hurd/rc or falls back to starting an emergency shell.

/etc/hurd/rc is Debian/Hurds equivalent of /etc/init.d/rc, but it is doing a lot of other stuff too, like checking the root filesystem, remounting it rw, activating swap, cleaning up various files, working around various differences between Hurd and Linux. It is also a lot more limited, in fact it just runs all scripts matching /etc/rc{.boot,2.d}/S*.

So while the Hurd bootstrap has to be a bit different than a Linux bootstrap, there is no need for it to be this different. Also the rc script used by Debian/Hurd does not support the sysv style runlevel switching and does not execute K??-* scripts.

Survey of initialization scripts & differences between Hurd and Linux

Here is a list of scripts I found on my most recently installed Hurd box in /etc/rcS.d:


doing what

is currently being done by


Set hostname based on /etc/hostname


It surely is being set somewhere, but I haven't figured out where this happens

Mount kernel virtual file systems (proc & sys)



Set preliminary keymap


I guess Hurds equivalent is the Mach console before the Hurd console takes over

Mount special file systems under /dev (pts & shm)


If we try to minimize our passive translator usage, we would have to start a lot of translators here

Check to root file system.


bootclean after checkroot.



Update mtab file.


reads /proc/mounts which does not exist on Hurd

Check all filesystems.


Mount all filesystems.


bootclean after mountall.



Save and restore random seed between restarts.


translator reads from a seed file, not sure if this is ever written to


Raise network interfaces.


known issue: [3]

Wait for network file systems to be mounted


bootclean after mountnfs.



Set console font and keymap


font and keymap are handled by the hurd console

Miscellaneous things to be done during bootup (utmp file & nologin)



[1] Not part of the startup scripts, uses passive translators for persistence.

[2] Not normally done on hurdish systems, but could/should be done, see discussion about passive translators.

[3] Nowadays Hurd uses translators to access NICs (yay userspace drivers :) ) typically bound to /dev/ethX. Using a device name like /dev/ethX in /etc/network/interfaces kinda works, but does not play well with ifupdowns state machinery.

Stuff that the current Hurd scripts & programs do that have no equivalent on Linux:

State of the initialization scripts

(Probably) thanks to the kFreeBSD folks some of the initialization scripts are kernel aware, e.g. contains:

        KERNEL="$(uname -s)"
        MACHINE="$(uname -m)"
        case "$KERNEL" in

So there is a mechanism in place to deal with different kernels. In addition, urandom contains a kFreeBSD specific workaround.

This makes me believe that

Passive translators

There are some system configuration aspects that are handled quite differently on Hurd, prime examples are mounting of file systems and network configuration.

While on Linux this configuration is volatile (meaning that it is not preserved across system restarts) and has to be set up at boot time, Hurd provides a mechanism to encode system configuration as "passive translators" in filesystem nodes. Translators provide some kind of service (e.g. filesystem or network services) and are started on demand if a passive translator is set on a filesystem node.

For example the network configuration on my hurd box is currently done by means of passive translators. The passive translator can be queried using showtrans, the active translator can be inspected using fsysopts. Translators are just programs running in user space, my pfinet translator (Hurds network stack) is running as pid 100:

root@hurdbox /etc/hurd # showtrans /servers/socket/2
/hurd/pfinet --interface=/dev/eth0 --address= --netmask= --gateway=
root@hurdbox /etc/hurd # fsysopts /servers/socket/2
/hurd/pfinet --interface=/dev/eth0 --address= --netmask= --gateway=
root@hurdbox /etc/hurd # ps --pid 100
  100  - S<o  27:40.58 /hurd/pfinet --interface=/dev/eth0 --address= --netmask= --gateway=

It is an open (design) question how to deal with this discrepancy between Hurd and Linux. As passive translators have their share of problems as well, it might be best not to use passive translators but to just start active translators at boot time as specified by the same configuration files as Debian/Linux uses.

More information on translators can be found at

  1. The live cd part was inspired by the live cd. I learned a lot from this experience and I was amazed how pluggable and powerful the Hurds architecture is. Announcement: (1)