[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cryptdisks(-early) initscripts, dependencies and loops



[C. Gatzemeier]

> Am Fri, 4 Jun 2010 02:49:32 +0200
> schrieb Petter Reinholdtsen <pere@hungry.com>:
>
>> 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. :)

S20bootcdram
S20mountoverflowtmp
S21adjtimex
S21atm
S21bootcdflop
S21ebtables
S21fsprotect
S21iptables-persistent
S21mountdebugfs
S21mt-st
S21netenv
S21pcmciautils
S21pppd-dns
S21procps
S21pyroman
S21rdnssd
S21resolvconf
S21udev-mtab
S21ufw
S21x11-common
S21zvbi
S22ifupdown
S23ifscheme
S23networking
S24aoetools
S24bastille-firewall
S24cman
S24nbd-client
S24portmap
S24rpcbind
S25gfs-tools
S25gfs2-tools
S25nfs-common
S25rgmanager
S26mountnfs.sh
S27mountnfs-bootclean.sh
S28console-screen.sh
S29kbd
S30console-setup
S31alsa-utils
S31arno-iptables-firewall
S31bootmisc.sh
S31clvm
S31console-cyrillic
S31corosync
S31cryptmount-early
S31dns-clean
S31eeepc-acpi-scripts
S31espeakup
S31ferm
S31fiaif
S31fuse
S31gom
S31guarddog
S31guidedog
S31later-readahead
S31libpam-devperm
S31libpam-foreground
S31lm-sensors
S31mini-buildd-bld
S31netperf
S31nviboot
S31open-iscsi
S31oss4-base
S31quota
S31racoon
S31schroot
S31screen-cleanup
S31selinux-basics
S31setkey
S31setserial
S31shorewall
S31shorewall-lite
S31shorewall6
S31shorewall6-lite
S31srptools-boot
S31svgalib-bin
S31switchconf
S31tmux-cleanup
S31uptimed.sh
S31urandom
S32buildd
S32zfs-fuse
S33stop-bootlogd-single

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).

Happy hacking,
-- 
Petter Reinholdtsen


Reply to: