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 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 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 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 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 _______________________________________________ initscripts-ng-devel mailing list initscripts-ng-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel