Debian 12 Grub Update - Falsche Shim Signatur

Registriert
Juli 2019
Beiträge
190
Hallo,
ich war gerade dabei Debian 12 in einer VM in Proxmox zu testen, weil ich vor hatte, meine Server auf Debian 12 umzustellen.

Nach der Installation und nach den ersten Updates lief alles super. Bis ich die Grub und Shim Upgrades gemacht hatte.
Das Update lief ohne Fehlermeldungen durch.

Nach einem Reboot bootete die VM nicht mehr. Fehlermeldung: Falsche Shim Signatur, zuerst Kernel laden etc.
Erst wenn ich Secure-Boot ausstelle, bootet die Kiste wieder. Das ist aber nicht Sinn der Sache.

Ich weiß nicht was ich davon halten soll. Speziell zu diesem Problem habe ich nichts gefunden. Vielleicht liegt es an der Kombination zwischen Proxmox und Debian 12 Client. Proxmox ist auf dem neuesten Stand.

Das schreckt mich son bisschen ab Debian 12 einzusetzen...

Diese Updates stehen aus, wenn ich die durchführe, kein Boot mehr.
1702314172990.png

LOG vom Upgrade die zu diesem Fehler führen
Code:
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Die folgenden Pakete werden aktualisiert (Upgrade):
  grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub2-common shim-helpers-amd64-signed shim-signed shim-signed-common shim-unsigned
