Lieber Thorben,
vielen Dank, dass du uns so lange ertragen hast. Du hast unsere Arbeit leichter und bunter gemacht. Ohne dich hätten wir sicher schon die Raufasertapete mehr als einmal von der Wand gefressen.
Vielen Dank für deine Unterstützung in technischer und menschlicher Weise! Wir werden dich NIE vergessen!
Liebe Grüße
Die zwei „Dicken“
Mit FreeBSD 13 lässt sich die native ZFS Verschlüsselung direkt nutzen. Dabei muss man zwischen einem komplett verschlüsselten zpool und verschlüsselten Datasets unterscheiden. Hat man einen komplett verschlüsselten zpool, bedeutet es nicht, dass damit auch alle Datasets verschlüsselt sein müssen, so wie es auch nicht bedeutet, dass man Datasets nur verschlüsseln kann, wenn auch der komplette ZFS Pool verschlüsselt ist.
Wer nun also sein FreeBSD auf Version 13 gehoben hat, möchte ggf. einzelne ZFS Datasets verschlüsseln. In der Praxis trifft dieses sicher oft auf Jails zu. Diese liegen in der Regel in eigenen ZFS Datasets und mit dem folgenden Beispiel lassen sich diese und andere Datasets nachträglich verschlüsseln.
Im Beispiel haben wir den Pool zroot und in diesem das Dataset varta. Weder der zpool noch das Dataset sind aktuell verschlüsselt:
root@testtest:/ # zfs list zroot/varta NAME USED AVAIL REFER MOUNTPOINT zroot/varta 100M 12.0G 100M /zroot/varta root@testtest:/ # zfs get encryption zroot/varta NAME PROPERTY VALUE SOURCE zroot/varta encryption off default root@testtest:/ #
Aktiviert man bei ZFS Dinge wie Komprimierung oder Deduplikation sind diese immer nur ab dem Moment der Aktivierung und bis genau zur Deaktivierung aktiv. Dieses hat viele Vorteile aber auch Nachteile. So greift dieses nur für Daten, welche neu geschrieben werden. Möchte man dieses nachträglich auf alle Daten anwenden, muss man die Daten komplett neu schreiben. Dieses lässt sich am einfachsten und schnellsten per zfs send und zfs receive erledigen. Wenn man also sein bestehendes Dataset verschlüsseln möchte, dann geht dieses faktisch nicht, sondern man erstellt im Grunde ein neues verschlüsseltes Dataset und schreibt seine Daten dort rein.
Bevor wir nun mit der Migration starten, müssen wir noch eine Kleinigkeit wissen.... Zum Verschlüsseln der Daten benötigen wir noch ein Geheimnis, einen Schlüssel/Key. Dieser kann bei ZFS in verschiedenster Form und an verschiedensten Orten liegen. So könnte man den Key zur Ver- und Entschlüsselung auf einen USB-Stick ablegen. Nur wenn dieser auch im System steckt usw. usw.. Der eingängigste Weg ist sicher ein Passphrase welches per prompt abgefragt wird. Will man sein verschlüsseltes Dataset öffnen, wird man nach einem Kennwort gefragt, welches sich das System bis zum nächsten Reboot oder dem manuellen "Schließen" des Datasets merkt. Diesen Zustand wollen wir nach der Migration, in diesem Beispiel, erreichen.
Zur Verdeutlichung erstellen wir kurz ein neues verschlüsseltes Dataset:
root@testtest:/ # zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt zroot/enc-beispiel Enter passphrase: Re-enter passphrase:
Damit haben wir ein neues Dataset welches sofort benutzt werden kann, alles was wir in dieses legen, ist verschlüsselt.
root@testtest:/ # zfs list zroot/enc-beispiel NAME USED AVAIL REFER MOUNTPOINT zroot/enc-beispiel 200K 12.0G 200K /zroot/enc-beispiel
Schauen wir in die Optionen des Datasets ist die Verschlüsselung aktiviert und der Schlüssel wird per Prompt vom Benutzer abgefragt:
root@testtest:/ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel NAME PROPERTY VALUE SOURCE zroot/enc-beispiel encryption aes-256-gcm - zroot/enc-beispiel keylocation prompt local zroot/enc-beispiel keyformat passphrase -
Wie immer wird das Dataset sofort eingehangen:
root@testtest:/ # mount |grep enc-beispiel zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)
Nach einem reboot, wird das Dataset nicht automatisch eingehangen, da ZFS den Schlüssel nicht hat. Wenn wir es nun einhängen und ZFS anweisen, den Schlüssel zu laden (Option -l), dann werden wir zur Eingabe des Kennwortes aufgefordert und können das Dataset im Anschluss wieder nutzen:
root@testtest:~ # mount | grep enc-beispiel root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel NAME PROPERTY VALUE SOURCE zroot/enc-beispiel encryption aes-256-gcm - zroot/enc-beispiel keylocation prompt local zroot/enc-beispiel keyformat passphrase - root@testtest:~ # mount | grep enc-beispiel root@testtest:~ # zfs mount -l zroot/enc-beispiel Enter passphrase for 'zroot/enc-beispiel': root@testtest:~ # mount | grep enc-beispiel zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)
Gut gut... So viel zu den Basics. Damit ist nun auch klar, warum im nun folgenden zfs send / zfs reveive Beispiel, der Schlüssel einen Umweg nehmen wird. Denn durch das pipen kommen wir so schlecht an die stdin heran, um das Passphrase einzugeben ;-) Wir sind nun also wieder zurück bei unserem unverschlüsselten Dataset varta und dessen Migration in einen verschlüsselten Zustand. Als erstes legen wir nun das gewünschte Passphrase in einer Datei ab:
root@testtest:~ # echo 'Tolles-Kennwort' > /kennwort.txt root@testtest:~ # cat /kennwort.txt Tolles-Kennwort
Ebenfalls erstellen wir einen snapshot vom Dataset varta, welchen wir zur Migration nutzen:
root@testtest:~ # zfs snapshot zroot/varta@migration root@testtest:~ # zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT zroot/varta@migration 0B - 100M -
Jetzt kann die eigentliche Migration starten:
root@testtest:~ # zfs send zroot/varta@migration | zfs receive -F -o encryption=on -o keyformat=passphrase -o keylocation=file:///kennwort.txt zroot/en-varta root@testtest:~ # zfs list zroot/varta zroot/en-varta NAME USED AVAIL REFER MOUNTPOINT zroot/en-varta 100M 11.8G 100M /zroot/en-varta zroot/varta 100M 11.8G 100M /zroot/varta root@testtest:~ # zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT zroot/en-varta@migration 112K - 100M - zroot/varta@migration 0B - 100M -
Das ist schnell und einfach, oder? Natürlich liegt nun noch immer das Passphrase offen in einer Datei im root des Systems. Wir müssen nun also den Ort des Schlüssels auf prompt ändern:
root@testtest:~ # zfs get keylocation zroot/en-varta NAME PROPERTY VALUE SOURCE zroot/en-varta keylocation file:///kennwort.txt local root@testtest:~ # zfs set keylocation=prompt zroot/en-varta root@testtest:~ # zfs get keylocation zroot/en-varta NAME PROPERTY VALUE SOURCE zroot/en-varta keylocation prompt local
Damit kann die Datei mit dem Passphrase gelöscht werden:
root@testtest:~ # rm /kennwort.txt
Ebenfalls kann nun auch das unverschlüsselte Dataset weg:
root@testtest:~ # zfs destroy -r zroot/varta
Wenn man nun möchte, kann man das neue Dataset natürlich an die gleiche Stelle mounten oder direkt komplett gleich dem alten benennen:
root@testtest:~ # zfs rename zroot/en-varta zroot/varta
Damit ist die Migration fertig und das Dataset ist verschlüsselt:
root@testtest:~ # zfs list zroot/varta NAME USED AVAIL REFER MOUNTPOINT zroot/varta 100M 11.9G 100M /zroot/varta root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/varta NAME PROPERTY VALUE SOURCE zroot/varta encryption aes-256-gcm - zroot/varta keylocation prompt local zroot/varta keyformat passphrase -
Es sieht nun nach sehr viel aus, ist es aber nicht und es lässt sich sogar automatisieren.
Fragen? Dann fragen!
Wie ich lernen durfte, haben verschiedene Geschirrspüler ein ähnliches Problem mit der Dichtung vom Pumpentopf. Die Hersteller einer Spülmaschine erfinden diese nicht für jedes Modell komplett neu. Ähnlich wie zum Beispiel bei Autoherstellern, greifen sie auf unterschiedliche Grundkomponenten zurück. Gibt es mit so einem Teil Probleme, betrifft es direkt viele verschiedene Geräte.
So scheint es ebenfalls mit meiner Spülmaschine zu sein. Nach ein paar Jahren im Einsatz, verzieht sich scheinbar der Pumpentopf in der Maschine leicht. Grade genug um etwas Wasser zu verlieren. Nicht so viel, dass die Küche komplett im Wasser versinkt, aber so viel, dass der Sensor anspricht und die Maschine mit dem Fehlercode E-15 stehen bleibt. Die Maschine beginnt in so einem Fall "panisch" das Wasser aus der Maschine zu pumpen und hört damit auch nicht mehr auf.
Die Reparatur ist recht einfach. Es gibt einen fertigen Reparatursatz für dieses Problem, welcher sich einfach bei Amazon kaufen lässt: https://amzn.to/3kHALRS
Wenn man nicht komplett zwei linke Hände hat, ist die komplette Reparatur in 15 Minuten durch.
Diese zusätzliche Dichtung sorgt nun dafür, dass wenn sich der Pumpentopf durch die Hitze etwas verzieht, es weiterhin dicht ist. Ob die eigene Maschine bereits mit dieser Dichtung kommt, erkennt man an einem kleinen Aufkleber links in der Türe, auf welchem ein großes R zu sehen ist.
Reparatur einer Spülmaschine... Auch mal etwas anders, hm?
Vor einigen Monaten habe ich ein neues Labornetzteil aus China gekauft. AliExpress Labornetzteil - RIDEN RD6006 DC POWER SUPPLY
Bisher arbeitet dieses Gerät vor sich hin und hat auch bereits einige kWh abgeleistet. Als Fazit... Das Netzteil tut seinen Job, die grüne Schraubklemme verwechselt man schnell mit PE, ist aber zum Laden von Akkus und am Oszilloskop kann man sehr gut einiges "switching noise" erkennen. Wenn man sich dessen bewusst ist, gibt es kaum etwas, was man gegen dieses Netzteil sagen kann. Preis / Leistung ist einfach unschlagbar!
Selbst die Ladefunktion für Akkus funktioniert tadellos, wenn auch manuell. Das Netzteil erkennt nicht selbstständig den Akku, sondern man muss dem Netzteil sagen, was es tun muss.
In der Zwischenzeit habe ich es ebenfalls etwas "missbraucht", um ein paar alte Blei gel Akkus wieder zu beleben. Dabei hat sich leider ein kleines Problemchen ergeben.... Mir ist eine Schottky-Diode geplatzt, genauer die S10C110D vom RIDEN RD6006. Diese ist auf dem Board mit D12 gekennzeichnet. Wenn man in die >>Specs<< dieser Diode schaut, sieht es so aus, als wenn sie eine Art Verpolungsschutz beim Akkulader ist. Nun ist mir nicht bewusst aufgefallen, dass ich hier etwas verpolt habe. Die kaputte Diode (vor allem mit den Leistungsdaten) sagen dazu etwas anders :-D
Nun wollte ich schnell Ersatz bestellen, leider konnte ich nichts Passendes finden. Klar ich hätte hier und da etwas kombinieren können, nur wollte ich dieses nicht.
Hangzhou Ruideng Technology Co., Ltd. bietet zur Kontaktaufnahme WeChat (15868147353) an. Wie ich lernen durfte, ist es nicht ganz trivial, als nicht Festlandchinese WeChat zu nutzen. Ich meine inzwischen zusätzliche Kontaktmöglichkeiten gefunden zu haben. Durch die Unterstützung eines Bekannten (DANKE JOST), lief es irgendwann und ich konnte das Unternehmen RD Tech in China darüber erreichen.
Der Support dabei war extrem gut. Schnell, super freundlich, sehr hilfsbereit und kompetent.
Zusammen mit dem Support konnten wir das komplette Labornetzteil durch testen und sicherstellen, dass wirklich nur diese eine Diode def. ist. Absoluter Service von RD Tech, eigentlich wollte ich nur nach dem Ersatzteil fragen. Dieses habe ich am Ende ebenfalls bekommen, sogar direkt 5 Stück davon und noch zwei Sicherungen als Reserve (da hat wohl jemand den Verdacht, ich könnte noch mehr kaputt machen). Zahlen musste ich nur 3€ für den Versand.
Der Versand von China zu mir hat natürlich ein paar Tage gedauert, heute ich alles angekommen.
Inzwischen verbaut und das Netzteil ist wieder voll funktionsfähig!
Ich möchte hier noch einmal ganz besonders den Support von RD Tech hervorheben. Englisch war überhaupt kein Problem (was mir vorher etwas Sorgen bereitete), es hat sich wirklich jemand knapp 2 Stunden Zeit genommen um mir bei meinem Problem zu helfen und derjenige war wirklich daran interessiert, mein Problem zu lösen. Alles für 0€. Ich habe kostenlos viel mehr Ersatzteile bekommen, als ich eigentlich haben wollte. Ich musste, wie schon erwähnt, nur den Versand bezahlen. Wenn ich dann also noch mal etwas Werbung machen darf: YouTube link
Firmware und BIOS Updates müssen hin und wieder sein um Fehler zu beseitigen oder Unterstützung für neuere Komponenten zu erhalten. Dieses unter Linux zu tun, war nicht immer einfach. Oft bieten die Hersteller nur Software für DOS oder vielleicht sogar noch Windows an. Der Support für Linux war eher selten vorhanden und beschränkte sich dabei eher auf Serversysteme. Wenn ich früher an meinem Linux Arbeitsplatz oder Notebook Firmware oder BIOS Updates installieren wollte, musste ich oft eine Festplatte aus der Kiste nehmen, Windows installieren, die nötigen Treiber für die Hardware installieren und mir dann die Herstellertools besorgen, um der Firmware ein Update zu verpassen. So macht es keinen Spaß und ist viel zu aufwendig.
Vor knapp 5 Jahren haben ein paar Gnome Entwickler zusammen mit dem Hersteller Dell mit der Entwicklung an einem Update Tool fwupd gestartet. Über dieses Tool gibt es nun die Möglichkeit Firmwareupdates auf einem einheitlichen Weg und über eine einheitliche Basis zu verteilen und zu installieren. Klar steht und fällt es weiterhin mit den Hardware Herstellern. Diese müssen sich nun aber nicht mehr um das eigentliche Tooling und den Support am Betriebssystem Linux kümmern, sondern müssen nur ihre eigentlichen Firmwareupdates in einem Online-Repository zur Verfügung stellen.
Jetzt kann jeder Linux Benutzer über einen sehr einfachen Weg Firmware und BIOS Updates einspielen. Für Gnome und KDE gibt es dazu sogar eine GUI, über die CLI geht es genau so einfach.
fwupd kann dabei im Hintergrund als Daemon laufen, täglich nach neuen Firmwareupdates suchen und diese installieren oder zur Installation ankündigen.
Nun möchte ich es mir nicht nehmen lassen, mit euch einen kurzen Ablauf eines solchen Firmwareupdates auf der CLI durchzuführen. Also... Los geht es!
Testgerät dafür ist ein Lenovo ThinkPad, um zu sehen welche Hardware von fwupd erkannt und unterstützt wird, hilft folgender Aufruf:
root@errorlap:/home/kernel# fwupdmgr get-devices
20N588101
│
├─Thunderbolt Controller:
│ Device ID: 149dca4a469318aced513ec818b67eeac46753e9
│ Summary: Unmatched performance for high-speed I/O
│ Current version: 20.00
│ Vendor: Lenovo (TBT:0x0109)
│ GUIDs: 52265728-359a-574c-9a6a-a23d3b1f952d ← TBT-01091804-native
│ f117e89e-a75f-5f33-9e8e-c4aded9cbadf ← TBT-01091804-native-controller0-0
│ Device Flags: • Internal device
│ • Updatable
│ • Requires AC power
│ • Device stages updates
│
├─SAMSUNG MZVLB256HB88-000L7:
│ Device ID: f2759da7fe8e0388c5f3601cb072f837b1070b03
│ Summary: NVM Express Solid State Drive
│ Current version: 4M2QEXH7
│ Vendor: Samsung Electronics Co Ltd (NVME:0x144D)
│ Serial Number: S4ELN88N881038
│ GUIDs: 6e54c992-d302-59ab-b454-2d26ddd63e6d ← NVME\VEN_144D&DEV_A808&REV_00
│ 47335265-a509-51f7-841e-1c94911af66b ← NVME\VEN_144D&DEV_A808
│ 1b3b43f9-e0b0-5978-a89b-6f0866124233 ← SAMSUNG MZVLB256HBHQ-000L7
│ Device Flags: • Internal device
│ • Updatable
│ • Requires AC power
│ • Needs a reboot after installation
│ • Device is usable for the duration of the update
│
├─System Firmware:
│ Device ID: 6150dd1f7291b0709289ab8a53cc85a17e117ef2
│ Current version: 0.1.65
│ Minimum Version: 0.0.1
│ Vendor: LENOVO (DMI:LENOVO)
│ GUID: 603baf73-b997-45b5-86b4-2f981a008e18
│ Device Flags: • Internal device
│ • Updatable
│ • Requires AC power
│ • Needs a reboot after installation
│ • Cryptographic hash verification is available
│ • Device is usable for the duration of the update
│
├─UEFI Device Firmware:
│ Device ID: c0649684d1e6688e8147fac95eccb4fdd18d05aa
│ Current version: 192.64.1551
│ Minimum Version: 0.0.1
│ Vendor: DMI:LENOVO
│ GUID: 2c0665e2-fdbd-495e-b8e4-69d92b9c119a
│ Device Flags: • Internal device
│ • Updatable
│ • Requires AC power
│ • Needs a reboot after installation
│ • Device is usable for the duration of the update
│
├─UEFI Device Firmware:
│ Device ID: 489f23b2ba9c1adf3e9f9f10598c98ba5c6bba39
│ Current version: 0.1.19
│ Minimum Version: 0.1.19
│ Vendor: DMI:LENOVO
│ GUID: 38ea6335-29ca-417b-8cd4-6b4e5e866f92
│ Device Flags: • Internal device
│ • Updatable
│ • Requires AC power
│ • Needs a reboot after installation
│ • Device is usable for the duration of the update
│
└─UEFI Device Firmware:
Device ID: 88cf266a57697921241cc5f4b412c3f1b5a07780
Current version: 1.1.8
Minimum Version: 0.0.1
Vendor: DMI:LENOVO
GUID: a6634b3a-f446-42f0-a0b2-62c7d4dcb694
Device Flags: • Internal device
• Updatable
• Requires AC power
• Needs a reboot after installation
• Device is usable for the duration of the update
Wie man sehen kann, ist bei diesem Gerät der Support recht weitreichend. Damit fwupd in seinem "Katalog" überprüfen kann, ob es für eine bestimmte Hardware ein Update gibt, muss man diese kurz aktualisieren. Dieses geht direkt mit einem: fwupdmgr refresh --force
Natürlich merkt fwupd auch selbst, wenn sein Datenstand alt ist und bietet ein Update vor der Überprüfung an.
root@errorlap:/home/kernel# fwupdmgr get-updates
Firmware metadata has not been updated for 30 days and may not be up to date.
Update now? (Requires internet connection) [y|N]: y
Fetching metadata https://cdn.fwupd.org/downloads/firmware.xml.gz
Downloading… [***************************************]
Fetching signature https://cdn.fwupd.org/downloads/firmware.xml.gz.asc
Successfully downloaded new metadata: 5 local devices supported
• Thunderbolt Controller has the latest available firmware version
• SAMSUNG MZVLB256HBHQ-000L7 has the latest available firmware version
• UEFI Device Firmware has the latest available firmware version
• UEFI Device Firmware has no available firmware updates
20N588101
│
├─System Firmware:
│ │ Device ID: 6150dd1f7291b0709289ab8a53cc85a17e117ef2
│ │ Current version: 0.1.65
│ │ Minimum Version: 0.0.1
│ │ Vendor: LENOVO (DMI:LENOVO)
│ │ GUID: 603baf73-b997-45b5-86b4-2f981a008e18
│ │ Device Flags: • Internal device
│ │ • Updatable
│ │ • Requires AC power
│ │ • Supported on remote server
│ │ • Needs a reboot after installation
│ │ • Cryptographic hash verification is available
│ │ • Device is usable for the duration of the update
│ │
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │ New version: 0.1.70
│ │ Remote ID: lvfs
│ │ Summary: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │ License: Proprietary
│ │ Size: 25,1 MB
│ │ Vendor: Lenovo Ltd.
│ │ Flags: is-upgrade
│ │ Description: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware Version 1.70
│ │
│ │ The computer will be restarted automatically after updating BIOS completely. Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│ │
│ │ This stable release fixes the following issues:
│ │
│ │ • Fixed an issue where Setup Settings Capture/Playback Utility (SRSETUP) causes 191 error if Secure Boot Mode is reset to Setup Mode and
│ │
│ │ Supervisor Password is changed at the same time.
│ │
│ │ • Fixed an issue where system might hang at POST when Thunderbolt3 Dock Gen2 is attached.
│ │
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │ New version: 0.1.69
│ │ Remote ID: lvfs
│ │ Summary: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │ License: Proprietary
│ │ Size: 25,1 MB
│ │ Vendor: Lenovo Ltd.
│ │ Flags: is-upgrade
│ │ Description: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware 1.69
│ │
│ │ The computer will be restarted automatically after updating BIOS completely. Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│ │
│ │ This stable release fixes the following issues:
│ │
│ │ • This time BIOS release has no impact for Linux users.
│ │
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │ New version: 0.1.68
│ │ Remote ID: lvfs
│ │ Summary: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │ License: Proprietary
│ │ Size: 25,1 MB
│ │ Vendor: Lenovo Ltd.
│ │ Flags: is-upgrade
│ │ Description: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware 1.68
│ │
│ │ The computer will be restarted automatically after updating BIOS completely. Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│ │
│ │ This stable release fixes the following issues:
│ │
│ │ • Fixed an issue where keyboard language settings could not be applied by Setup Settings Capture/Playback Utility (SRSETUP).
│ │ • Fixed an issue where WWAN device firmware update process might fail when Thunderbolt BIOS Assist Mode is set to Enabled.
│ │ • Fixed an issue where BIOS might generate 0288 beep error.
│ │ • Support for TCO Certified Logo shown on POST screen.
│ │
│ ├─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ │ New version: 0.1.67
│ │ Remote ID: lvfs
│ │ Summary: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ │ License: Proprietary
│ │ Size: 25,1 MB
│ │ Vendor: Lenovo Ltd.
│ │ Flags: is-upgrade
│ │ Description: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware 1.67
│ │
│ │ • Fixed an issue where Intel TXT Feature cannot be Enabled in ThinkPad Setup
│ │
│ │ when Device Guard is Enabled.
│ │
│ │ • Fixed an issue where system might hang at POST when attach USB C to DisplayPort
│ │
│ │ Adapter cable.
│ │
│ │ • Support Lid Sensor Enable/Disable in ThinkPad Setup - Config - Power.
│ │ • Updated the CPU microcode.
│ │
│ │ Note: Above update will show "Self-Healing BIOS backup progressing ... xx %"
│ │
│ │ massage on screen during BIOS update process.
│ │
│ │ • Updated the Arrow key behavior in ThinkPad Setup with Graphical Setup UI.
│ │
│ │ Security issues fixed:
│ │
│ │ • CVE-2020-0548
│ │ • CVE-2020-0549
│ │ • CVE-2020-0543
│ │
│ └─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS for Machine types: 20N2, 20N3, 20N4, 20N5, 20N6, 20N7, 20Q9, 20QH, 20RH, 20RJ) System Update:
│ New version: 0.1.66
│ Remote ID: lvfs
│ Summary: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC System Firmware
│ License: Proprietary
│ Size: 25,1 MB
│ Vendor: Lenovo Ltd.
│ Flags: is-upgrade
│ Description: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC (W-BIOS) System Firmware 1.66
│
│ The computer will be restarted automatically after updating BIOS completely. Do NOT turn off your computer or remove the AC adaptor while update is in progress.
│
│ This stable release fixes the following issues:
│
│ • Fixed an issue where system performance may not set correctly.
│
│ Some new functionality has also been added:
│
│ • Updated Network Boot Device and Boot conditions.
│
│ Note: Above update will show "Self-Healing BIOS backup progressing ... xx %" massage on screen during BIOS update process.
│
└─UEFI Device Firmware:
│ Device ID: c0649684d1e6688e8147fac95eccb4fdd18d05aa
│ Current version: 192.64.1551
│ Minimum Version: 0.0.1
│ Vendor: DMI:LENOVO
│ GUID: 2c0665e2-fdbd-495e-b8e4-69d92b9c119a
│ Device Flags: • Internal device
│ • Updatable
│ • Requires AC power
│ • Supported on remote server
│ • Needs a reboot after installation
│ • Device is usable for the duration of the update
│
└─ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s Corporate ME Update:
New version: 192.71.1681
Remote ID: lvfs
Summary: Lenovo ThinkPad T490/P43s/T590/P53s Corporate ME Firmware
License: Proprietary
Size: 12,2 MB
Details: https://pcsupport.lenovo.com/de/en/search?query=N2IRM29W
Vendor: Lenovo Ltd.
Flags: is-upgrade
Description: Lenovo ThinkPad T490/ThinkPad P43s/ThinkPad T590/ThinkPad P53s/ThinkPad T490 HC ME Corporate Firmware Version: (12.0.71.1681)
This stable release fixes the following issues:
• Fixed an issue wherein BIOS returned wrong vaue following an Intel CSME update to 12.0.64.1551.
• Fixed an issue wherein IntelR AMT SUT couldn't change from CCMP to TKIP through WebUI
• Fixed an issue wherein there was Failure to update IntelR CSME software from version 1910.12.0.1239 to 1932.12.0.1298 after OS recovery reset complete.
• Fixed an issue wherein System stayed on S3 state and IntelR AMT PowerState shows 乬on乭.
Security issues fixed:
• CVE-2020-12356
• CVE-2020-12303
• CVE-2020-12297
• CVE-2020-8752
• CVE-2020-8749
• CVE-2020-8746
• CVE-2020-8747
• CVE-2020-8754
• CVE-2020-8751
• CVE-2020-8760
• CVE-2020-8756
• CVE-2020-8757
• CVE-2020-8705
• CVE-2020-8745
• CVE-2020-8744
• CVE-2020-8753
Wie man sehen kann, gibt es ein Update für UEFI Device Firmware von Version 192.64.1551 auf Version 192.71.1681. Zusätzlich werden vom Hersteller der Hardware über die Device Flags Vorbedinungen angegeben, die erfüllt sein müssen, um das Update einspielen zu können. Als Beispiel sollte der Notebook am Netzteil angeschlossen sein und nach dem Update ist ein Reboot nötig um die neue Firmware zu nutzen..... Ebenfalls wird mir direkt aufgelistet, welche Änderungen dieses Firmwarupdate mit sich bringt.
Um das Firmwareupdate nun zu installieren ist folgendes nötig:
root@errorlap:/home/kernel# fwupdmgr update • SAMSUNG MZVLB256HB88-000L7 has the latest available firmware version • System Firmware has the latest available firmware version Upgrade available for UEFI Device Firmware from 192.64.1551 to 192.71.1681 20N588101 must remain plugged into a power source for the duration of the update to avoid damage. Continue with update? [Y|n]: y Downloading 192.71.1681 for UEFI Device Firmware... Decompressing… [***************************************] Authenticating… [***************************************] Updating UEFI Device Firmware… ] Scheduling… [***************************************] Successfully installed firmware • UEFI Device Firmware has the latest available firmware version • UEFI Device Firmware has no available firmware updates • UEFI Device Firmware has no available firmware updates An update requires a reboot to complete. Restart now? [y|N]:
Beim Reboot begegnet mir in meinem Fall das UEFI BIOS des Notebooks mit den Informationen, dass es nun die nötigen Firmwareupdates durchführt (ich habe dazu ein paar Bilder gemacht). Ist alles durchgelaufen und das System wieder hochgefahren, kann ich alles mit folgendem Befehl prüfen:
root@errorlap:/home/kernel# fwupdmgr get-updates • SAMSUNG MZVLB256HB88-000L7 has the latest available firmware version • System Firmware has the latest available firmware version • UEFI Device Firmware has the latest available firmware version • UEFI Device Firmware has the latest available firmware version • UEFI Device Firmware has no available firmware updates • UEFI Device Firmware has no available firmware updates ________________________________________________ Devices that have been updated successfully: • System Firmware (0.1.65 → 0.1.70) • UEFI Device Firmware (192.64.1551 → 192.71.1681) Uploading firmware reports helps hardware vendors to quickly identify failing and successful updates on real devices. Upload report now? (Requires internet connection): 0. Do not upload reports at this time, but prompt again for future updates 1. Do not upload reports, and never ask to upload reports for future updates 2. Upload reports just this one time, but prompt again for future updates 3. Upload reports this time and automatically upload reports after completing future updates 3 Successfully uploaded 1 report
Das Update ist gut gelaufen und ich habe die letzte Version installiert!
Wie beschrieben, steht und fällt es mit den Herstellern der Hardware. Was helfen könnte diese zur Mitarbeit zu bewegen ist, wie so oft, nachfragen. Sollte eure Hardware also nicht "mitspielen", einfach mal eine kurze Nachricht an den Support schicken und fragen, warum die denn nicht zusammen mit fwupd arbeiten. FreeBSD oder generell BSD Benutzer wird die Information freuen, dass es recht aktuell Bemühungen gibt, fwupd ebenfalls auf BSD zu portieren: https://fosdem.org/2021/schedule/event/porting_fwupd_to_the_bsd/
Wer nun noch Fragen hat, bitte fragen :)
