Mein Datenhaufen zu IT und Elektronik Themen.

Autor: kernel-error (Seite 2 von 46)

FreeBSD & nginx jetzt mit HTTP/3 QUIC

Von QUIC habt ihr sicher alle schon gehört, seit knapp Mitte 2021 ist dieser neue Standard fertig und in einem recht einfach zu merkendem RFC 9000 beschrieben.

Im Grunde geht es darum, HTTP Verbindungen schneller zu machen und dabei sogar UDP zum Einsatz zu bringen. Nicht ganz korrekt ist es einfach eine Weiterentwicklung von SPDY.

Um zu testen, ob eine Webseite bereits HTTP/3 also QUIC unterstüzt kann ich euch http3check.net ans Herz legen. Diese gibt, wenn gewünscht, sogar noch ein paar Detailinformationen aus.

Wer sehen möchte, ob sein Browser QUIC „macht“, kann auch nginx.org nutzen. Steht oben „Congratulations! You’re connected over QUIC.“ Dann ist man ein Gewinner.

Die Konfiguration am NGINX ist wie immer sehr einfach und ein sehr gutes Beispiel findet sich direkt von nginx.

Mein NGINX spricht dieses nun ebenfalls, mal sehen ob es Probleme gibt.

Wechsel zur WordPress

Ich nutze Joomla seit 2006, als es aus Mambo hervorging. Die Datenbank und einige Plugins/Teils sind inzwischen also sehr alt und machen bei Versionssprüngen immer mehr Probleme. Den Wechsel vom CMS habe ich dennoch immer von mir weggeschoben, denn es macht viel Arbeit und für eine solch kleine Spielerei lohnt der Aufwand kaum. Da ich es inzwischen eh nur noch für einfache Blogeinträge nutze… Nun ich werde wohl in der nächsten Zeit auf WordPress wechseln. Damit wird es ebenfalls einen neuen RSS Feed geben und sicher wird ebenfalls viel Content verschwinden.

Lieber Thorben,

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“

FreeBSD 13 unverschlüsseltes ZFS Dataset/Jail zu verschlüsseltem ZFS Dataset/Jail

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!

RIDEN RD6006 und die def. Schottky-Diode S10C100D

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 😀

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

Bosch Geschirrspülmaschine und der Fehler E-15

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?

Firmware/BIOS Updates unter Linux können mit fwupd spaß machen!

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 🙂

TRIM für SSDs im ZFS Pool unter Linux aktivieren.

Speicherzellen eine SSD sind nicht unendlich beschreibbar. Irgendwann sind sie „kaputt“. Damit dieses möglichst spät passiert, hat jede SSD eine interne Logik, um Schreibzugriffe möglichst gut auf Speicherbereiche zu verteilen. Im optimalen Fall wird jeder Speicherbereich gleich oft zum Schreiben benutzt. Damit dieses möglichst gut funktioniert, muss die SSD wissen, welche Speicherbereiche wirklich frei sind. Diese Information kann die SSD fast nur vom Filesystem selbst bekommen. Damit die Info weitergeleitet wird, gibt es TRIM https://de.wikipedia.org/wiki/TRIM.

ZFS bietet diese Möglichkeit natürlich auch und dieses ebenfalls unter Linux. Im zpool nennt sich diese Option autotrim und um zu prüfen ob es aktiviert ist, hilft folgender Befehl:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  off        local
rpool  autotrim  off        local

Wie man sehen kann, gibt es die beiden ZFS Pools mit den Namen bpool und rpool. Auf beiden ist autotrim deaktiviert. Zum Aktivieren ist folgender Befehl nötig:

$ zpool set autotrim=on bpool
$ zpool set autotrim=on rpool

Wenn man nun prüft, ob es aktiviert ist:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  on        local
rpool  autotrim  on        local

Sollte man dieses bestätigt bekommen.

