[Pkg-sysvinit-devel] The future of non-dependency-based boot

[Goswin von Brederlow]

Roger Leigh <rleigh at codelibre.net> writes:

> Hi,
>
> When dependency-based booting was introduced, it was initially
> entirely optional.  We later made it the default, and encouraged
> users to switch to dependency-based boot on upgrade.  So today,
> pretty much everyone will be using dependency-based boot with
> there being a minority continuing to use the static boot ordering
> of yore.  Probably mostly users who upgraded from etch.
>
> The reason for this mail is mainly to ask if there is any
> continuing need for the old static ordering to be kept, and if
> not, how best to migrate the remaining users.  With all other
> init systems worth their salt requiring dependencies, should
> sysvinit not do the same?
>
> Now that all (?) init scripts provide LSB headers, the existing
> static ordering will increasingly bitrot.  It was never that great
> to begin with, but with dependency ordering being used by the vast
> majority, it's going to be increasingly untested.  Do we want to
> continue to maintain something that will be increasingly
> unsupportable, or complete the migration cleanly before that point?
>
> WRT actually doing this, the main issues I can see are
> - blocking by obsolete-but-unpurged init scripts without LSB header.
>   We could mv them out of the way to .dpkg-old and continue, or
>   abort and require manual intervention.
> - breakage of any non-LSB scripts remain after this.  We could
>   abort in the preinst and prevent upgrade until it's manually
>   resolved, unless there's a cleaner way to handle it.
> Obviously, we don't want to make any systems unbootable, but doing
> it without any manual intervention where possible would be
> desirable.
>
> This can, of course, be left until wheezy+1.  It's just something
> which needs considering before it becomes a bigger problem.
>
>
> Regards,
> Roger

I think:

1) Long term the init situation will change anyway with upstream /
systemd rising in popularity. But not in wheezy. So why not wait for
that before dropping existing support.

2) Static order is currently supported and supporting it for wheezy
doesn't incurr horrible amounts of work. It hasn't degraded enough to
warrant removing it yet.

3) Aborting the upgrade because dependency boot ordering fails will be a
major issue for users. You already mentioned 2 issues and on my system
at home I get an error about a dependency loop. Dependency based boot
doesn't seem to be universally working enough yet.

Conclusion: Given the short timeframe for wheezy keep things as they
are. Consider removing it in wheezy+1.



As a side note I have a use case at work where static order seems to be
needed. We build boot images for network boot of clusters. During boot
additional files can be copied from NFS into the system including boot
scripts. When using dependency based boot order the numbers for boot
scripts change a lot depending on the boot image (include support for
lustre, ha, slurm, ... and each gets a different order). That makes it
impossible (or at least a lot harder) to copy in the same generic boot
scripts from NFS into different images since the name needs to be
different for each case. The boot scripts would have to be reordered
during boot.

MfG
        Goswin