(draft) The future of the boot system in Debian
Armin Berres
armin at space-based.de
Thu Jul 30 21:55:55 UTC 2009
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
More information about the initscripts-ng-devel
mailing list