Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select
On Tue, Jun 27, 2017 at 11:31:57AM -0700, Josh Triplett wrote:
> On Sun, 25 Jun 2017 23:37:13 +0100 Colin Watson <cjwatson@debian.org> 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
Reply to: