Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Niko Tyni]

On Wed, Aug 16, 2017 at 06:58:32PM +0200, Philip Hands wrote:
> Colin Watson  writes:
> 
> ...
> > If you want to consider this bug closed at this point without a formal
> > resolution, then I'm OK with saving you folks some time, ...
> 
> I think that's fine, so I'm going to just close the bug now.

Fine by me at least, thanks Phil.

Following OdyX's suggestion I'm appending my initial draft for a
resolution that turned out to be unnecessary. Maybe this is helpful
in some way.

Please note that this has not been reviewed by other tech-ctte members
except partly Phil. Any errors (factual or otherwise) are therefore all
mine.

=== Draft resolution ===

The Technical Committee has been asked for advice regarding a GRUB upgrade
failure caused by a configuration file in the init-select package.

The default contents of this configuration file in the current oldstable
distribution (jessie) have a bug that triggers when the init-select
package is removed but not purged. The package has since been removed from
Debian and does not exist in the current stable distribution (stretch)
or in unstable/testing. Normal system upgrades from jessie to stretch
result in the package getting removed due to other dependencies, leading
to an upgrade failure.

While fixing the configuration file in oldstable in a point release would
mitigate the issue, it would leave upgrades straight to current stable
affected. Therefore a fix in a stable point release would be preferrable
(but does not rule out fixing this in oldstable too.)

The fix can go either in the (now obsolete) configuration file, or
GRUB's handling of it. As there is no package left responsible for
cleaning away the configuration file, changes in the GRUB handling
would be needed potentially forever and would therefore cause a long
term maintenance burden.  By contrast, fixing the configuration file is
a one-time operation.

The Committee therefore resolves that:

1. We advise the GRUB maintainer to take over management of the
   offending configuration file.

Actual changes in the configuration file (modifying or removing it)
are not in scope of this resolution and are governed by normal Debian
policies and procedures.

2. Developers who consider this takeover to violate the Debian Policy
   are invited to voice their concerns via the normal policy process so
   that the policy can be amended if necessary.

=== End Draft Resolution ===

The change proposed by Guillem in

 <20170702011536.kux7dnmybmbsv...@gaara.hadrons.org>

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863801#22

to introduce a comment in the configuration file (instead of removing it
straight away) seems sound to me and might have been part of the advice
but we never got as far as discussing that.

-- 
Niko Tyni   nt...@debian.org

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Colin Watson]

On Sat, Jul 22, 2017 at 06:25:19AM +0200, Philip Hands wrote:
> Just in case it's not already clear from the replies you have received
> so far, there is a consensus amongst the members of the TC that you
> should do as you suggest -- this was reflected in our recent meeting:
> 
>   
> http://meetbot.debian.net/debian-ctte/2017/debian-ctte.2017-07-19-18.59.log.html#l-36
> 
> That being the case, I think you should just get on with fixing it,
> rather than awaiting a resolution from us.  (of course if other TC
> members have some objection to this suggestion, please say so).

Thanks.  I haven't had a chance to actually deal with this yet, and
won't for at least a couple of weeks, but I agree that there's a clear
consensus.  (I like the suggestion to just adopt the configuration file
outright, which seems like a good way to make it clear that this isn't
just two packages playing core wars in the archive; I expect I'll take
that approach unless some unforeseen problem arises while implementing
it.)

If you want to consider this bug closed at this point without a formal
resolution, then I'm OK with saving you folks some time, but I also
don't object if you want a formal resolution for the project's records.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Philip Hands]

Hi Colin,

Just in case it's not already clear from the replies you have received
so far, there is a consensus amongst the members of the TC that you
should do as you suggest -- this was reflected in our recent meeting:

  
http://meetbot.debian.net/debian-ctte/2017/debian-ctte.2017-07-19-18.59.log.html#l-36

That being the case, I think you should just get on with fixing it,
rather than awaiting a resolution from us.  (of course if other TC
members have some objection to this suggestion, please say so).

I see no reason for you to waiting for the outcome of a discussion
about whether we need to change policy, or give you an exception to
policy, or simply say that there's nothing going on in violation of
policy.

Also, if you were to come across any additional wrinkles in the course
of fixing this, you can mention them so that we can make sure that
whatever we resolve ensures that you are able to do whatever is needed
(or perhaps suggest alternative approaches).

BTW I'd like to thank you for the clarity with which you laid out the
problem for us -- I'm sure the rest of the TC appreciate that too.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Bastian Blank]

