(draft) The future of the boot system in Debian

[Armin Berres]

Hi!

On Thu, 30 Jul 09 23:05, Petter Reinholdtsen wrote:
> 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.

I think d-d-a@ is appropriate.
Maybe you should also mention which changes are actually changes for
Squeeze, Squeeze+1 or maybe Squeeze+2?

Below I marked some things which I consider to be typos and noticed
while reading the mail. Recheck before changing your text, I am also
no native speaker.

Greetings,
Armin

> 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
                                                               in
> 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
           tries
> when the audio settings should be set.  The problem is fundamental to
> the way we boot Debian today - sequencially, and a solution need to
                                                              needs
> 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
      needs
> 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
                                                           be solved?
> 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
                  is?
> 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
> parts:
> 
>  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
>     order.
> 
>  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
          requires
> distribution, and this make me confident that we need to handle init.d
                         makes
> 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
                                           needs
> order using dependency information for those using it during boot
> (this is 0.16% of the Debian population, according to
> popularity-contest).
> 
> 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
       an                               based on?     events 
> 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
              solves
> 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
> 
> _______________________________________________
> initscripts-ng-devel mailing list
> initscripts-ng-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel