Web lists-archives.com

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

On Wed, May 31, 2017 at 01:42:34PM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'stretch' fails.
> >From the attached log (scroll to the bottom...):
>   Setting up grub-coreboot (2.02~beta3-5) ...
>   Installing new version of config file /etc/kernel/postinst.d/zz-update-grub ...
>   Installing new version of config file /etc/kernel/postrm.d/zz-update-grub ...
>   /var/lib/dpkg/info/grub-coreboot.config: 1: /etc/default/grub.d/init-select.cfg: /usr/lib/init-select/get-init: not found
>   dpkg: error processing package grub-coreboot (--configure):
>    subprocess installed post-installation script returned error exit status 127
> This is most likely a bug in init-select, but since that package
> does not exist in stretch any more (and it will be removed during the
> upgrade from jessie to stretch due to dependencies/conflicts),
> grub-coreboot will have to work around the bug.

This is a tricky bug, so CCing debian-devel for comments.  (Note that
this applies to all grub-<platform> binary packages, not just

The basic problem in init-select is of course the good old favourite of
a conffile not behaving correctly when the package has been removed but
not purged.  This is probably worth fixing in unstable as follows, since
init-select is still there:

--- a/init-select.cfg
+++ b/init-select.cfg
@@ -1,1 +1,1 @@
+GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $([ ! -x /usr/lib/init-select/get-init ] || /usr/lib/init-select/get-init)"

I propose to NMU init-select with this change after a bit of testing and
the usual delay, since it would generally make life easier if there were
a non-broken version around somewhere.  We might also want to think
about putting that into jessie-proposed-updates.

However, I take Andreas's point that we need to work around this
somehow, probably in a stretch point release now, and that's where I
need feedback.  One possible approach would be to change grub-mkconfig
to do something like this:

  for x in ${sysconfdir}/default/grub.d/*.cfg ; do
    if [ "$(basename "$x")" = init-select.cfg ] && [ ! -x /usr/lib/init-select/get-init ]; then
      # work around #863801
    if [ -e "${x}" ]; then
      . "${x}"

But that lumbers me with having to maintain a workaround patch forever,
since there's no guarantee that init-select would ever be purged from
affected systems.  I appreciate that it's only a few lines, but these
things pile up over time.  I also don't think that ignoring errors from
/etc/default/grub.d/*.cfg scripts is a good idea: they might actually be
important to booting the system, even though they aren't in this case.

I'd rather do something like checking in the postinst whether these
conditions hold:

 * init-select is removed but not purged
 * /etc/default/grub.d/init-select.cfg contents match the buggy contents
   shown above

... and if so, replace /etc/default/grub.d/init-select.cfg with the
corrected version, coordinated with the NMU above.  This ought to mean
that if a fixed version of init-select is installed in the future, then
there'll be no conffile prompt because the new version is already in
place.  It would open the possibility of a potential conffile prompt in
future if the conffile in question is changed further, but it doesn't
seem to me that init-select has a sufficiently long likely future
lifespan for this to be very probable.  Replacing the file with a
corrected version is better than removing it, moving it aside, or
commenting out the offending line, since none of those would have the
desired behaviour in the event that a fixed version of init-select is

The benefit of this approach, even though it's a bit more complicated,
is that I could eventually drop it once users can be expected to have
upgraded through a grub-* package containing this workaround.  That
means that I don't have to carry a permanent patch just because some
other package made use of my package's extension facilities and got it

I fully appreciate that this is skating along the edge of policy's
requirements regarding conffiles, and arguably violates at least 10.7.4
"The maintainer scripts must not alter a conffile of any package,
including the one the scripts belong to".  However, I think that this is
a reasonable case of self-defence, and could be tolerable with
sufficient commentary and care.  I doubt I would be contemplating it if
init-select hadn't been removed from stretch.

Thoughts?  Can anyone think of a better solution than either of the two
I've outlined here?


Colin Watson                                       [cjwatson@xxxxxxxxxx]