On Tue, Jun 27, 2017 at 11:31:57AM -0700, Josh Triplett wrote:
> On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson  wrote:
> > 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.
> 
> This seems very reasonable. However, to avoid even the remote chance of
> losing user data, you should include hashes of all shipped versions of
> init-select.cfg or possible generated versions of it for various init
> systems, and if the file doesn't match one of those, move it aside to a
> backup location and provide a notice to the user that you've done so.

We already have such a functionality available via
dpkg-maintscript-helper.

Bastian

-- 
There are some things worth dying for.
-- Kirk, "Errand of Mercy", stardate 3201.7

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Andreas Beckmann]

Control: block 866643 with -1

On Wed, 28 Jun 2017 22:34:41 +0300 Niko Tyni  wrote:
> On Sun, Jun 25, 2017 at 11:37:13PM +0100, Colin Watson wrote:
> 
> > I could arrange for the relevant grub2 postinst scripts to remove
> > /etc/default/grub.d/init-select.cfg entirely when appropriate conditions
[...]
> As init-select is gone from stretch and sid, and particularly given the
> other circumstances, I think you should feel free to take over management
> of the offending conffile that used your extension facility.
> 
> Viewed this way, I'm not sure there's an inherent policy violation here
> at all (assuming you only remove the file if it's unmodified etc.)
> All you're doing is adopting a configuration file and removing it on
> upgrade as obsolete.
> 
> Obviously moving configuration files should only be done between
> cooperative packages and hostile takeovers are not OK, but that's not
> an issue here.

On 2017-07-02 03:15, Guillem Jover wrote to #863801 (the corresponding
grub-coreboot bug):
> Isn't the obviously correct and policy compliant approach to just
> Conflicts/Replaces (or Breaks/Replaces depending on the force you want
> to apply here) with the init-select package from one of the grub
> packages, and on that grub package ship a stub init-select.cfg with
> just a comment explaining what's going on. And in the next release cycle,
> just make that package remove its (now) own conffile?

(Guillem explained this in a better way than my similar suggestion)

For completeness: init-select needs to be fixed in jessie-pu, since it
will fail to install/remove if mysql-server is installed, but apparmor
is not. (This is unfortunately not flagged as a failure by our regular
piuparts tests [1]) Bugs: init-select: #858528, jessie-pu: #866643

[1] https://piuparts.debian.org/jessie-rcmd/pass/cqrlog_1.8.2-1.1.log


Andreas

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Niko Tyni]

On Sun, Jun 25, 2017 at 11:37:13PM +0100, Colin Watson wrote:

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

I also think this is acceptable.

As init-select is gone from stretch and sid, and particularly given the
other circumstances, I think you should feel free to take over management
of the offending conffile that used your extension facility.

Viewed this way, I'm not sure there's an inherent policy violation here
at all (assuming you only remove the file if it's unmodified etc.)
All you're doing is adopting a configuration file and removing it on
upgrade as obsolete.

Obviously moving configuration files should only be done between
cooperative packages and hostile takeovers are not OK, but that's not
an issue here.

If init-select actually had a future in sid/buster, things would be
a bit messier I think...

As for possible policy changes, this seems such a corner case to me that
they'd be a bit overkill. But I'm certainly not opposing such changes.
-- 
Niko Tyni   nt...@debian.org

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Josh Triplett]

On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson  wrote:
> 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.

This seems very reasonable. However, to avoid even the remote chance of
losing user data, you should include hashes of all shipped versions of
init-select.cfg or possible generated versions of it for various init
systems, and if the file doesn't match one of those, move it aside to a
backup location and provide a notice to the user that you've done so.

- Josh Triplett

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[David Bremner]

Colin Watson  writes:


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

This seems like a tolerable approach for this particular situation.

The question of what policy changes (if any) are needed seems harder to
me, and for the moment I'll defer commenting on that, except to note
that I agree with Tollef that policy change doesn't need be a blocker
here.


signature.asc
Description: PGP signature

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Tollef Fog Heen]

Hi,

]] Colin Watson 

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

I think this would be ok, see below.

[...]

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

I think a package that provides an extension interface (as you do)
should be able to police the use of those extension points in the cases
where there are (effectively unfixable) bugs or abuses of those
extension points.

I think extending policy with wording in this direction would be fine,
but I also think that you don't need to hold up making your change for
the policy change to go in (at least once the CTTE issues a
recommendation).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Michael Biebl]

On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson  wrote
> I could have NMUed init-select in both unstable and stretch with a
> corrected conffile (and probably also with a corrected sysvinit

init-select was not part of stretch, so an NMU would not be possible
afaics. At least I would be surprised if the SRMs would allow to
re-introduce a package via a stable upload.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Colin Watson]

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