vor ein paar Tagen habe ich den Leap 16.0 neu installiert und nach Installation von Patches und Updates habe ich heute überrascht entdeckt Discover meldet zwei Update von Microsoft bezüglich UEFI:
Microsoft UEFI CA
“3rd Party UEFI Signature Database …”
Microsoft UEFI dbx
“List of forbidden signatures …”
Hier im Forum gibt es mehrere Threads, die sich mit diesen MS-UEFI-Updates befassen und ich habe verstanden, die kann beruhigt installieren.
Trotzdem habe ich dazu 2 Fragen:
Soll man diese Updates auch installieren, wenn man kein Windows OS auf dem POC ht?
Wieso werden sie von Discover gemeldet und nicht von Mirylin?
Greift Discover zu besonderen Repositories, die nicht in Repoliste hinterlegt sind?
Vielleicht weil Secure Boot in UEFI nicht aktiv ist … Stimmt es?
Da ich gerne Discover deinstallieren und nur mit einem Paketmanager (Myrlin bzw. zypper) arbeiten möchte, gibt es die Möglichkeit das fwupd-Daemon in Myrlin zu “implementieren”?
Auf der Webseite https://fwupd.org/ habe ich jedenfalls kein rpm-Repo gefunden.
Hallo,
Antwort erst jetzt, da das Login ins Forum lange gesperrt war und dazwischen musste ich ein paar Stunden außerhalb der Wohnung arbeiten.
Zuerst poste ich hier erneut das Ergebnis von sudo systemctl status fwupd
nach Update von Microsoft UEFI CA und Neustart, weil es sich eesentlich geändert:
:~> sudo systemctl status fwupd
● fwupd.service - Firmware update daemon
Loaded: loaded (/usr/lib/systemd/system/fwupd.service; static)
Active: active (running) since Fri 2026-07-10 17:45:04 CEST; 39min ago
Invocation: ad1bdde35d604f569698a4a852788a3a
Docs: https://fwupd.org/
Main PID: 2954 (fwupd)
Tasks: 4 (limit: 38081)
CPU: 1.044s
CGroup: /system.slice/fwupd.service
└─2954 /usr/libexec/fwupd/fwupd
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:tcti:src/tss2-tcti/tctildr-dl.c:149:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:tcti:src/tss2-tcti/tcti-device.c:455:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tpm0: Die Operation ist nicht erlaubt
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:tcti:src/tss2-tcti/tctildr-dl.c:149:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:tcti:src/tss2-tcti/tcti-device.c:455:Tss2_Tcti_Device_Init() Failed to open specified TCTI device file /dev/tcm0: Datei oder Verzeichnis nicht gefunden
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:tcti:src/tss2-tcti/tctildr-dl.c:149:tcti_from_file() Could not initialize TCTI file: libtss2-tcti-device.so.0
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:tcti:src/tss2-tcti/tctildr-dl.c:263:tctildr_get_default() No standard TCTI could be loaded
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:tcti:src/tss2-tcti/tctildr.c:477:tctildr_init_context_data() Failed to instantiate TCTI
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: ERROR:esys:src/tss2-esys/esys_context.c:71:Esys_Initialize() Initialize default tcti. ErrorCode (0x000a000a)
Jul 10 17:45:04 EliteDesk-Leap fwupd[2954]: 15:45:04.862 FuMain fwupd 2.0.20 ready for requests (locale de_DE.UTF-8)
Jul 10 17:45:04 EliteDesk-Leap systemd[1]: Started Firmware update daemon.
geppino@EliteDesk-Leap:~>
Hat UEFI BIOS das Update nicht richtig “verdaut”?
Oder vielleicht ist der Grund der ERRORS die Unmöglichkeit die UEFI-Kapsel zu aktualisieren? Sie weiter unten.
~> su
Passwort:
EliteDesk-Leap:/home/geppino # fwupdmgr get-history
WARNUNG: Aktualisierung der UEFI-Kapsel nicht verfügbar oder in der Firmware-Einrichtung aktiviert
Siehe https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported für weitere Informationen.
Hewlett-Packard HP EliteDesk 800 G1 SFF
│
├─UEFI CA:
│ │ Gerätekennung: 5bc922b7bd1adb5b6f99592611404036bd9f42d0
│ │ Vorherige Version: 2011
│ │ Aktualisierungsstatus: Erfolg
│ │ Zuletzt geändert: 2026-07-09 21:16:49
│ │ GUID: 26f42cba-9bf6-5365-802b-e250eb757e96
│ │ Geräte-Bitschalter: • Internes Gerät
│ │ • Aktualisierbar
│ │ • Unterstützt auf dem entfernten Server
│ │ • Benötigt einen Neustart nach der Installation
│ │ • Signierte Nutzdaten
│ │ • Kann für die Emulation markieren
│ │
│ └─Secure Boot Signature Database Konfigurationsaktualisierung:
│ Neue Version: 2023
│ Gegenstellenkennung: lvfs
│ Veröffentlichungskennung: 116503
│ Zusammenfassung: UEFI Secure Boot Signature Database
│ Lizenz: Proprietär
│ Größe: 10,0 KB
│ Erstellt: 2025-04-29 00:00:00
│ Dringlichkeit: Hoch
│ Geprüft: 2026-04-20 00:00:00
│ Distribution: ubuntu 25.10
│ Alte Version: 2011
│ Version[fwupd]: 2.0.16
│ Geprüft: 2025-10-17 00:00:00
│ Distribution: fedora 42 (workstation)
│ Alte Version: 2011
│ Version[fwupd]: 2.0.16
│ Geprüft: 2025-09-17 00:00:00
│ Distribution: fedora 42 (workstation)
│ Alte Version: 2011
│ Version[fwupd]: 2.0.16
│ Geprüft: 2025-07-24 00:00:00
│ Distribution: nixos 25.11
│ Alte Version: 2011
│ Version[fwupd]: 2.0.12
│ Anbieter: Microsoft
│ Veröffentlichungsbitschalter: • Vertrauenswürdige Nutzdaten
│ • Vertrauenswürdige Metadaten
│ Beschreibung:
│ This updates the 3rd Party UEFI Signature Database (the "db") to the latest release from Microsoft.It also adds the latest OptionROM UEFI Signature Database update.
│ Prüfsumme: 4bdf420ad7e5ddde89d7a66ffe1b4328927059d56551f03afac855c4ed80f6c3
│
└─UEFI dbx:
│ Gerätekennung: 362301da643102b9f38477387e2193e57abaa590
│ Vorherige Version: 20230501
│ Installationsdauer: 17 Sekunden
│ Aktualisierungsstatus: Erfolg
│ Zuletzt geändert: 2026-07-10 11:13:14
│ GUID: f8ba2887-9411-5c36-9cee-88995bb39731
│ Geräte-Bitschalter: • Internes Gerät
│ • Aktualisierbar
│ • Unterstützt auf dem entfernten Server
│ • Benötigt einen Neustart nach der Installation
│ • Das Gerät ist während der Dauer der Aktualisierung nutzbar
│ • Nur Versionsaktualisierungen sind erlaubt
│ • Signierte Nutzdaten
│ • Kann für die Emulation markieren
│
└─Secure Boot dbx Konfigurationsaktualisierung:
Neue Version: 20260402
Gegenstellenkennung: lvfs
Veröffentlichungskennung: 143971
Zusammenfassung: UEFI Secure Boot Forbidden Signature Database
Variante: x64
Lizenz: Proprietär
Größe: 24,6 KB
Erstellt: 2025-09-02 00:00:00
Dringlichkeit: Hoch
Anbieter: Linux Foundation
Veröffentlichungsbitschalter: • Vertrauenswürdige Nutzdaten
• Vertrauenswürdige Metadaten
Beschreibung:
This updates the list of forbidden signatures (the "dbx") to the latest release from Microsoft.
Some insecure bootloaders were added, due to security vulnerabilities that allowed an attacker to bypass UEFI Secure Boot. The additional entries were from:
• Baramanudi Management Suite
• EAZ EasyFix
• Finland Matriculation Examination Board
• NTC IT ROSA Linux
• PC-Doctor
• Spyrus WTGCreator
• WhiteCanyon blancco
• Some ancient shim releases for OpenSUSE, Oracle and Red Hat
Probleme: 616257
CVE-2026-8863
Prüfsumme: 9edea8bc287bf9bf4659856b28cf421f330eb2f658c163eab0a03512a98c0e78
Der PC verfügt über ein BIOS VON 2013 (v02.18) und wird nicht updated, obwohl in BIOS eine monatliche automatische Prüfung eingestellt ist.
Aus meiner Sicht wäre ein mal im Jahr ausreichend.
fwupdmgr kann UEFIs und auch die Firmware von verschiedener Hardware updaten. Das ist z.B. die Hardware die generell bei mir am Laptop von fwupdmgr erkannt wird:
user@xyz:~> sudo fwupdmgr update
Geräte mit der neuesten verfügbaren Firmware-Version:
• UEFI CA
• UEFI dbx
Geräte ohne verfügbare Firmware-Aktualisierungen:
• LINPUS
• Quanta NB4
• SSD 870 EVO 1TB
• System Firmware
• Windows Production PCA
• -spi
• Database
• Internal SPI Controller (BIOS)
• KEK CA
• Key Exchange Key
• Option ROM UEFI CA
• SBAT
Du bekommst also beim Update angezeigt wofür Updates durchgeführt werden sollen. Wenn Updates verfügbar sind sollte das das selbe sein, was auch Discover anzeigt. Vermutlich nutzt Discover ja auch fwupdmgr als backend in dem Fall.
Im Grunde sollten die Firmware-Updates ja problemlos durchlaufen, aber sollte irgendwas schieflaufen (Stromausfall, Akkudefekt am Laptop, etc.) hilft dir unter Umständen auch kein Snapper-Snapshot mehr. Deshalb würde ich vor solchen Updates generell ein Backup aller meiner Daten auf dem Gerät machen. Mit Datensicherung ist die Fehlerbehebung in so einem Fall dann auch viel entspannter
Ja, es sind 2 BIOS-Updates verfügbar, und auch auf der Festplatte gespeichert, aber nur als exe-Datei und ich habe Windows nicht mehr, weil Win 11 auf diesen PC nicht installierbar ist.
Warum habe ich sie nie implementiert? Weil ich “aus der alten Schule bin”, nach dem Motto “Don’t change a running system, if not necessary”. Und ich hatte kein Problem. Darüber hinaus hat die Linux-Welt bis vor ein paar Jahre einen Bogen um die Microsoft Security Policy gemacht … Das war wenigstens meine Wahrnehmung.
Ich habe das Readme gelesen. Bei der exe-Dateien handelt es sich eigentlich um ein “Kontainer” von Informationen und den jeweiligen Updates in DOS. Es reicht also die Update aus der exe-Dateien zu extrahieren und auf einen USB-Stick zu kopieren. Beim Booten kann man sie dann einspielen lassen, nachdem man in BIOS galangt.
Ich kann also die Update erst durchführen lassen, nachdem (falls) ich Win 11 in VirtualBox installiert habe. Ich habe nämlich mal einen Artikel gelesen, in dem beschrieben wird, wie man in einer virtuellen Maschine die Win11-Hardware-Prüfung umgegangen werden kann.
Das heißt aber dann nicht vor Ende Oktober! Früher geht aus privaten Gründen nicht. Darüber hinaus will ich ich zuerst mit dem Leap 16.0 klar kommen. Es gibt noch viele Aspekte, die ich nicht verstehe bzw. mir komisch vorkommen.
Das nächste SHIM-Update aller SecureBoot-fähigen Linuxdistributionen wird mit dem Stammzertifikat “Microsoft Corporation KEK 2K CA 2023” unterzeichnet sein. Somit muss vor dem nächsten SHIM-Update dieses neue Stammzertifikat im KEK installiert sein. Ansonsten startet der Rechner nach dem SHIM-Update bei aktiviertem UEFI Secure Boot nicht mehr die Linux-Installation.
Weshalb behältst du Discover nicht nur für fwupd und die Verwaltung (falls verwendet) von Flatpaks? So handhabe ich es.
Dazu müsstest du nur das Paket discover6-backend-packagekit deinstallieren und für eine erneute Installation sperren.
Hallo @tomm_fa,
ich hatte auch die Idee gehabt, aber gedacht, wenn ich die anderen Repos in Discover deaktiviere, würden sie auch Myrlin nicht mehr zur Verfügung stehen.
Darüber hinaus, wie werde informiert, dass Updates und/oder Patches zu installieren sind, wenn die Repos in Discover deaktiviert sind?
Verfügt Myrlin oder das Leap-Sytem über ein ähnlicher Dienst, dessen Symbol (icon) man in die Fensterleiste einfügen kann, wie früher mit Yast?
Da hast du recht, wurde aber auch von niemandem empfohlen. Es ist ein Unterschied, die RPM-Repositorien in Discover zu deaktivieren, oder discover6-backend-packagekit zu deinstallieren und zu sperren.
Da ist mir zurzeit nichts bekannt. Du wolltest Discover doch ohnehin komplett deinstallieren, dann hättest du dazu ebenfalls keine Benachrichtigungen erhalten.
Es ist aber kein Aufwand einmal am Tag, in der Woche, oder im Monat Myrlyn oder ein zypper up aufzurufen/auszuführen.
Wie schon erwähnt, dazu ist mir derzeit nichts bekannt.
Was früher mit YaST(2) möglich war, bezog sich sowieso nur auf YOU (YaST Online Update) und damit wurden nur Patches angezeigt und installiert.
Was anderes war es dann, als es mit PackageKit losging und es Applets wie plasma*-pk-updates und andere vorherige gab.
