(draft) The future of the boot system in Debian

Petter Reinholdtsen pere at hungry.com
Thu Jul 30 21:05:18 UTC 2009

I believe it is time to send some words to the debian community at
large, to let them know what is planned for the boot system.  Here is
a draft text.  Did I forget something, mess up something or should
anything be changed before I ship it off.  Where should it be sent?
debian-devel-announce@ seem like a good target for it.

The future of the boot system in Debian

(this is a draft written by Petter Reinholdtsen 2009-07-30)

Over the last few years, the boot system in Debian has become more and
more broken.  The reason is the changes done in the Linux kernel,
making it more and more event based.  The kernel and its drivers no
longer block all processing while detecting disks, network interfaces
and other hardware, and this make the trusty old boot system i debian
more and more fragile.  Device files in /dev/ are missing when fsck or
mount are looking for for them, or the network is not available when
the boot try to mount NFS entries, or the audio devices are missing
when the audio settings should be set.  The problem is fundamental to
the way we boot Debian today - sequencially, and a solution need to
address this fundamential problem.  I believe the solution is to move
to an event based boot system.

In addition to this, there are long lasting problems with the boot
sequence of the existing init.d scripts, for some combination of
packages.  The boot sequence is wrong in these cases, and to solve it
one need to change the sequence numbers of all the immediate forward
and reverse dependencies of the init.d script in question - and their
forward and reverse dependencies and so forth until the boot sequence
is correct.  Previously this was done by asking the package
maintainers to guess on and update sequence numbers, a process that
tended to introduce new problems and took a long time to solve
properly.  The solution to this problem is to change how we order of
boot scripts to calculate the boot sequence using dependency
information provided in the init.d scripts themselves.  Since
2009-07-27 this was enabled in Debian unstable, and it will be the way
init.d scripts are ordered in Squeeze.  Switching to a dependency
based boot sequencing allow us to ensure the correctness of the boot
sequencing, detect and fix dependency loops, and in general fix a set
of bugs in the distribution that has been very hard to fix.

It will take longer to solve the fundamental problem.  Here is the
current plan for how to solve it.  First some background information.
The current boot system can be seen as consisting of three different

 1) The implementation of /sbin/init, reading /etc/inittab and
    starting of the second part.  This is normally done using the
    sysvinit package, but a replacement available for the brave is the
    upstart package.

 2) The implementation of /etc/init.d/rc, which is responsible for
    calling the init.d scripts in the correct sequence.  This is
    normally done using the sysv-rc package.  An alternative is the
    file-rc package, which uses a file /etc/runlevel.conf instead of
    symlinks in /etc/rc?.d/ to decide what to execute and in which

 3) The individual init.d scripts, taking care of the tasks that need
    to be done during boot.  The basic framework is provided by the
    initscripts package, and the rest is handled by individual
    packages like udev, netbase, ifupdown, apache, etc. :) There is
    approximately 850 packages with init.d scripts in Debian/unstable.

The LSB require that init.d scripts are handled by a compliant
distribution, and this make me confident that we need to handle init.d
scripts also in the future.  For this reason, we need a solution that
is both event based for the early boot and calling init.d scripts in
the required sequence for the packages providing such scripts.

Part 2 (sysv-rc) and 3 has been changed to use dependency based boot
sequencing.  For those using file-rc, it need to be changed to also
order using dependency information for those using it during boot
(this is 0.16% of the Debian population, according to

To solve the fundamental problem, the plan is to replace /sbin/init
with a implementation that is able to act on kernel event.  It will
allow us to modify the boot system for the early boot to become event
based, while keeping the existing boot stuff working.  We could
rewrite sysvinit to become event based, or have a look at the existing
boot systems that handle kernel events.  After checking the options
and the systems used in other distributions, upstart seem like the
most promising candidate.  It is used by Ubuntu and Fedora at the
moment, and solve the problem in a backwards compatible way.  The plan
is to change upstart to actually use /etc/inittab, to make it easy to
switch between sysvinit and upstart.  We will also change the init.d
script handling to treat upstart jobs as init.d scripts, to provide an
alternative the architectures lacking upstart support.

When /sbin/init is changed to an event based framework, the next step
is to rewrite the early boot system to use these events when
available, and behave the traditional way when there are no events.
When this step is finished, the fundamental problem will be solved,
and the boot will be robust and should work correctly even in edge
cases with slow device busses.

Happy hacking,
Petter Reinholdtsen

More information about the initscripts-ng-devel mailing list