9 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 7.274 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 8.192 B Plattenplatz freigegeben.
Möchten Sie fortfahren? [J/n]
Holen:1 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 grub2-common amd64 2.06-13+pmx1 [613 kB]
Holen:2 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 grub-efi-amd64 amd64 2.06-13+pmx1 [45,7 kB]
Holen:3 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 grub-efi-amd64-bin amd64 2.06-13+pmx1 [1.578 kB]
Holen:4 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 grub-common amd64 2.06-13+pmx1 [2.707 kB]
Holen:5 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 grub-efi-amd64-signed amd64 1+2.06+13+pmx1 [1.260 kB]
Holen:6 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 shim-unsigned amd64 15.7-1+pmx1 [432 kB]
Holen:7 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 shim-helpers-amd64-signed amd64 1+15.7+1+pmx1 [302 kB]
Holen:8 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 shim-signed-common all 1.39+pmx1+15.7-1+pmx1 [12,9 kB]
Holen:9 http://download.proxmox.com/debian/pbs bookworm/pbs-no-subscription amd64 shim-signed amd64 1.39+pmx1+15.7-1+pmx1 [323 kB]
Es wurden 7.274 kB in 0 s geholt (24,4 MB/s).
Vorkonfiguration der Pakete ...
(Lese Datenbank ... 39740 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../0-grub2-common_2.06-13+pmx1_amd64.deb ...
Entpacken von grub2-common (2.06-13+pmx1) über (2.06-13+deb12u1) ...
Vorbereitung zum Entpacken von .../1-grub-efi-amd64_2.06-13+pmx1_amd64.deb ...
Entpacken von grub-efi-amd64 (2.06-13+pmx1) über (2.06-13+deb12u1) ...
Vorbereitung zum Entpacken von .../2-grub-efi-amd64-bin_2.06-13+pmx1_amd64.deb ...
Entpacken von grub-efi-amd64-bin (2.06-13+pmx1) über (2.06-13+deb12u1) ...
Vorbereitung zum Entpacken von .../3-grub-common_2.06-13+pmx1_amd64.deb ...
Entpacken von grub-common (2.06-13+pmx1) über (2.06-13+deb12u1) ...
Vorbereitung zum Entpacken von .../4-grub-efi-amd64-signed_1+2.06+13+pmx1_amd64.deb ...
Entpacken von grub-efi-amd64-signed (1+2.06+13+pmx1) über (1+2.06+13+deb12u1) ...
Vorbereitung zum Entpacken von .../5-shim-unsigned_15.7-1+pmx1_amd64.deb ...
Entpacken von shim-unsigned (15.7-1+pmx1) über (15.7-1) ...
Vorbereitung zum Entpacken von .../6-shim-helpers-amd64-signed_1+15.7+1+pmx1_amd64.deb ...
Entpacken von shim-helpers-amd64-signed (1+15.7+1+pmx1) über (1+15.7+1) ...
Vorbereitung zum Entpacken von .../7-shim-signed-common_1.39+pmx1+15.7-1+pmx1_all.deb ...
Entpacken von shim-signed-common (1.39+pmx1+15.7-1+pmx1) über (1.39+15.7-1) ...
Vorbereitung zum Entpacken von .../8-shim-signed_1.39+pmx1+15.7-1+pmx1_amd64.deb ...
Entpacken von shim-signed:amd64 (1.39+pmx1+15.7-1+pmx1) über (1.39+15.7-1) ...
grub-common (2.06-13+pmx1) wird eingerichtet ...
shim-signed-common (1.39+pmx1+15.7-1+pmx1) wird eingerichtet ...
No DKMS packages installed: not changing Secure Boot validation state.
grub-efi-amd64-bin (2.06-13+pmx1) wird eingerichtet ...
shim-unsigned (15.7-1+pmx1) wird eingerichtet ...
grub-efi-amd64-signed (1+2.06+13+pmx1) wird eingerichtet ...
grub2-common (2.06-13+pmx1) wird eingerichtet ...
grub-efi-amd64 (2.06-13+pmx1) wird eingerichtet ...
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-15-amd64
Found initrd image: /boot/initrd.img-6.1.0-15-amd64
Found linux image: /boot/vmlinuz-6.1.0-13-amd64
Found initrd image: /boot/initrd.img-6.1.0-13-amd64
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done
shim-helpers-amd64-signed (1+15.7+1+pmx1) wird eingerichtet ...
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
shim-signed:amd64 (1.39+pmx1+15.7-1+pmx1) wird eingerichtet ...
x86_64-efi wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
No DKMS packages installed: not changing Secure Boot validation state.
 

Anhänge

  • 1702314122732.png
    1702314122732.png
    61,9 KB · Aufrufe: 109
Danke für die Links. Die bin ich schon durch. Hat leider alles nicht funktioniert. Ich würde aber auch gerne verstehen, wieso das Verhalten nach dem Update auftritt. Das kann nicht normal sein.
 
Dann würde ich eher im Debian-Forum direkt posten.
 
Okay. Ne Frage aus Interesse. Wieso hast du so viele Mini-Server bzw. Raspis? Wieso nicht virtualisieren?
 
Möglicherweise hilft ein:
Bash:
update-grub

Sah beim überfliegen nicht so aus, als wäre das beim Update gemacht worden.

Und mir brennt auch eine Frage auf der Seele:
Wozu eigentlich Secure Boot? Unter Linuxern wird sowas eigentlich als reine Schikane von Microsoft angesehen, um Linux "auszusperren".

Ist Dein Anwendungsfall so sicherheitskritisch?
 
Anonymous User schrieb:
Okay. Ne Frage aus Interesse. Wieso hast du so viele Mini-Server bzw. Raspis? Wieso nicht virtualisieren?
Ich habe auch Proxmox da. ;) Alles für unterschiedliche Zwecke. Über die Jahre angewachsen.

Raspis:
  • Pi-Zero sind nicht angeschlossen
  • 8x Pi4 sind ein Kubernetes Cluster -> 1 Manager, 6 Nodes und 1 Client
  • 1 Pi3 läft 24/7 die anderen sind für Kleinkram
Raspis waren mal als Entschleunigung gedacht. ;) 2019 als ich die Raspis gekauft habe, habe ich ein Open MPI Cluster aufgesetzt. Da wollte ich die alten Projekte aus dem Studium darauf laufen lassen. Bis auf die Berechnung des Zusammenstoßes der Milchstraße und Andromeda-Galaxie liefen die anderen Projekte. Nun werden die Raspis für Kubernetes eingesetzt.

