Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select
Package: tech-ctte
Preamble
--------
I would like to seek advice from the Technical Committee on the proper
resolution of #863801. This is (for once) not a matter of
irreconcilable disagreement among developers, but one where the only
sensible technical resolutions I can see are in clear conflict with
generally-reasonable requirements in policy.
Constitutional status
---------------------
My belief is that I would ordinarily be responsible for this decision in
my capacity as the main active maintainer of grub2, and that in the
circumstances I could keep the policy violation narrow enough that it's
unlikely that anyone would be particularly inclined to make an issue of
it. However, on advice from debian-devel, I'm seeking advice under
§6.1(3) anyway because of the unusual situation (and so I believe that
the "last resort" injunction in §6.3(6) does not apply).
It may be that the right thing to do involves changing our technical
policy documents, but since I'm not absolutely sure of the correct
approach yet I haven't troubled the policy list with a discussion on
that, so I'm not asking for a decision under §6.1(1); I'm happy to
propose policy changes if the committee believes that to be part of a
proper resolution.
Summary
-------
init-select was introduced in January 2014 around the time of the init
system debate, with the intent of providing a straightforward way for a
user to select a non-default init daemon. It provides a debconf
interface to select between sysvinit, systemd, and openrc (and formerly
upstart as well). It operates by setting a variable in
/etc/default/init, and installing a conffile in
/etc/default/grub.d/init-select.cfg which adds an init= parameter to the
default kernel command line set by GRUB.
The grub2 extension facility used by init-select was added by me,
unrelatedly, in January 2013. At present it's maintained as a
Debian-specific patch to source /etc/default/grub.d/*.cfg after
/etc/default/grub, in the spirit of many other such *.d directories in
Debian. Any error in sourcing any of these files will cause
grub-mkconfig to exit non-zero: while this is partly due to the usual
shell "set -e" rules and would be quite difficult to avoid, I also think
it's generally appropriate here.
The conffile installed by init-select has a bug of a kind often found in
conffiles that arrange to execute programs: when init-select has been
removed but not purged, it will fail (exiting non-zero) rather than
realising that it is in a removed-but-not-purged state and silently
doing nothing. This results in various grub2 binary packages failing to
upgrade when init-select is in this state.
init-select was removed from stretch because of #830897: it depends on
sysvinit, which was a transitional package in jessie and was removed
from the archive in stretch. The appropriate fix would have been to
depend on sysvinit-core instead, but the maintainer did not react and no
other developer chose to issue an NMU. As a result, it will typically
be removed as part of upgrades from jessie to stretch, exposing any
users who had previously installed it to #863801.
init-select was removed from unstable in response to #865752, following
a discussion about this general problem on debian-devel.
Considering the upgrade problems that may result from this, I'd like to
find a solution that I can reasonably implement in a point release of
stretch.
Possible grub2 changes
----------------------
These are laid out in more detail in my debian-devel post, linked below.
I considered but rejected the idea of having grub-mkconfig explicitly
ignore errors from /etc/default/grub.d/init-select.cfg, or having it
ignore that file altogether. That option offers no long-term cleanup
path, and so I would have to retain an ugly patch in perpetuity.
I could have NMUed init-select in both unstable and stretch with a
corrected conffile (and probably also with a corrected sysvinit
dependency), and then arranged for the relevant grub2 postinst scripts
to replace /etc/default/grub.d/init-select.cfg with a corrected version
when appropriate conditions apply. This would have violated policy
§10.7.3/10.7.4. However, this option is at least in part no longer
available since init-select has been removed from unstable (at least not
without reintroducing it, which I don't wish to do).
I could arrange for the relevant grub2 postinst scripts to remove
/etc/default/grub.d/init-select.cfg entirely when appropriate conditions
apply. In addition to a self-defence argument, this is further
justified by the fact that grub2 now provides a similar facility of its
own as of 2.02~beta2-20: if other init daemons are installed, then
grub-mkconfig generates additional menu items for them (although there
are no arrangements to migrate the default choice from
/etc/default/init). This would still violate policy §10.7.3/10.7.4,
although it seems to be the favoured option of the debian-devel thread,
and it is the least bad option I can see so far.
Possible policy changes
-----------------------
The primary intent of the sections of policy governing configuration
file handling, at least insofar as it's relevant to this issue, is to
preserve user configuration and to avoid unnecessary conffile prompts.
Packages must remove configuration files on purge, and should remove
obsolete configuration files without local changes on upgrade. In the
case of a shared configuration file (which is not really the case here,
but it's related), policy requires a clear interface between the two
packages.
Policy does not at present contemplate the situation of an obsolete
*package* with configuration files whose presence causes grave-severity
problems for another package. Should it do so? We might, for instance,
grant a package that is being extended by configuration files from some
other package some additional authority to clean up problems caused by
that, or perhaps make some general provisions about this quite common
kind of configuration file extension interface. Of course we wouldn't
want to suggest that packages could play core wars with each other in
the archive.
References
----------
https://bugs.debian.org/863801
https://lists.debian.org/debian-devel/2017/06/msg00283.html
Thanks,
--
Colin Watson [cjwatson@debian.org]
Reply to: