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

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

[Debian Bug Tracking System]

Processing control commands:

> block 866643 with -1
Bug #866643 [release.debian.org] jessie-pu: package 
init-select/1.20140921+deb8u1
866643 was not blocked by any bugs.
866643 was not blocking any bugs.
Added blocking bug(s) of 866643: 865929

-- 
865929: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865929
866643: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866643
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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