Irgendwann kam ich an die I/O Grenzen bei den Raspis und es kamen die NUCs dazu. Da laufen um die 13 Datenbanken (verteilt auf 3x PostgreSQL 16), ELK-Stack, Messaging Broker, Memcached Cluster -> alles was I/O produziert läuft auf den NUCs. Meine NUCs haben alle je 32GB RAM, was bei den Sachen, die ich mache vom Vorteil ist. Auf einem der NUCs läuft auch Proxmox. Da spiele ich ein wenig mit Terraform und Coder rum. Vielleicht mache ich aus 4 NUCs ein Proxmox Cluster.

Nur ein NUC läuft 24/7 und die anderen sind aus bis ich wieder was machen will. Mit Ubuntu Server und vielen Docker Containern. Da überlege ich auf Proxmox umzustellen. Sehe aber kein Vorteil Da ich mit dem jetziges Setup optimal die Ressourcen nutzen kann. Proxmox mit VMs wäre ein wenig Overhead.

D.h. alles, was ich da habe ich meine Spielwiese um sich mit diversen Sachen nach Lust, Laune und Zeit zu beschäftigen und zu vertiefen.
 
_anonymous0815_ schrieb:
Möglicherweise hilft ein:
Bash:
update-grub
Habe ich versucht. Auch update-initramfs.

_anonymous0815_ schrieb:
Und mir brennt auch eine Frage auf der Seele:
Wozu eigentlich Secure Boot? Unter Linuxern wird sowas eigentlich als reine Schikane von Microsoft angesehen, um Linux "auszusperren".

Ist Dein Anwendungsfall so sicherheitskritisch?
Weil es bisher auch lief und nicht geschadet hat... Ich mein ein riesen Sicherheitsgewinn ist das nicht. Ich könnte auch verzichten. Wahrscheinlich werde ich einfach vorübergehend Secure boot deaktiveren und vielleicht behebt sich das "Problem" von selbst irgendwann.
 
  • Gefällt mir
Reaktionen: _anonymous0815_
Es gab die Tage eine Empfehlung von Debian, das updaten auszusetzen, da es einen Fehler mit der ext4 Implementation gab. Jetzt wurde Debian 12.4 veröffentlicht, möglicherweise gibt es irgendeinen Zusammenhang!

https://nitter.net/debian/status/1733559140914749547#m
 
  • Gefällt mir
Reaktionen: floTTes
Wenn er das heute gemacht hat, dann hat er schon die 12.4 Version drauf. ;) Hatte heute eine Debian 12 VM schon am Vormittag hochgezogen.
 
  • Gefällt mir
Reaktionen: _anonymous0815_
oicfar schrieb:
Ich habe auch Proxmox da. ;) Alles für unterschiedliche Zwecke. Über die Jahre angewachsen.

Raspis:
  • Pi-Zero sind nicht angeschlossen
  • 8x Pi4 sind ein Kubernetes Cluster -> 1 Manager, 6 Nodes und 1 Client
  • 1 Pi3 läft 24/7 die anderen sind für Kleinkram
Raspis waren mal als Entschleunigung gedacht. ;) 2019 als ich die Raspis gekauft habe, habe ich ein Open MPI Cluster aufgesetzt. Da wollte ich die alten Projekte aus dem Studium darauf laufen lassen. Bis auf die Berechnung des Zusammenstoßes der Milchstraße und Andromeda-Galaxie liefen die anderen Projekte. Nun werden die Raspis für Kubernetes eingesetzt.