Einen kleinen Tipp habe ich darüber hinaus zusätzlich noch. Wenn eine SSD an den Strom angeschlossen wird, ohne dass ein „Computer“ angeschlossen ist, fallen viele SSD in eine Art Wartungs- / Reparaturmodus. Dann sortieren SSDs selbstständig ihre Speicherzellen um. Wenn also einmal etwas in den ersten Speicherbereich geschrieben wurde, ist dieses nicht gleichbedeutend, dass es für immer in nur diesem Bereich liegen bleibt. Im laufenden Betrieb wird dieses verschoben, wenn die SSD (wie beschrieben) nur am Strom angeschlossen ist forciert man dieses zusätzlich bei vielen SSDs. Einfach 2 / 3 Stunden „laufen“ lassen… Hin und wieder lassen sich über diesen Weg „tote“ SSDs wiederbeleben. Alles funktioniert natürlich mit TRIM viel besser 😀

Frage? Dann fragen..

Mein FreeBSD hat Probleme mit IPv6 bei netcup

Als Kunden der bei netcup FreeBSD „rootserver“ auf KVM qemu Basis einsetzt, habe ich schnell gemerkt, dass meine IPv6 Verbindung nicht stabil ist.

Dieses zeigt sich wie folgt:

– Direkt nach dem Boot scheinen IPv6 Verbindungen zu funktionieren, wie gewünscht.

– Nach einiger Zeit brechen die Verbindungen zusammen, sowohl Verbindungen vom System in die Welt als auch Verbindungen von der Welt ins System.

– Verbindungen scheinen „Startprobleme“ zu haben. Ein ping läuft erst ein paar Mal ins Leere und dann funktionieren alle Verbindungen plötzlich wieder für einen Moment.

Ein möglicher Workaround ist es, vom System aus einen ping auf die IPv6 Adresse des Gateways von netcup zu starten. Dieses sorgt in der Regel kurzzeitig für funktionsfähige IPv6 Verbindungen. Aber was ist das genaue Problem und wie könnte eine brauchbare Lösung aussehen?

Als Leser mit IPv6 Wissen, denkt man natürlich sofort a NDP das Neighbor Discovery Protocol und ja ich denke genau hier liegt das Problem. Dieses unterscheidet sich zur Implementation bei Linux etwas, daher funktioniert IPv6 im netcup Testsystem problemfrei unter FreeBSD, NetBSD usw. aber nicht. Die Probleme im NDP lassen sich auf dem System schnell wie folgt erkennen:

root@netcup-vps:~ # netstat -s -picmp6
icmp6:
    0 calls to icmp6_error
    0 errors not generated in response to an icmp6 message
    0 errors not generated because of rate limitation
    Output histogram:
        neighbor solicitation: 29
        neighbor advertisement: 10
        MLDv2 listener report: 8
    0 messages with bad code fields
    0 messages < minimum length
    0 bad checksums
    0 messages with bad length
    Input histogram:
        router advertisement: 17
        neighbor solicitation: 633
        neighbor advertisement: 25
    Histogram of error messages to be generated:
        0 no route
        0 administratively prohibited
        0 beyond scope
        0 address unreachable
        0 port unreachable
        0 packet too big
        0 time exceed transit
        0 time exceed reassembly
        0 erroneous header field
        0 unrecognized next header
        0 unrecognized option
        0 redirect
        0 unknown
    0 message responses generated
    0 messages with too many ND options
    0 messages with bad ND options
    423 bad neighbor solicitation messages
    0 bad neighbor advertisement messages
    0 bad router solicitation messages
    0 bad router advertisement messages
    0 bad redirect messages
    0 path MTU changes

