+
In the Debian boot system, several packages include scripts that
+are started from /etc/rcS.d/. In fact, there is a bite more of them
+than make sense, and this causes a few problems. What kind of
+problems, you might ask. There are at least two problems. The first
+is that it is not possible to recover a machine after switching to
+runlevel 1. One need to actually reboot to get the machine back to
+the expected state. The other is that single user boot will sometimes
+run into problems because some of the subsystems are activated before
+the root login is presented, causing problems when trying to recover a
+machine from a problem in that subsystem. A minor additional point is
+that moving more scripts out of rcS.d/ and into the other rc#.d/
+directories will increase the amount of scripts that can run in
+parallel during boot, and thus decrease the boot time.
+
+
So, which scripts should start from rcS.d/. In short, only the
+scripts that _have_ to execute before the root login prompt is
+presented during a single user boot should go there. Everything else
+should go into the numeric runlevels. This means things like
+lm-sensors, fuse and x11-common should not run from rcS.d, but from
+the numeric runlevels. Today in Debian, there are around 115 init.d
+scripts that are started from rcS.d/, and most of them should be moved
+out. Do your package have one of them? Please help us make single
+user and runlevel 1 better by moving it.
+
+
Scripts setting up the screen, keyboard, system partitions
+etc. should still be started from rcS.d/, but there is for example no
+need to have the network enabled before the single user login prompt
+is presented.
+
+
As always, things are not so easy to fix as they sound. To keep
+Debian systems working while scripts migrate and during upgrades, the
+scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency
+order, ie the scripts that nothing in rcS.d/ depend on can be moved,
+and the next ones can only be moved when their dependencies have been
+moved first. This migration must be done sequentially while we ensure
+that the package system upgrade packages in the right order to keep
+the system state correct. This will require some coordination when it
+comes to network related packages, but most of the packages with
+scripts that should migrate do not have anything in rcS.d/ depending
+on them. Some packages have already been updated, like the sudo
+package, while others are still left to do. I wish I had time to work
+on this myself, but real live constrains make it unlikely that I will
+find time to push this forward.
+
