boot menu not appearing after manual install of jellyfish daily build alongside other OS

[Bob H]

desktop amd64 PC, UEFI, 8 core processor, 16gb RAM, nVidia graphics card, several ssd's

manual install of Kubuntu Jellyfish to a partition on ssd alongside Kubuntu Focal LTS

I am testing an installation of Kubuntu Jellyfish daily build alongside Kubuntu Focal 20.04.3
Usually this proceeds without a problem.

Since the 16th Dec daily build of Jammy, the boot menu does not appear any more after installation, also booting ignores Kubuntu Focal and proceeds directly to Kubuntu 22.04.

I recovered the boot menu on this PC by running boot-restore from an iso of Kubuntu Focal both Focal and Jelly fish are then available from the restored boot menu.

This bug appears in Kubuntu Jammy after a manual install directly to the computer's ssd.

I'm not an expert at bug reporting, so if this report is incorrectly set out or if more info is needed I'm happy to follow instructions.
I'll keep an eye on this thread.
I think the problem is with the Jammy iso, not Focal.

A boot menu is not created and any other operating systems on the device become invisible to the user.
As this is a development version this could be a temporary state of affairs.
At the very least the user needs to know what will happen and to know this before beginning the installation process.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151
Uname: Linux 5.4.0-91-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
Date: Fri Dec 17 08:24:04 2021
InstallationDate: Installed on 2020-10-27 (416 days ago)
InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
SourcePackage: grub2
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1955109

[Julian Andres Klode (juliank)]

Yes, this is expected. os-prober has been disabled for security reasons in 2.06.

grub2 (2.06-1) UNRELEASED; urgency=medium

  * Boot menu entries for other operating systems are no longer generated by
    default. To re-enable this, set GRUB_DISABLE_OS_PROBER=false in
    /etc/default/grub.

 -- Colin Watson <email address hidden> Wed, 18 Aug 2021 13:03:23 +0100

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[ajgreeny (ajg-charlbury)]

I noticed this problem yesterday, 16 December 2021, but it is easy enough to overcome with an additional line added to /etc/default/grub
GRUB_DISABLE_OS_PROBER=false

There are other methods as well, adding the boot stanza of a missing OS to /etc/grub.d/40_custom file.

You need to update grub after either edit with
sudo update-grub

[Bob H (bobbicat)]

As os-prober has been disabled for 'security reasons' is it safe to re-enable it?
I am not a developer or programmer and am ignorant in these matters so I could use some guidance.

[Bob H (bobbicat)]

This bug was reported from Focal, I think I should have reported from Jammy.
I just tried a report from Jammy but was redirected here.

[Bob H (bobbicat)]

There is a workaround here but I'm pretty sure a newcomer to Ubuntu wouldn't be able to discover it.
To them this would appear to be an insurmountable problem and they could get into difficulties as any other OS present alongside on their device would apparently have 'disappeared'.
Perhaps the developers already have a method and plan to make this issue more user friendly?

[Bob H (bobbicat)]

A boot menu is not created and any other operating systems on the device become invisible to the user. As this is a development version this could be a temporary state of affairs.
At the very least the user needs to know what will happen and to know this before beginning the installation process.

[Bob H (bobbicat)]

As OS PROBER is disabled for security reasons I think this bug should be labelled 'security issue'
IO'm not sure I know how to do that at this stage.

[Leó Kolbeinsson (leok)]

Tested daily Kubuntu Jammy ISO 20-12-2021 and can confirm this error -
Installed alongide Lubuntu Jammy aand after reboot no boot menu available.

Test results here:
http://iso.qa.ubuntu.com/qatracker/milestones/429/builds/241532/testcases/1302/results

[Leó Kolbeinsson (leok)]

Tested daily Mate Jammy ISO 23-12-2021 and this occurred as in original report -

Installed alongside Kubuntu Jammy and after reboot no boot menu available as in comment # 11 above -

Test results here : http://iso.qa.ubuntu.com/qatracker/milestones/429/builds/241656/testcases/1300/results/

[Chris Guiver (guiverc)]

I just experienced this issue on my primary box.

Outlined here - https://discourse.lubuntu.me/t/lubuntu-jammy-issue-tracker-os-prober-grub-2-06/2952/3

- dell [optiplex] 960 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

Each ~fortnight I reboot from my usual *jammy* into my backup dualboot system (*focal*) to update it's packages etc.. but earlier today on reboot no grub menu appeared & I found myself back in jammy. The grub entries were only for the jammy system. It'd been 16 days since last reboot on the box.

[Leó Kolbeinsson (leok)]

I can confirm this also in Lubuntu Jammy - tested ISO 23-12-2021
http://iso.qa.ubuntu.com/qatracker/milestones/429/builds/241694/testcases/1701/results/

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Erich Eickmeyer (eeickmeyer)]

FYI, this is a known issue that is being discussed [1]. It has security implications.

[1] https://lists.ubuntu.com/archives/ubuntu-devel/2021-December/041769.html

[Chris Guiver (guiverc)]

QA-test install of Lubuntu jammy on
- dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

Box contains many OSes (lubuntu 20.04, 21.10 & debian/bookworm), with this install replacing the prior-to-install 21.04 with 22.04..

Post install; the box boots straight into new jammy install; no `grub` appears giving me the choice to boot into other OSes; and my first two attempts to get grub to show have failed (not hitting keys fast enough; or at the right time)

At the very least this will need documentation, but current "Install alongside", "auto-resize" QA-tests will/are failing due to this issue on some (older?) boxes.

[Norbert (nrbrtx)]

Installed Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220205)
along side Ubuntu MATE 18.04 LTS, can't boot it.

Please fix this bug.

[Bob H (bobbicat)]

@ Norbert (nrbrtx)
to overcome this bug, until some sort of fix is applied by the developers:

while logged into Jammy Jellyfish navigate to /etc/default/grub
and add the following line and save:

GRUB_DISABLE_OS_PROBER=false

After the edit, in the console, run:

sudo update-grub

The grub menu will be set up and other operating systems on the device will be displayed next time the system starts.

(Unfortunately this is viewed as a security problem, which has yet to be addressed.)

[Bob H (bobbicat)]

The installation text creates the impression that jellyfish will install alongside pre-existing operating systems.
Perhaps there should be a warning that it is a little more complicated in practice.

[Launchpad Janitor (janitor)]

This bug was fixed in the package grub2 - 2.06-2ubuntu5

---------------
grub2 (2.06-2ubuntu5) jammy; urgency=medium

  [ Julian Andres Klode ]
  * Free correct size when freeing params, rather than 16 Ki (LP: #1958623)
  * Build with FUSE3 (LP: #1935659)
  * Only run os-prober on first run and if it previously found other OS
    (LP: #1955109)

  [ Heinrich Schuchardt ]
  * Rename grub-core/loader/efi/linux.c
  * Add patches for GRUB on RISC-V
  * fat: fix listing the root directory
  * Enable building for RISC-V (LP: #1876620)

  [ Julian Andres Klode ]
  * Re-enable peimage code on other archs outside secure boot; this
    fixes LP: #1947046 when not booting in secure boot mode (secure
    boot pending security review of the code)

 -- Julian Andres Klode <email address hidden> Fri, 18 Feb 2022 17:21:16 +0100