Schön, daß sich Google darüber freut, daß mein Android-Gerät neue Funktionen hat …
…blöd nur, daß ich die neuen Funktionen weder haben noch nutzen möchte und sie trotzdem ungefragt installiert wurden.
In Outlook können einzelne Nachrichten im msg-Format abgespeichert und so z.B. auch im Dateisystem abgelegt werden. Leider stellt man spätestens beim Öffnen fest, daß die Dateien im Binärformat vorliegen und man Outlook benötigt, um die Inhalte lesen zu können.
Hier kommt das Perl-Modul “Email::Outlook::Message” ins Spiel, welches neben einer Bibliothek zur Verarbeitung der Dateien auch das Kommandozeilenprogramm “msgconvert” mitbringt, mit dessen Hilfe auch ohne Perl-Kenntnisse die von Outlook gespeicherten Dateien ins RFC822-Format gewandelt werden können.
Unter Debian wird das Paket “libemail-outlook-message-perl” installiert, dann kann mittels
$ msgconvert test.msg
eine unter dem Dateinamen “test.msg” abgelegte Nachricht konvertiert werden. Sofern keine entsprechende Option gesetzt wurde, wird der exportierbare Inhalt unter dem Quell-Dateinamen mit der Endung “.eml” gespeichert.
Zum gelegentlichen Musik- und/oder Radiohören steht im Büro eine Philips MCM2050 Mini-Stereoanlage, die auch über einen USB-Steckplatz verfügt.
Leider war das Gerät nicht dazu zu bewegen, den eingesteckten USB-Stick zu verwenden bzw. die Dateien auf diesem zu lesen, egal, welches der in der Bedienungsanleitung aufgeführten Formate verwendet wurde:
USB- oder Speicher-Dateiformat:
FAT12, FAT16, FAT32
(Abschnittsgröße: 512 Byte)
Kurz vorm Aufgeben kam beim Blick in die GNOME Laufwerksverwaltung noch ein rettender Gedanke, denn diese zeigte als Partitionerung “GUID-Partitionstabelle” an. Und tatsächlich: nach einer Neupartitionierung mit MBR funktionierte der Stick dann auch wie erwartet.
Manchmal bin ich tatsächlich froh, Mails wie
Von: news@updates.ubisoft.com
Betreff: Aktualisierung unserer Nutzungsbedingungen und DatenschutzerklärungHallo,
Wir aktualisieren die Nutzungsbedingungen und Datenschutzerklärung von Ubisoft.
…
Wenn du diesen Änderungen nicht zustimmen willst, kannst du die Schließung deines Ubisoft-Kontos auf der Website zur Kontoverwaltung beantragen.
…
zu erhalten, die an einen schon lange nicht mehr genutzten Account erinnern, den man entsorgen kann.
Schön auch, daß direkt in der Mail der Link enthalten ist, mit dessen Hilfe man eine Account-Schließung beantragen kann, ohne sich erst durch einen Irrgarten hindurchfinden zu müssen.
Leider funktioniert die Schließung auch bei Ubisoft nicht direkt, sondern nur mit der inzwischen meist üblichen Verzögerungstaktik, so daß ich mir’s zumindest in diesem Zeitraum nochmal anders überlegen könnte.
Nach der BIOS-Aktualisierung eines ASRock DeskMini X300 auf die seit 16. Januar 2026 angebotene Version 2.20 erschien beim folgenden Systemstart eine Warnmeldung:
Laut Changelog sollte das Update im Wesentlichen zwei Punkte verändern:
- Update AMD AM4 AGESA Combov2 PI 1.2.0.10
- Update Secure Boot Key (2023 KEK/DB/PK)
Somit lag der Gedanke nahe, daß ASRock mit Hinzufügen des ab 2023 gültigen Keysgleichzeitig den seit 2011 gültigen Secure Boot Key entfernt hatte, so daß es - je nach Kombination aus Betriebssystem und fehlender Signatur - zu der “Secure Boot Violation” kommt.
Erste Anlaufstelle war der “Secure Boot"-Beitrag des Debian Wikis, der im Abschnitt “I have shim and the Debian bootloader installed, and with secure boot enabled the machine fails to boot!” auf auf das mögliche Fehlen genau dieses Schlüssels und die damit verbundenen Probleme hinweist.
Mit Hilfe von “mokutil” lassen sich die in der Datenbank vorhandenen Schlüssel überprüfen und der “UEFI CA 2011”-Schlüssel war weiterhin auf dem System vorhanden:
$ mokutil --db | grep UEFI
Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
Somit konnte ein fehlender Schlüssel nicht der Grund des veränderten Bootverhaltens sein und weitere Recherche war angesagt.
Den entscheidenden Hinweis lieferte die Ausgabe von “efibootmgr” - zum ursprünglichen Boot-Eintrag hatte sich noch ein zweiter Eintrag gesellt und dieser wurde auch zum Starten verwendet:
$ efibootmgr
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000
Boot0000* debian HD(...)/File(\EFI\DEBIAN\SHIMX64.EFI)
...
Boot0001* debian HD(...)/File(\EFI\DEBIAN\GRUBX64.EFI)0000424f
...
Wie in der Ausgabe zu sehen, verwendet der Eintrag “Boot0001” den Pfad “\EFI\DEBIAN\GRUBX64.EFI” und da “GRUBX64.EFI” nicht mit dem “UEFI CA 2011”-Schlüssel signiert ist, kommt es zu der “Secure Boot Violation”. Der ursprüngliche (korrekte) Eintrag ist “Boot0000” mit dem Pfad “\EFI\DEBIAN\SHIMX64.EFI”, der mit “SHIMX64.EFI” auch den von Microsoft signierten Bootloader verwendet.
Nach Änderung der Bootreihenfolge startete das System wieder ohne zu Meckern mit Secure Boot:
$ mokutil --sb-state
SecureBoot enabled
Hintergrundinformationen zur grundlegenden Thematik liefert der Mircosoft Support-Beitrag “Ablauf des Windows Secure Boot-Zertifikats und Updates der Zertifizierungsstelle”.