Irgendwann kam ich an die I/O Grenzen bei den Raspis und es kamen die NUCs dazu. Da laufen um die 13 Datenbanken (verteilt auf 3x PostgreSQL 16), ELK-Stack, Messaging Broker, Memcached Cluster -> alles was I/O produziert läuft auf den NUCs. Meine NUCs haben alle je 32GB RAM, was bei den Sachen, die ich mache vom Vorteil ist. Auf einem der NUCs läuft auch Proxmox. Da spiele ich ein wenig mit Terraform und Coder rum. Vielleicht mache ich aus 4 NUCs ein Proxmox Cluster.

Nur ein NUC läuft 24/7 und die anderen sind aus bis ich wieder was machen will. Mit Ubuntu Server und vielen Docker Containern. Da überlege ich auf Proxmox umzustellen. Sehe aber kein Vorteil Da ich mit dem jetziges Setup optimal die Ressourcen nutzen kann. Proxmox mit VMs wäre ein wenig Overhead.

D.h. alles, was ich da habe ich meine Spielwiese um sich mit diversen Sachen nach Lust, Laune und Zeit zu beschäftigen und zu vertiefen.
Klingt sehr interessant. Die Aufteilung könnte sich auch positiv auf die Stromkosten auswirken. Ich fahre lieber mit einer relativ starken Maschine, die ich so stromsparend wie möglich konfiguriert habe mit Wasserkühlung und externen Thunderbolt PCIE Devices, die ich ein und ausschalten kann wie ich es brauche. Einige VMs und viele Docker Container, das macht den Overhead auch etwas wett :D. Läuft 16/7.

Ansonsten noch 2 Mini-Server für Backup und eine Firewall Appliance für OPNsense
Ergänzung ()

oicfar schrieb:
Jap. 8.1.3
Aber Secure Boot gabs doch schon vorher?
 
  • Gefällt mir
Reaktionen: oicfar
Anonymous User schrieb:
Klingt sehr interessant. Die Aufteilung könnte sich auch positiv auf die Stromkosten auswirken. Ich fahre lieber mit einer
Ich habe es so aufgebaut (insgesamt 4 Switche sind da), dass ich abhängig davon was ich mache zwischen 1 und 17 Rehnern hochfahren kann. 9 Raspis, 1 Jetson Nano und zwei switche verbrachen im Idle ~35 Watt und unter Volllast 67 Watt. Es geht.

Wenn ich mal Lasttest fahre, dann sind 8 Raspis und 3 NUC 3 2,5 Tage online.

Aber wie geschrieben: wenn ich was mache, schalte ich es ein.
Anonymous User schrieb:
relativ starken Maschine, die ich so stromsparend wie möglich konfiguriert habe mit Wasserkühlung und externen Thunderbolt PCIE Devices, die ich ein und ausschalten kann wie ich es brauche. Einige VMs und viele Docker Container, das macht den Overhead auch etwas wett :D. Läuft 16/7.
2019/2020 hatte ich überlegt ein Threadripper (16C/32T oder höher) hinzustellen um dann mit vielen VMs solche Spiele machen zu können. Aber es ist doch was anderes, wenn LAN Kabel da ist und dann noch Router für VLANs (das ist aktuell eine Baustelle) an Managed Switch hängt. Alles hat seine Vor-/Nachteile. ;)

Und durch die lagsameren Raspis ist man gezwungen auch mehr darauf zu achten was und wie man was macht um die bessere Performance rauszubekommen. Bei schneller Hardware fällt so was eher nicht auf oder erst unter sehr hoher Last.
Ergänzung ()

Anonymous User schrieb:
Jap. 8.1.3
Aber Secure Boot gabs doch schon vorher?
"This version is now compatible with Secure Boot. This security feature is designed to protect the boot process of a computer by ensuring that only software with a valid digital signature launches on a machine. Proxmox VE now includes a signed shim bootloader trusted by most hardware's UEFI implementations. This allows installing Proxmox VE in environments with Secure Boot active."
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Anonymous User
Alles klar, mein System x570 Plattform, Ryzen 9 5950x, 128 GB Ram kommt so auf 65W - 120W je nach Auslastung, das ist schon ein großer Unterschied. Wenn ich die dicken Grafikkarten dazuschalte, naja, kann man sich denken. Deswegen werden die Gpus auch extern betrieben, dank TB kann ich die im laufenden Betrieb ein- und ausschalten.

