staging.inyokaproject.org

black_tencate schrieb:

UlfZibis schrieb:

Wenn man mehrere NVRAM-Einträge anlegt könnte man ja …

schaust Du → Mehrbootsystem mit 2x Ubuntu, da findest Du den Grund, warum das bei mehreren Ubuntu eben nicht geht!

Da steht vor allem ein Verweis auf genau den Artikel, den ich ja schon erwähnt hatte, und wo es ja erklärt wird. Und ansonsten schrieb ich ja im Konjunktiv.

Im UEFI-Bootmenü stehen dann halt fehlerhafte nicht nutzbare Einträge, was doch ein bisschen hässlich ist.

wer zwingt Dich, die anzulegen/beizubehalten?

Na genau Dein Vorschlag erzwingt das.

kB schrieb:

Es müssen zuerst die Pakete shim und os-prober entfernt werden und danach alle Pakete mit grub im Namen in der richtigen Reihenfolge. Die richtige Reihenfolge ist experimentell zu ermitteln: ...

Ich hab' jetzt mal in dem 22.04, welches ich mit ubiquity -b installiert hatte, nachgeguckt:

$ dpkg -l grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc grub-pc-bin grub-common grub2-common os-prober
dpkg-query: Kein Paket gefunden, das auf grub-efi-amd64-bin passt
dpkg-query: Kein Paket gefunden, das auf grub-efi-amd64-signed passt
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name           Version         Architektur  Beschreibung
+++-==============-===============-============-===============================>
ii  grub-common    2.06-2ubuntu7.1 amd64        GRand Unified Bootloader (commo>
un  grub-efi-amd64 <keine>         <keine>      (keine Beschreibung vorhanden)
ii  grub-pc        2.06-2ubuntu7.1 amd64        GRand Unified Bootloader, versi>
ii  grub-pc-bin    2.06-2ubuntu7.1 amd64        GRand Unified Bootloader, versi>
ii  grub2-common   2.06-2ubuntu7.1 amd64        GRand Unified Bootloader (commo>
ii  os-prober      1.79ubuntu2     amd64        utility to detect other OSes on>
$ apt policy grub-efi-amd64-bin grub-efi-amd64-signed
grub-efi-amd64-bin:
  Installiert:           (keine)
  Installationskandidat: 2.06-2ubuntu14.1
  Versionstabelle:
     2.06-2ubuntu14.1 500 (gestaffelt 0%)
        500 http://de.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
     2.06-2ubuntu10 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
     2.06-2ubuntu7 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
grub-efi-amd64-signed:
  Installiert:           (keine)
  Installationskandidat: 1.187.3~22.04.1+2.06-2ubuntu14.1
  Versionstabelle:
     1.187.3~22.04.1+2.06-2ubuntu14.1 500 (gestaffelt 0%)
        500 http://de.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
     1.182~22.04.1+2.06-2ubuntu10 500
        500 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages
     1.180+2.06-2ubuntu7 500
        500 http://de.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

Es scheint also schon das Fehlen der grub-efi-* Pakete zu reichen, damit grub nicht mehr unerwünscht per Aktualisierung installiert wird.

UlfZibis schrieb:

...

wer zwingt Dich, die anzulegen/beizubehalten?

Na genau Dein Vorschlag erzwingt das.

äh… nein. Im Falle secure boot steht sogar, daß er zu löschen ist. Bei nicht secure boot kann so ein Eintrag benutzt werden, aber

btw., der Titel hier heißt doch "…wie nach ubiquity -b", d.h, irgendein Bootloader der mit dieser Installation zusammenhängt, wird nicht gebraucht – gebootet wird über einen externen Loader, entweder die SymLinks, oder über configfile – also wozu sollte dann ein NVRAM Eintrag nützlich sein?

black_tencate schrieb:

Streifenschmerle schrieb:

...Bei mir hat es schon ausgereicht, den fstab-Eintrag der EFI-Partition in demjenigen System ("Sekundärinstallation") zu entfernen, das die EFI-Partition in Ruhe lassen soll.

bestimmt nicht, kannst Du ganz einfach prüfen mit dpkg-reconfigure grub-efi-amd64

Ich hab das jetzt nochmal überprüft und in meinem Sekundärsystem dpkg-reconfigure grub-efi-amd64 manuell ausgeführt (was ich bisher noch nie getan hatte - keine Notwendigkeit). In den folgenden Konfigurationsdialogen hab ich testweise mal angekreuzt, daß der NVRAM-Eintrag geschrieben/aktualisiert werden soll, bei der nachfolgenden Frage nach der EFI-Partition wurde diese jedoch zwar vorgeschlagen, war aber _nicht_ vorausgewählt und ich habe sie auch nicht angekreuzt. Daraufhin kam dann eine Warnung, daß ich kein Gerät zur Grub-Installation ausgewählt hab und ob ich mir da sicher bin, was ich bejaht habe. Trotzdem lief danach einmal update-grub durch.

Jedenfalls, nach einem Neustart erscheint immer noch wie gewünscht das Grub-Menü meines Primärsystems. Das ist dasselbe Verhalten, wie wenn bisher im Sekundärsystem update-grub ausgeführt wurde (automatisch oder manuell). Ich vermute, zum Überschreiben von Grub des Primärsystems durch das Sekundärsystem wäre es nötig gewesen, bei dpkg-reconfigure grub-efi-amd64 explizit die EFI-Partition anzukreuzen.

Mein Fazit bleibt daher das gleiche: Es scheint bereits auszureichen, im Sekundärsystem die EFI-Partition aus der fstab zu entfernen, um Grub-Interferenzen zu verhindern. (Oder ist das evtl. anders, wenn Secure Boot aktiv ist? Bei mir ist es deaktiviert.)

Viele Grüße, Jan

black_tencate schrieb:

UlfZibis schrieb:

...

wer zwingt Dich, die anzulegen/beizubehalten?

Na genau Dein Vorschlag erzwingt das.

äh… nein. Im Falle secure boot steht sogar, daß er zu löschen ist. Bei nicht secure boot kann so ein Eintrag benutzt werden, aber

Ich hab' da tatsächlich was durcheinandergebracht, nämlich den NVRAM-Eintrag und den meist gleich benannten UEFI-Ordner. 1:0 für Dich.
Durch die "manipulierte" /etc/default/grub wird GRUB in einem neuen Ordner <ESP>/EFI/NEU installiert. Wieweit und unter welchen Umständen dann auch automatisch ein gleich benannter NVRAM-Eintrag vorgenommen wird (und damit je nach UEFI-Implementierung auch automatisch die UEFI-Boot-Order auf selbigen priorisiert), weiß ich nicht mehr genau. Ich meine, dass mir das mal passiert ist.

btw., der Titel hier heißt doch "…wie nach ", d.h, irgendein Bootloader der mit dieser Installation zusammenhängt, wird nicht gebraucht –

Genau. Interessanterweise sind trotz ubiquity -b die Pakete grub-pc usw. dennoch installiert, aber auf eine mir nicht bekannte Weise kommt da bei einer Aktualisierung grub-install nicht zum Einsatz, und deshalb landet dann dessen GRUB-Binary auch nicht in <ESP>/EFI/Ubuntu (update grub und os-Prober werden weiterhin ausgeführt und aktualisieren die lokale /boot/grub/grub.cfg, was ja auch im Sekundär-System sinnvoll ist). Wo genau das konfiguriert ist, wäre der Kern meiner Frage gewesen. Wie man hier sieht, kann ich den Aufruf grub-install aber nun ins Leere laufen lassen. Dafür musste ich aber ein bisschen mehr deinstallieren, als nach ubiquity -b noch im System ist.

gebootet wird über einen externen Loader, entweder die SymLinks, oder über configfile – also wozu sollte dann ein NVRAM Eintrag nützlich sein?

Eben, und stören kann er in Zusammenhang mit der UEFI-Boot-Order, wenn er durch Aktualisierung des Sekundär-Systems automatisch angelegt wird.

Streifenschmerle schrieb:

Jedenfalls, nach einem Neustart erscheint immer noch wie gewünscht das Grub-Menü meines Primärsystems. Das ist dasselbe Verhalten, wie wenn bisher im Sekundärsystem update-grub ausgeführt wurde (automatisch oder manuell). Ich vermute, zum Überschreiben von Grub des Primärsystems durch das Sekundärsystem wäre es nötig gewesen, bei dpkg-reconfigure grub-efi-amd64 explizit die EFI-Partition anzukreuzen.

Entscheidend ist ja, wohin <ESP>/boot/grub/grub.cfg verweist (<ESP>/EFI/Ubuntu/grub.cfg kommt nur bei einem unsignierten und auch ohne secure boot startbarem <ESP>/EFI/Ubuntu/grubx64.efi zum Einsatz). Welche dieser Dateien nach einer GRUB-Aktualisierung in Sekundärsystem überschrieben werden, kann man direkt danach gut am Dateidatum erkennen. Im Grunde ist es egal, von welchem System <ESP>/EFI/Ubuntu/grubx64.efi stammt, wenn man (evtl. nachträglich manuell) dafür sorgt, dass <ESP>/boot/grub/grub.cfg auf /boot/grub/grub.cfg des Primärsystems verweist.

Nur in meinem speziellen Fall ist das nicht egal, weil neuere UEFI-GRUB-Versionen (und nur die von Ubuntu verteilten und angepassten) keine 32-Bit-Installationen mehr starten können. Hier die letzte Version, die das noch kann.

UlfZibis schrieb:

... Entscheidend ist ja, wohin <ESP>/boot/grub/grub.cfg verweist (<ESP>/EFI/Ubuntu/grub.cfg kommt nur bei einem unsignierten und auch ohne secure boot startbarem <ESP>/EFI/Ubuntu/grubx64.efi zum Einsatz).

*grübel*
eine

<ESP>/boot/grub/grub.cfg

ist hier in einer Ubuntu-Installation in VirtBox VM weder mit noch ohne secure boot vorhanden

Welche dieser Dateien nach einer GRUB-Aktualisierung in Sekundärsystem überschrieben werden, kann man direkt danach gut am Dateidatum erkennen.

und hier erscheinen jedenfalls alle in der ESP vorhandenen Dateien mit neuem Datum nach einem dpkg-reconfigure

(s. Anhang)

Hallo,

UlfZibis schrieb:

Wie kann ich das konfigurieren, bzw. welches Paket muss ich dafür deinstallieren, also um den gleichen Zustand zu bekommen, als hätte ich mit ubiquity -b installiert?

Also für Jammy führt ein ubiquity -b zu folgendem Installations-Stand - egal ob UEFI-Boot mit oder ohne Secure Boot:

root@ubuntu:/# dpkg -l grub* | grep ii
ii  grub-common           2.06-2ubuntu7 amd64        GRand Unified Bootloader (common files)
ii  grub-gfxpayload-lists 0.7           amd64        GRUB gfxpayload blacklist
ii  grub-pc               2.06-2ubuntu7 amd64        GRand Unified Bootloader, version 2 (PC/BIOS version)
ii  grub-pc-bin           2.06-2ubuntu7 amd64        GRand Unified Bootloader, version 2 (PC/BIOS modules)
ii  grub2-common          2.06-2ubuntu7 amd64        GRand Unified Bootloader (common files for version 2)

AFAIK - zu 100% garantieren kann ich es aber nicht - sind die Abhängigkeiten hinsichticher dieser Pakete bei Focal und Jammy gleich.

Von diesen Paketen sind die folgenden abhängig:

root@ubuntu:/# apt-rdepends -r -s=Depends,Recommends,Suggests --state-follow=Installed --state-show=Installed grub-common grub-gfxpayload-lists grub2-common grub-pc grub-pc-bin
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
grub-common
grub-pc
  Reverse Suggests: memtest86+ (5.31b+dfsg-4)
  Reverse Recommends: linux-image-5.15.0-43-generic (5.15.0-43.46)
  Reverse Recommends: linux-image-5.19.0-32-generic (5.19.0-32.33~22.04.1)
grub-gfxpayload-lists
grub-pc-bin
grub2-common
os-prober
  Reverse Recommends: grub-common (>= 2.06-2ubuntu7.1)

Außerdem eventuell noch hilfreich für Dich:

root@ubuntu:/# apt remove -s grub-common grub-gfxpayload-lists grub2-common grub-pc grub-pc-bin
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Das folgende Paket wurde automatisch installiert und wird nicht mehr benötigt:
  systemd-hwe-hwdb
Verwenden Sie »sudo apt autoremove«, um es zu entfernen.
Die folgenden Pakete werden ENTFERNT:
  grub-common grub-gfxpayload-lists grub-pc grub-pc-bin grub2-common os-prober
0 aktualisiert, 0 neu installiert, 6 zu entfernen und 286 nicht aktualisiert.
Remv grub-pc [2.06-2ubuntu7] [grub-gfxpayload-lists:amd64 ]
Remv grub-gfxpayload-lists [0.7]
Remv grub2-common [2.06-2ubuntu7]
Remv grub-pc-bin [2.06-2ubuntu7]
Remv grub-common [2.06-2ubuntu7] [os-prober:amd64 ]
Remv os-prober [1.79ubuntu2]

-s simmuliert das Entfernen der Pakete nur.

Und dann auch noch hiflreich:

root@ubuntu:/# dpkg-query -S $(which update-grub)
grub2-common: /usr/sbin/update-grub

und

root@ubuntu:/# dpkg-query -S $(which grub-mkconfig)
grub-common: /usr/sbin/grub-mkconfig

LG, Newubunti

EDIT:

Hatte ich noch vergessen und ist auch nicht unbedeutend für die Beantwortung der Ausgangsfrage:

root@ubuntu:/# debconf-show grub-pc
  grub-pc/install_devices:
  grub-pc/install_devices_empty: false
  grub-pc/hidden_timeout: true
  grub2/linux_cmdline_default: quiet splash
  grub-pc/disk_description:
  grub2/update_nvram: true
  grub-pc/install_devices_failed: false
  grub2/no_efi_extra_removable: false
  grub-efi/install_devices_failed: false
  grub-pc/postrm_purge_boot_grub: false
  grub-efi/partition_description:
  grub-pc/timeout: 0
  grub-pc/chainload_from_menu.lst: true
  grub2/linux_cmdline:
  grub-pc/kopt_extracted: false
  grub-efi/install_devices_disks_changed:
  grub2/unsigned_kernels_title:
  grub-pc/mixed_legacy_and_grub2: true
  grub-efi/install_devices:
  grub2/kfreebsd_cmdline:
  grub-efi/install_devices_empty: false
  grub-pc/install_devices_disks_changed:
  grub2/unsigned_kernels:
  grub-pc/partition_description:
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/install_devices_failed_upgrade: true
root@ubuntu:/# 

Also im Endeffekt sollte folgendes helfen:

sudo apt purge grub2-common grub-pc grub-pc-bin grub-efi-amd64-bin shim*
sudo apt install efibootmgr  # verhindert automatisches Entsorgen durch autopurge
sudo apt autopurge 

Am besten erst mal mit der Option -s testen, nicht dass mehr deinstalliert wird, als gesund.

grub-common und os-prober können bleiben, damit man immer noch grub-mkconfig ausführen kann.

UlfZibis schrieb:

Also im Endeffekt sollte folgendes helfen:

sudo apt purge grub2-common grub-pc grub-pc-bin grub-efi-amd64-bin shim*
... 

Im Ergebnis führt das zum gewünschten Ergebnis.

Allerdings hat man dann nicht die exakt gleiche Systemkonstellation, wie nach ubiquity -b. Um das exakt gleiche Ergebnis zu erhalten, müsste man die debconf-Ausgaben vergleichen und auch eine Auge darauf haben, was eigentlich mit den Hooks bezüglich initrd bzw. Kernel-Images passiert.

Sind die in beiden Konstellationen also einmal mit und einmal ohne ubiquity -b alle exakt gleich?

Nur so als Denksportaufgabe.

LG, Newubunti

Hej,

nur mal nebenbei: Ab 23.04 ist ubiquityraus!

Gruß black tencate

black_tencate schrieb:

nur mal nebenbei: Ab 23.04 ist ubiquityraus!

Gab es den Satz irgendwo im 10er-Pack? 😈

In den offiziellen Release-Notes steht:

• The legacy installer is still available in case of issues with the new installer.

LG, Newubunti

Hej Newubunti,

Newubunti schrieb:

... Gab es den Satz irgendwo im 10er-Pack? 😈

hmm, hätte ich jetzt so von Dir nicht erwartet, aber naja.

In den offiziellen Release-Notes steht:

• The legacy installer is still available in case of issues with the new installer.

aha

ubuntu@ubuntu:~$ ubiquity
Der Befehl 'ubiquity' wurde nicht gefunden, kann aber installiert werden mit:
sudo apt install ubiquity
ubuntu@ubuntu:~$ sudo apt install ubiquity
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  bogl-bterm ncurses-term ubiquity-frontend-debconf
Die folgenden NEUEN Pakete werden installiert:
  bogl-bterm ncurses-term ubiquity ubiquity-frontend-debconf
0 aktualisiert, 4 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 3695 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 25.9 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Holen:1 http://archive.ubuntu.com/ubuntu lunar/main amd64 ncurses-term all 6.4-2 [272 kB]
Holen:2 http://archive.ubuntu.com/ubuntu lunar/main amd64 bogl-bterm amd64 0.1.18-20ubuntu1 [31.4 kB]
Holen:3 http://archive.ubuntu.com/ubuntu lunar/main amd64 ubiquity-frontend-debconf amd64 23.04.8 [447 kB]
Holen:4 http://archive.ubuntu.com/ubuntu lunar/main amd64 ubiquity amd64 23.04.8 [2944 kB]
Es wurden 3695 kB in 4 s geholt (950 kB/s).
Vorkonfiguration der Pakete ...
Vormals nicht ausgewähltes Paket ncurses-term wird gewählt.
(Lese Datenbank ... 210790 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../ncurses-term_6.4-2_all.deb ...
Entpacken von ncurses-term (6.4-2) ...
Vormals nicht ausgewähltes Paket bogl-bterm wird gewählt.
Vorbereitung zum Entpacken von .../bogl-bterm_0.1.18-20ubuntu1_amd64.deb ...
Entpacken von bogl-bterm (0.1.18-20ubuntu1) ...
Vormals nicht ausgewähltes Paket ubiquity-frontend-debconf wird gewählt.
Vorbereitung zum Entpacken von .../ubiquity-frontend-debconf_23.04.8_amd64.deb .
..
Entpacken von ubiquity-frontend-debconf (23.04.8) ...
Vormals nicht ausgewähltes Paket ubiquity wird gewählt.
Vorbereitung zum Entpacken von .../ubiquity_23.04.8_amd64.deb ...
Entpacken von ubiquity (23.04.8) ...
ncurses-term (6.4-2) wird eingerichtet ...
bogl-bterm (0.1.18-20ubuntu1) wird eingerichtet ...
ubiquity-frontend-debconf (23.04.8) wird eingerichtet ...
ubiquity (23.04.8) wird eingerichtet ...
Created symlink /etc/systemd/system/graphical.target.wants/ubiquity.service → /l
ib/systemd/system/ubiquity.service.
Trigger für man-db (2.11.2-1) werden verarbeitet ...
ubuntu@ubuntu:~$ ubiquity
Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 92, in <module>
    main()
  File "/usr/bin/ubiquity", line 79, in main
    raise AttributeError('No frontend available; tried %s' %
AttributeError: No frontend available; tried gtk_ui, kde_ui
ubuntu@ubuntu:~$ 

Gruß black tencate

black_tencate schrieb:

• The legacy installer is still available in case of issues with the new installer.

aha

Das ist ein Extra-Image. Direktlink:

https://cdimage.ubuntu.com/releases/23.04/release/ubuntu-23.04-desktop-legacy-amd64.iso

Mit dem neuen Snap-Flutter - wie das Canonical nennt - kannst Du im Moment noch nicht mal bequem Ubuntu neben Ubuntu installieren. Das geht nur über "Manuell". Einen Schalter zum Deaktivieren der Bootloader-Installation sehe ich im Moment noch nicht, soll sich aber laut diesem Beitrag im Quellcode von subiquity befinden, das da im Hintergrund werkelt.

Ich gehe mal davon aus, dass die Kinderkrankheiten bis zur nächsten LTS (grob) behoben sein werden. Warten wir es ab!

LG, Newubunti

Newubunti schrieb:

Um das exakt gleiche Ergebnis zu erhalten, müsste man die debconf-Ausgaben vergleichen und auch eine Auge darauf haben, was eigentlich mit den Hooks bezüglich initrd bzw. Kernel-Images passiert.

Guter Hinweis, den Du am 1. März noch nachgeschoben hattest. Hier das Ergebnis für das bearbeitete Ubuntu 20.04:

$ apt list grub-common grub2-common grub-pc grub-pc-bin grub-efi-amd64-bin grub-efi-amd64 grub-efi-amd64-signed shim shim-signed os-prober
Auflistung... Fertig
grub-common/focal-updates,now 2.04-1ubuntu26.16 amd64  [installiert]
grub-efi-amd64-bin/focal-updates 2.06-2ubuntu14.1 amd64
grub-efi-amd64-bin/focal-updates 2.06-2ubuntu14.1 i386
grub-efi-amd64-signed/focal-updates 1.187.3~20.04.1+2.06-2ubuntu14.1 amd64
grub-efi-amd64/focal-updates 2.06-2ubuntu14.1 amd64
grub-efi-amd64/focal-updates 2.06-2ubuntu14.1 i386
grub-pc-bin/focal-updates 2.04-1ubuntu26.16 amd64
grub-pc/focal-updates 2.04-1ubuntu26.16 amd64
grub2-common/focal-updates 2.04-1ubuntu26.16 amd64
os-prober/focal,now 1.74ubuntu2 amd64  [installiert]
shim-signed/focal-updates 1.40.9+15.7-0ubuntu1 amd64
shim/focal-updates 15.7-0ubuntu1 amd64
$ sudo debconf-show grub-pc
$

Und nun das Gleiche aus einem mit ubiquity -b installierten Ubuntu 22.04:

$ apt list grub-common grub2-common grub-pc grub-pc-bin grub-efi-amd64-bin grub-efi-amd64 grub-efi-amd64-signed shim shim-signed os-prober
Auflistung… Fertig
grub-common/jammy-updates,now 2.06-2ubuntu7.1 amd64  [installiert]
grub-common/jammy-updates 2.06-2ubuntu7.1 i386
grub-efi-amd64-bin/jammy-updates 2.06-2ubuntu14.1 amd64
grub-efi-amd64-bin/jammy-updates 2.06-2ubuntu14.1 i386
grub-efi-amd64-signed/jammy-updates 1.187.3~22.04.1+2.06-2ubuntu14.1 amd64
grub-efi-amd64/jammy-updates 2.06-2ubuntu14.1 amd64
grub-efi-amd64/jammy-updates 2.06-2ubuntu14.1 i386
grub-pc-bin/jammy-updates,now 2.06-2ubuntu7.1 amd64  [installiert]
grub-pc/jammy-updates,now 2.06-2ubuntu7.1 amd64  [installiert]
grub2-common/jammy-updates,now 2.06-2ubuntu7.1 amd64  [installiert]
grub2-common/jammy-updates 2.06-2ubuntu7.1 i386
os-prober/jammy,now 1.79ubuntu2 amd64  [installiert]
shim-signed/jammy-updates 1.51.3+15.7-0ubuntu1 amd64
shim/jammy-updates 15.7-0ubuntu1 amd64

$ sudo debconf-show grub-pc
  grub-pc/chainload_from_menu.lst: true
  grub2/update_nvram: true
  grub2/kfreebsd_cmdline_default: quiet splash
  grub2/unsigned_kernels_title:
  grub-pc/install_devices_disks_changed:
  grub2/kfreebsd_cmdline:
  grub2/linux_cmdline:
  grub-pc/hidden_timeout: true
  grub-efi/partition_description:
  grub-efi/install_devices:
  grub-efi/install_devices_disks_changed:
  grub-pc/partition_description:
  grub-pc/install_devices_failed: false
  grub2/linux_cmdline_default: quiet splash
  grub-pc/install_devices:
  grub2/no_efi_extra_removable: false
  grub-pc/mixed_legacy_and_grub2: true
  grub2/unsigned_kernels:
  grub-pc/disk_description:
  grub-pc/timeout: 0
  grub-pc/kopt_extracted: false
  grub-pc/install_devices_empty: false
  grub-efi/install_devices_failed: false
  grub-pc/postrm_purge_boot_grub: false
  grub-pc/install_devices_failed_upgrade: true
  grub-efi/install_devices_empty: false

Folgendes passierte dann nach einem Kernel-Update auf 20.04 (Auffälliges und Unterschiede habe ich markiert):

$ sudo apt upgrade
[.....]
Die folgenden NEUEN Pakete werden installiert:
  grub-gfxpayload-lists grub-pc grub-pc-bin grub2-common
  linux-headers-5.15.0-71-generic linux-hwe-5.15-headers-5.15.0-71
  linux-image-5.15.0-71-generic linux-modules-5.15.0-71-generic
  linux-modules-extra-5.15.0-71-generic
[.....]
Creating config file /etc/default/grub with new version
Quelldatei `/etc/default/grub'
Quelldatei `/etc/default/grub.d/init-select.cfg'
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-5.15.0-71-generic
Linux-Abbild gefunden: /boot/vmlinuz-5.15.0-60-generic
initrd-Abbild gefunden: /boot/initrd.img-5.15.0-60-generic
Linux-Abbild gefunden: /boot/vmlinuz-5.13.0-27-generic
initrd-Abbild gefunden: /boot/initrd.img-5.13.0-27-generic
Windows Boot Manager auf /dev/sda1@/EFI/Microsoft/Boot/bootmgfw.efi gefunden
Ubuntu 16.04.7 LTS (16.04) auf /dev/sda11 gefunden
Ubuntu 16.04.7 LTS (16.04) auf /dev/sda13 gefunden
Ubuntu 22.04.2 LTS (22.04) auf /dev/sda15 gefunden
Ubuntu 18.04.1 LTS (18.04) auf /dev/sda17 gefunden
Ubuntu 18.04.6 LTS (18.04) auf /dev/sda9 gefunden
Startmenüeintrag für UEFI-Firmware-Einstellungen wird hinzugefügt
abgeschlossen
[.....]

$ apt list grub-common grub2-common grub-pc grub-pc-bin grub-efi-amd64-bin grub-efi-amd64 grub-efi-amd64-signed shim shim-signed os-prober
Auflistung... Fertig
grub-common/focal-updates,now 2.04-1ubuntu26.16 amd64  [installiert]
grub-efi-amd64-bin/focal-updates 2.06-2ubuntu14.1 amd64
grub-efi-amd64-bin/focal-updates 2.06-2ubuntu14.1 i386
grub-efi-amd64-signed/focal-updates 1.187.3~20.04.1+2.06-2ubuntu14.1 amd64
grub-efi-amd64/focal-updates 2.06-2ubuntu14.1 amd64
grub-efi-amd64/focal-updates 2.06-2ubuntu14.1 i386
grub-pc-bin/focal-updates,now 2.04-1ubuntu26.16 amd64  [Installiert,automatisch]
grub-pc/focal-updates,now 2.04-1ubuntu26.16 amd64  [Installiert,automatisch]
grub2-common/focal-updates,now 2.04-1ubuntu26.16 amd64  [Installiert,automatisch]
os-prober/focal,now 1.74ubuntu2 amd64  [installiert]
shim-signed/focal-updates 1.40.9+15.7-0ubuntu1 amd64
shim/focal-updates 15.7-0ubuntu1 amd64
$ sudo debconf-show grub-pc
  grub-pc/install_devices_empty: false
  grub-pc/mixed_legacy_and_grub2: true
  grub2/linux_cmdline_default: quiet splash
  grub-efi/install_devices_empty: false
  grub-pc/hidden_timeout: true
  grub-efi/partition_description:
  grub-pc/partition_description:
  grub-efi/install_devices_failed: false
  grub-pc/install_devices_failed_upgrade: true
  grub2/unsigned_kernels:
  grub2/kfreebsd_cmdline:
  grub-pc/timeout: 0
  grub-pc/chainload_from_menu.lst: true
  grub2/unsigned_kernels_title:
  grub-pc/install_devices_disks_changed:
* grub-efi/install_devices: /dev/disk/by-id/ata-HGST_HTS545050A7E680_TMA55C3J3G3YNM-part1
  grub-pc/disk_description:
  grub-pc/install_devices:
  grub-pc/install_devices_failed: false
  grub2/kfreebsd_cmdline_default: quiet splash
  grub-pc/kopt_extracted: false
  grub2/no_efi_extra_removable: false
  grub-efi/install_devices_disks_changed:
  grub-pc/postrm_purge_boot_grub: false
  grub2/update_nvram: true
  grub2/linux_cmdline:
$