The future of the boot system in Debian

[Petter Reinholdtsen]

[Craig Small]
> Hello Peter,

Hi.  

I copy your email to the initscripts-ng-devel@ mailing list, where the
work of the new boot system is being discussed.

> Thankyou for your detailed email on d-d-a about the changes in the
> init system.  I have personally seen some of these things happen but
> just put it down to my strange hardware.

I guess strange hardware is becoming the norm instead of being a rare
configuration. :)

> Anyhow, I look after the dh-make and procps packages and have a question
> regarding this new system for both.  Feel free to pass this email along
> to anyone else that can help.
> 
> First, dh-make has templates of init.d files.  I'd appreciate that
> someone have a look at them and let me know if there needs to be
> changes.  These templates roll into lots of packages so its worthwhile
> to get them right.  Filing a bugreport is probably the easiest way to
> let me know there is a problem.

I guess the equivalent of 'update-rc.d script defaults' would be a
good idea for the template.  That is provide the script/package name,
start in runlevels 2, 3, 4 and 5, stop in runlevels 0, 1 and 6, and
have required start and stop dependencies on $remote_fs and $syslog.

> Secondly, procps runs a sysctl program to set kernel variables. There
> are a mountain of dependencies between that kernel modules load when and
> what sysctl has access to.  For example, bug #507788 is the fact you
> cannot set ipv6 variables until the ipv6 module is loaded, which is
> loaded too late to set ipv4 variables before interfaces come online.
> 
> I'm wondering if you have any suggestions about what we could do here.
> Setting kernel variables is important, but when is the right time and is
> there any meaningful concept of "time" in an event based startup?

I would recommend starting with replicating the old boot location
using dependencies, and upload a package doing so.  If it is wrong, it
will be equally wrong for all. :)

Next, if procps can not load its setting using one script at one
location during boot, I guess it should be split in several scripts
loading different parts of the settings at different time during boot.
Eventually, perhaps some udev or upstart rule can be used when drivers
are loaded to set their kernel settings at the right time.

PS: I'm Petter, Peter Reinholdtsen is my distant cousin. :)

Happy hacking,
-- 
Petter Reinholdtsen