Vorher hatte ich einen Minisforum elite b550, war schon nicht schlecht. Vorallem hatte ich einen Verbrauch von 11 bis 22 Watt. War schon angenehm. Allerdings war ich eingeschränkt, irgendwann hat der RAM nicht mehr gereicht und ich wollte mit der Kiste auch bisschen zocken. Da meine Freundin und ich keinen separaten gaming PC kaufen wollten, habe ich meinen aktuellen Server gebaut mit den externen Gpus, die durchgereicht sind. 15M HDMI Kabel und USB Hub durch die Wohnung verlegt, hat meine Freundin am anderen Ende des Raumes ihren eigen virtuellen PC.

Ich muss nur zusehen, dass der Verbrauch weiter sinkt. Undervolten und mal sehen.
 
  • Gefällt mir
Reaktionen: oicfar
Ich habe mein Ryzen 7 5700G undervoltet. Wie viel es weniger verbraucht weiß ich nicht mehr. Schon 2 Jahre her, dass ich das gemessen habe. Aber es läuft stabiler unter Last auf allen Kernen.

Anonymous User schrieb:
Ich muss nur zusehen, dass der Verbrauch weiter sinkt. Undervolten und mal sehen.
Damit wird man denke ich nicht viel rausholen. Eher auf 65Watt runtergehen. Oder für normale Aktivität andere Hardware hinstellen.

Wie sieht es nun mit der Debian 12 VM aus? War die Info wg. 8.1.x hilfreich für dein Problem?
 
In Bios.

Um mir es zu vereinfachen, habe ich unter Windows den Ryzen Master laufen lassen. Man kann die Einstellungen ermitteln lassen. Dauerte ca. 1 Stunde bei mir. In der Zeit würde Windows paar Mal gebootet, da instabil. Als die finalen Werte da waren, habe ich Prime95 laufen lassen. Dabei stürzte Windows ab. Da swar Zeichen, dass die ubderwolt Werte nicht optimal waren. Dann habe ich pro Kern +2 (d.h. von z.B. -28 auf -26) erhöht. Und habe Prime noch Mal laufen lassen. Und wenn es nach 1h noch stabil war, habe ich es so belassen. Ich habe aber +2 nicht für jedes Kern addiert und getestet, sondern für alle 8. Ob es da bei dem einen oder anderen Kern der undervolt Wert nicht ganz optimal ist, ist mir wurscht. Aber gibt Tools, die das automatisch und genauer ermitteln als Ryzen Master. Aber die Zeit wollte ich nicht invertieren.

Ohne undervolting lief meine CPU (8C/16T) auf allen Kernen mit 4,5MHz. Nach dem undervolting komme ich mit meinem CPU Kühler auf ~4,6MHz. Und das stabil.
 
  • Gefällt mir
Reaktionen: knoxxi
Vielen Dank für die Info. 👍🏼
 
  • Gefällt mir
Reaktionen: oicfar
oicfar schrieb:
Wie sieht es nun mit der Debian 12 VM aus? War die Info wg. 8.1.x hilfreich für dein Problem?
Leider nein. Ich habe die aktuellste Proxmox Version und Secure Boot klappt mit der D12 VM nicht mehr nach dem Update. Wie gesagt, ich lasse das update aus und warte bis sich das Problem durch neue Updates evtl. behebt. Ansonsten wende ich mich direkt an das Debian Forum. Danke der Nachfrage :D

@Merkmal SSD in VM angebunden als scsi mit VirtIO scsi single Controller. Warum?
 
  • Gefällt mir
Reaktionen: oicfar
Zurück
Oben