Re: cryptdisks(-early) initscripts, dependencies and loops
> Am Fri, 4 Jun 2010 02:49:32 +0200
> schrieb Petter Reinholdtsen <firstname.lastname@example.org>:
>> It is possible event baset boot sequencing might make it easier to
>> change the ordering, but also there the maintainer of a package need
>> to decide on some ordering.
> The defined order in /etc/init/cryptdisks-udev.conf is simply "start on
> block-device-added ID_FS_USAGE=crypto".
> The boot sequence then automatically corresponds to how things have been
> installed on top of each other. You'd have to check if upstart is ready
> for use in initramfs.
Good to see. I suspect this was possible, but had not verified it.
This is a great example of the issues a event based boot system will
solve, which the current sequence based boot system do not. Other
examples are failure to fsck and mount USB disks during boot (fatal if
the home directory is on that disk :) and services failing because the
network is not available when the service start during boot. There
are several such issues with the current boot system.
We need to address this fundamental problem with the current boot
system, but I believe we are too late in the Squeeze release cycle to
fix it before Squeeze.
A good start you all could help out with, is to move as many init.d
scripts as possible out of rcS.d/. If the script do not _have_ to run
before single user mode is entered, it should not be started from
rcS.d/. Eventually we can move network initialization out of rcS.d/
too. Below is the list from
<URL:http://lintian.debian.org/~pere/test-20100603.log> of all scripts
started after mountall-bootclean.sh. At least some of these should be
moved from rcS.d/ to rc[2-5].d/. To do this without breaking existing
installations, we need to start at the end and move scripts one by
one, while making sure package upgrades update all depending packages
first. Lucikly a lot of these scripts are standalone (like buildd)
and can be moved without much coordination. :)
I do not know which one of these can be moved. There are a lot of
them, and each will have to be evaluated individually. :)
Moving scripts out of rcS.d/ will get us one step closer to a useful
and working single user, increase concurrency during boot (speed up
the boot) and make it easier to move to an event based boot sequencing
(the remaining pieces in rcS.d/ can be converted to event scripts one
at the time, starting at the first script).