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.

and used that as the jigdo base to download bookworm 12.0.0
main repository. After apt-get update --allow-insecure-repositories, I
rebooted.
Windows is no longer available. Looking in the Advanced options finds the
prior Linux entry.
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.
should not be erased - except for the one being replaced.
added to customize the system. This looks like a bug.

I just wanted to add my 2p to this as I have just had the same experience -
I have just updated my Linux installation, and rebooted to find that my
Windows installation is no longer available. I had to go and look up
GRUB_DISABLE_OS_PROBER, find it in /etc/default/grub, then change it, then
run update-grub, then reboot again.

It's fine to change the default behaviour, but it's not fine to remove OSs
that are already configured in grub before the upgrade. This is definitely
a bug.

CC

Control: retitle -1 grub doesn't run os-prober by default anymore, so no more other OS detected
Control: tag -1 wontfix

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.

Or edit /etc/default/grub and change the GRUB_DISABLE_OS_PROBER
setting there, then run "update-grub". It's up to you.

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


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

It's no secret that we ship a patch in Ubuntu to keep running
os-prober if the existing grub.cfg has os-prober entries in it to
avoid the regression, but the ship has sailed for Debian, everyone
has received the update by now, so introducing it again isn't helping
anyone (arguably the patch keeps it on if you install fresh but that
wasn't my personal decision).

If you are interested in multi boot via grub menum, my suggestion would
be to invest the time to write the code to do os-probing from grub. The
most important piece - dual booting windows can be easily done by
checking if the correct windows files exist and then adding a boot
entry.

Ultimately this is becoming less and less a priority for people because
it doesn't even work. If you have Windows installed in a normal setup,
it does its TPM based Bitlocker encryption, you won't be able to start
it via grub anyhow, but have to boot via the firmware menu. Same for
other OS, as we move forward to increasingly TPM encrypt OS, dual
booting only works without a foreign grub in the chain.

What I do want to do is add a boot menu to grub to allow you to boot
other OS in the boot menu by setting BootNext and resetting the machine;
but I don't think there's much value to be had sinking considerable
resources into legacy boot multi booting.

And yes, I want to also add that Windows detection, but I think that's
a reasonable level of regression for the security benefits.

Alternatively if you feel you need os-prober because you install
multiple Linux distributions in a BIOS system, I mean, by all means
enable it and live with the risk or work to sandbox grub-mount, I think
it could just drop its privileges after opening the device and install
seccomp filters and whatnot.

Thank you for the comprehensive explanation. I'm glad that the problem was
avoided for Ubuntu users. I am not a fan of TPM but accept that it is
inevitable. I agree that your BootNext idea is better in that context.

Good luck,

CC