Your message dated Wed, 16 Aug 2017 18:58:32 +0200 with message-id <878tija1qf.fsf@whist.hands.com> and subject line Re: Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select has caused the Debian Bug report #865929, regarding Advice on dealing with GRUB upgrade failure caused by init-select to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 865929: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865929 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: Advice on dealing with GRUB upgrade failure caused by init-select
- From: Colin Watson <cjwatson@debian.org>
- Date: Sun, 25 Jun 2017 23:37:13 +0100
- Message-id: <20170625223713.br33iugwqzwt5sip@riva.ucam.org>
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]
--- End Message ---
--- Begin Message ---
- To: 865929-done@bugs.debian.org
- Subject: Re: Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select
- From: Philip Hands <phil@hands.com>
- Date: Wed, 16 Aug 2017 18:58:32 +0200
- Message-id: <878tija1qf.fsf@whist.hands.com>
- In-reply-to: <[🔎] 20170806124343.wb554whyrl6oymqj@riva.ucam.org>
- References: <20170625223713.br33iugwqzwt5sip@riva.ucam.org> <87k231xfm8.fsf@whist.hands.com> <[🔎] 20170806124343.wb554whyrl6oymqj@riva.ucam.org>
Colin Watson <cjwatson@debian.org> 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. Cheers, Phil. P.S. It is conceivable that I'm exceeding my authority by doing so, but we can reopen the bug if so, and simply closing it avoids further delay. -- |)| 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, GERMANYAttachment: signature.asc
Description: PGP signature
--- End Message ---