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