Ich habe einige Zeit damit verbracht, mich mit dem Support darüber auszutauschen. Wie immer landet man zuerst in der human firewall, im Anschluss erreichte ich oft Supportmitarbeiter in Ausbildung eines IT Berufes. Zwischenzeitlich wurde mir das Problem von netcup dann auch bestätigt und mit dem Hinweis versehen, dass es an ihren Core-Routern liege, welche irgendwann ein Update bekommen sollen. Wann genau dieses Updates gemacht wird, konnte/wollte mir niemand bestätigen. Ebenfalls wurde versucht mein System auf verschiedene Hosts zu verschieben, von welchen andere Kunden wohl positives berichtet hatten. Dann sollte das Problem irgendwann behoben sein und netcup war erstaunt, dass es dieses noch nicht ist. Was auch immer… Aus meiner Sicht liegt das Problem an netcup.

Gelöst werden kann dadurch, dass man seinem BSD mitteilt, es soll bitte ND nach RFC4861 machen. Dieses ähnelt zumindest im Punkt der Bindung des jeweiligen ND ans Interface. Dafür kann man dieses als kurzen Test wie folgt aktivieren:

sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Stellt sich der gewünschte Erfolg ein, wird es mit dem passenden Eintrag in der /etc/sysctl.conf permanent aktiviert:

net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Dabei aber bitte beachten, dass FreeBSD dieses vor ca. 10 Jahren aus Sicherheitsgründen deaktiviert hat. https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc

Ich bin mit meinen Bemühungen aber leider nicht zu einer, für mich funktionierenden, Lösung von Seiten netcups gekommen. Daher blieb mir nur RFC4861.

Ich denke das Problem ist sicher schon lange beim Support bekannt, einfache google Suchen oder im netcup Forum zeigen dieses schnell auf. Dennoch vermittelte der Support mir erst das Gefühl, selbst etwas falsch konfiguriert zu haben, nur um mir dann den Eindruck zu vermitteln, dass sie noch nie von einem solchen Problem gehört haben. Ich vermute daher, dass ihr Setup aktuell einfach keine „einfache“ Lösung dieses Problems zulässt und sie daher so agieren. Was aber natürlich reine Spekulation ist, ich kann auch nur „vor“ das Setup schauen.

Fragen? Dann fragen…

Managebarer 4 Port MikroTik 10 Gbit SFP+ Switch für knapp über 100€

Ich habe einen neuen Switch. MikroTik CRS305-1G-4S+IN… Das Gerät verbindet bei mir zuhause im Arbeitszimmer meine Workstation, das Storage, meinen eigentlichen Switch und meinen Windows PC.


Das Teil ist der Knaller! Die angepriesene Leistung ist tatsächlich da, das Gerät kommt zwar nur mit einem Netzteil, man könnte aber ein weiteres anschließen. Ebenfalls kann man den Switch per PoE betrieben, somit hätte man im Grunde schon drei Netzteile als Ausfallsicherheit, wenn man es denn braucht. Das Gehäuse ist komplett aus Metall und dient zusätzlich zur passiven Kühlung. Es gibt also keinen Lüfter oder ähnliches, dass Geräusche machen könnte.

Unter dem Gehäuse sind noch Löcher, um es einfach an einer Wand oder ähnlichem befestigen zu können.

Wer MikroTik kennt, der fragt sich natürlich sofort: „Läuft da ein MikroTik OS drauf?“ JA tut es… Voll nutzbar und mit allem was man so gewohnt ist. Man könnte also noch über verschiedenste Dinge wir z.B.: VRRP die verrücktesten Failover Szenarien abbilden. Aber selbst, wenn nicht… 4 SFP+ Ports mit 10 GB/s für knapp über 100€, muss man da noch nachdenken?!?

Ich mache ja eher selten Werbung für ein Produkt aber den Switch wollt ihr haben. Als „Desktopswitch“ für zuhause (wie bei mir) ist der schon zu schade. Ich kann mir den gut als Pärchen vorstellen um klassische 1GB/s Switche zu verbinden oder ähnliche Dinge. Klickt euch den und testet ihn. Das Ding ist super: https://amzn.to/3r3kQiW

« Ältere Beiträge Neuere Beiträge »

© 2024 -=Kernel-Error=-

Theme von Anders NorénHoch ↑