Bug#1038974: grub2: Update Linux erases Windows entry in boot list

[Chris Carr]

On Thu, 21 Sept 2023, 14:28 Julian Andres Klode, <julian.klode at canonical.com>
wrote:

> Control: retitle -1 grub doesn't run os-prober by default anymore, so no
> more other OS detected
> Control: tag -1 wontfix
>
> On Fri, Jun 23, 2023 at 04:31:55PM -0400, bud wrote:
> > Package: grub2
> > Severity: important
> > File: grub2
> > X-Debbugs-Cc: budheal508 at gmail.com
> >
> > Dear Maintainer,
> >
> >    * What led up to the situation?
> > I installed the 2023-04-24 weekly build, downloaded the 2023-06-05 build
> and used that as the jigdo base to download bookworm 12.0.0
> > Then I added the 21 DVD images and synaptic suggested adding the online
> main repository. After apt-get update --allow-insecure-repositories, I
> rebooted.
> >    * What exactly did you do (or not do) that was effective (or
> >      ineffective)?
> > The computer booted into bookworm. However, the existing option to boot
> Windows is no longer available. Looking in the Advanced options finds the
> prior Linux entry.
> >
> > Compare Bugs #1033985, #1008294 and #250626
> >
> >    * What was the outcome of this action?
> > Without a Windows option, there is a suggestion in bug #1033985 that
> os-prober will help set me reset the grub list. Otherwise, the Windows DVD
> will contrarily erase grub. I only added a Linux partition to this laptop
> to investigate a HDMI bug, as this one has HDMI, VGA and DisplayPort
> connectors.
> >    * What outcome did you expect instead?
> > Just because the Linux kernel has been updated, any existing entries
> should not be erased - except for the one being replaced.
> >
> > An update should not erase the settings the user or administrator has
> added to customize the system. This looks like a bug.
>
> The followup comment from Chris Carr made me understand that this seems
> to be about the os-prober entries. For security reasons, os-prober is
> no longer run when writing a new grub.cfg.
>
> You can either re-enable it and get exposed to any bug in grub
> filesystem implementations which will then run as root to mount
> any disk attached to the system, or add a /etc/grub.d file that
> echos additional fixed boot entries for your other OS.
>


But this still leaves the user significantly worse off than before the
update. A very small proportion of users will be knowledgeable enough to
write their own /etc/grub.d file without instructions (I'm not) or
confident enough to re-enable OS-prober after the update tells them it's an
attack vector (I am).

It feels like the correct behaviour is to look at the existing entries at
the start of the update and write a grub.d file on the user's behalf. There
aren't going to be many users who want to lose access to an OS on updating
grub.

CC

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20230922/8a7c2f39/attachment-0001.htm>