Bug#851893: The availability of update-grub does not imply that GRUB is used
Severity: important
Hi Alexander,
Le 20 janvier 2017 20:39:04 GMT+01:00, Alexander Kurtz <alexander@kurtz.be> a écrit :
>Hi!
>
>On Thu, 2017-01-19 at 22:05 +0100, Aurélien COUDERC wrote:
>> Thank you for your detailed bug report and analysis.
>> This looks a lot like #843727 [0] to me, although not for the same
>use case.
>>
>> Would you care to test 9.0.1, already in sid that should fix this
>problem ?
>> The following change was done :
>> 208: update-grub || echo "Updating grub failed, report success
>anyway!"
>
>I am sorry, I had not noticed bug #843727.
No problem. :-)
> However, I believe this
>change is not a correct solution, because:
>
> a) "On Error Resume Next" is (in general) not a good idea.
Yes, this was discussed on the team's list and deemed sufficient for now though not a very likable solution.
I quickly checked the released versions of desktop-base and it has been doing this at least since Squeeze… (Not that it makes it any better of an idea.)
> b) It is still a GRUB-specific solution. People use a whole bunch
> of different bootloaders to start Debian, GRUB is just one of them.
Understood. And is not using grub and still having grub tools installed such a common case ?
> c) It will cause really subtle bugs under some circumstances.
>
>Let me explain c): Assume that a user has the grub-pc package installed
>and GRUB is installed to /boot normally. At one point, the user decides
>to remove the grub-pc package (and only that) and use a different
>bootloader. Everything works, but the files under /boot/grub are of
>course still there. Now your package comes along and runs update-grub
>which happily modifies /boot/grub even though the user explicitly
>removed the GRUB automation package.
OK that's a case. :-)
I'm not really getting the problem here as I don't understand which other components would break with update-grub updating a grub folder… Not being a specialist I can imagine such cases could exist, though.
And anyway I agree with the whole idea that we shouldn't be update-grubing when we don't need to.
>> I'll merge the 2 bugs after confirmation that it works for you.
>
>I agree that your changes fixes the immediate problem. But I really
>think there are two fundamental issues with desktop-base calling the
>update script of one specific bootloader:
>
>(1) It's surprising to the user (and the maintainers of other packages)
>(2) It will only work with GRUB
Right, that said it's currently targeted specifically at grub to setup its wallpaper so I can sleep with that.
Patches are of course welcome if other bootloaders support similar functionality.
>> If you know of a better and robust way to detect if grub is being
>> used, advice is welcome.
>
>There is a better way, dpkg triggers [0-3]. There's even a
>corresponding bug in GRUB about it [4]. However, nobody really seems to
>care, so not much progress has been made.
>
>Maybe you could talk to the GRUB maintainers and convince them to add a
>"interest update-grub" trigger in the grub-pc and grub-efi packages.
You mean "activate update-grub" in grub packages ? (Or even "activate-noawait update-grub" would be preferred if I read the doc correctly.)
>Then GRUB's postinst would run the update-grub script, and all your
postinst would do is issue a "dpkg-trigger update-grub" call. Of
>course, it would be even better to find a generic solution for all
>bootloaders (e.g. a generic "update-bootloader" trigger), but I believe
>that it's too late in the release cycle for this.
I didn't have dpkg triggers in mind, but it sounds like a nice solution to this problem.
I'm unsure we can manage even the "simple" update-grub trigger done for Stretch though.
The current behaviour (that I had broken in 9.0.0, and reverted in 9.0.1) has been around for such I long time that I'd personally prefer postponing this change to early in the Buster cycle.
If you still feel like preparing the patches for both grub* and desktop-base and coordinating with the grub maintainers, I'll happily accept the change for desktop-base where I have commit rights.
Cheers,
--Aurélien
Reply to: