Mein Datenhaufen zu IT und Elektronik Themen.
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!
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
Wie ich feststellen konnte, haben verschiedene Geschirrspüler ein ähnliches Problem mit der Dichtung am Pumpentopf. Die Hersteller entwickeln solche Teile nicht für jedes Modell völlig neu. Ähnlich wie bei Autoherstellern greifen sie auf diverse Grundkomponenten zurück. Tritt bei einem dieser Teile ein Problem auf, betrifft es daher oft eine Vielzahl an Geräten. Nicht nur meine von Bosch sondern auch baugleiche von Siemens, Neff und Constructa.
So scheint es auch bei meiner Spülmaschine zu sein. Nach ein paar Jahren im Einsatz verzieht sich der Pumpentopf in der Maschine offenbar leicht. Gerade genug, um ein wenig Wasser zu verlieren – nicht so viel, dass die Küche überschwemmt wird, aber genug, damit der Sensor anspricht und die Maschine mit dem Fehlercode E-15 stoppt. In einem solchen Fall beginnt die Maschine „panisch“ Wasser abzupumpen und hört damit auch nicht mehr auf.
Die Reparatur ist recht einfach. Es gibt einen speziellen Reparatursatz für dieses Problem, den man bequem bei Amazon bestellen kann: https://amzn.to/3kHALRS
Wenn man nicht gerade zwei linke Hände hat, lässt sich die Reparatur in etwa 15 Minuten erledigen.
Diese zusätzliche Dichtung sorgt dafür, dass der Pumpentopf auch dann dicht bleibt, wenn er sich durch die Hitze leicht verzieht. Ob die eigene Maschine bereits über diese Dichtung verfügt, erkennt man an einem kleinen Aufkleber links in der Tür, auf dem ein großes „R“ zu sehen ist.
Reparatur einer Spülmaschine … mal was anderes, oder?
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 🙂
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..
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…
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
Zu ZFS und warum man es haben will, muss ich hier sicher nicht mehr viel schreiben. Ebenfalls wird sich niemand mehr die Frage stellen, warum man seine Festplatte verschlüsseln möchte.
ABER wenn man nun Linux, ZFS und Verschlüsselung kombinieren möchte, dann gibt es etwas, worüber es sich zu schreiben lohnt. Wie man nun also sehr einfach unter sein Linux Mint >= 20.x einen native encryptet zfs root pool bekommt, darum geht es hier.
Linux Mint bringt seit Version 20 bereits alles mit um dieses ohne besonderen Aufwand zu erledigen. Natürlich ging es bereits schon früher, nur war es dann fast nur über den Weg möglich, die Festplatte inkl. Grub vollständig von Hand vor und während der Installation selbst fertig zu machen. Dieses ist… Sagen wir mal… „Für den erweiterten Anwender schon fast nicht zu machen“.
Zurück zu Linux Mint 20.x!
Wie erwähnt bringt diese Version alles Nötige mit, nur der Installer ist noch nicht ganz so weit und man muss ihm mit zwei Kleinigkeiten unter die Arme greifen. Einmal muss man die nötigen Pakete im Live-System nachinstallieren. Also einfach die gewünschte Version von Linux mit downloaden und davon booten. Ist man im Live-System angekommen, öffnen man ein Terminal und wirft die Installation der Pakete mit folgendem Befehl an:
sudo aptitude -y install libzfs2linux zfs-initramfs zfsutils-linux zfs-zed
Möchte man nun einfach nur sein Linux Mint auf einem ZFS Pool installieren, ist man schon fertig. Einfach den Installer starten und beim Punkt, auf welche Festplatte man sein neues System installieren möchte auf Advanced features… klicken und unten auf EXPERIMENTAL: Erase disk and use ZFS. Fertig ist!
Möchte man noch seinen zroot Pool verschlüsseln fehlt noch die zweite Kleinigkeit. Da der Installer den Wunsch und somit ebenfalls das Kennwort zur Verschlüsselung des ZFS Pools nicht abfragt, muss man es dem Installer mitgeben, bevor er mit seiner Arbeit startet. Dazu bleibt man im Terminal und editiert das Installerscript wie folgt:
sudo vi /usr/share/ubiquity/zsys-setup
Hier sucht man nun die Sektion, in welcher es ums Anlegen der ZFS Pools geht ?zpool create wäre eine gute Suche 😉
Hat man dieses gefunden (derzeit sollte es genau zwei Mal im Installerscript auftauchen) setzt man einfach vor das zpool create des rpools ein:
echo 'SUPER-SECURE' |
Die Hochkomma bleiben dabei stehen und ihr ersetzt SUPER-SECURE durch euer gewünschtes Kennwort, was sich natürlich schon jeder gedacht hat. Damit wird dem zpool create rpool später im Installationsprozess euer Kennwort übergeben.
Fehlen nur noch die Optionen beim Erstellen des Pools, damit er ihn auch verschlüsselt. Dafür bitte folgendes vor die Zeile -O mountpoint=/ -R „${target}“ rpool „${partrpool}“ eintragen:
-O encryption=aes-256-gcm \ -O keylocation=prompt \ -O keyformat=passphrase \
Am Ende sieht der Ausschnitt also beispielhaft wie folgt aus:
echo 'Kennwort!' | zpool create -f \
-o ashift=12 \
-O compression=lz4 \
-O acltype=posixacl \
-O xattr=sa \
-O relatime=on \
-O normalization=formD \
-O mountpoint=/ \
-O canmount=off \
-O dnodesize=auto \
-O sync=disabled \
-O encryption=aes-256-gcm \
-O keylocation=prompt \
-O keyformat=passphrase \
-O mountpoint=/ -R "${target}" rpool "${partrpool}"
Das war es auch schon. Jetzt, wie gewohnt den Installer starten und schon wird man nach dem Reboot aufgefordert seinen ZFS Pool mit einem Kennwort zu entschlüsseln. Oh, geht natürlich so mit EFi und lagacy und überhaupt….
Ob alles so funktioniert hat, wie man es sich vorstellt, lässt sich direkt nach dem ersten Boot ins neue System prüfen. Einfach Terminal öffnen und mittels folgender Befehle prüfen, ob die Verschlüsselung aktiviert ist und sich auch sauber durch den Pool bis zu den Benutzerdaten weiter vererbt hat:
test@test-VirtualBox:~$ sudo zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT bpool 1,38G 97,3M 1,28G - - 0% 6% 1.00x ONLINE - rpool 26,5G 4,46G 22,0G - - 3% 16% 1.00x ONLINE - test@test-VirtualBox:~$ sudo zpool get feature@encryption NAME PROPERTY VALUE SOURCE bpool feature@encryption disabled local rpool feature@encryption active local test@test-VirtualBox:~$ sudo zfs get encryption rpool/USERDATA/test_9d9i92 NAME PROPERTY VALUE SOURCE rpool/USERDATA/test_9d9i92 encryption aes-256-gcm - test@test-VirtualBox:~$
Hier noch Bilder zum Klicken, das mögen ja viele.
Fragen? Dann fragen…
Der Akku in meinem Bose QC35 hat inzwischen ausgedient und muss ausgetauscht werden. Der verbaute Akku ist ein AHB110520CPS von Synergy. Leider konnte ich diesen nicht als Ersatzakku finden. Man kann ihn zwar aus China bestellen (ca. 35 €), aber er ist dann gebraucht, da er aus einem alten Kopfhörer ausgebaut wurde – natürlich „getestet“.
Alternativ gibt es die Möglichkeit, den Kopfhörer einzuschicken und den Akku dort tauschen zu lassen (ca. 70 €). Beides sind jedoch Lösungen, die mir nicht zusagen, denn im Grunde handelt es sich nur um einen einfachen 3,7V-Akku mit knapp 500 mAh.
Nach einiger Suche habe ich jedoch einen passenden Ersatz gefunden. Der Akku GSP072035 hat zwar etwas weniger mAh, was bedeutet, dass die Kopfhörer etwas früher leer sind – aber damit kann ich leben. Zumal die Standzeit des alten Akkus ohnehin schon stark eingeschränkt war. Bestellt habe den folgenden Ersatzakku bei Amazon: https://amzn.to/2JXwhJc
Der neue Akku passt zwar nicht exakt ins Akkufach des alten, ist jedoch klein genug, um problemlos im Kopfhörer Platz zu finden, ohne das Gewicht oder die Klangqualität zu beeinflussen. Man merkt den Unterschied also nicht!
Ein kleiner Tipp: Wenn man schon dabei ist, kann man auch gleich die Ohrpolster austauschen. Ich habe die folgenden Polster bereits zweimal erneuert und kann sie wärmstens empfehlen: https://amzn.to/2L4xcbo
Wie man den Akku selbst austauscht, zeigt eine erstklassige Anleitung von IFIXIT: https://de.ifixit.com/Anleitung/Bose+QuietComfort+35+Akku+tauschen/134337
Sobald der alte Akku entfernt ist, klebt man den neuen mit einem kleinen Tropfen Heißkleber in die Ecke und lötet ihn wie den alten Akku an. Nach dem Zusammenbau sollte der Kopfhörer wieder wie gewohnt funktionieren – abgesehen von etwa 20–25 Minuten weniger Hörzeit.
Kleines Update! 😊
Inzwischen gibt es auf Amazon einen perfekt passenden Ersatzakku. Es war mal wieder Zeit für einen Austausch, und dieses Mal habe ich sogar ein Modell mit 600 mAh gefunden. Jetzt habe ich so viel Hörzeit wie noch nie zuvor mit meinen Kopfhörern! 🎧 https://amzn.to/3CsPQnv
Fragen? Dann fragt einfach! 🙂
© 2024 -=Kernel-Error=-
Theme von Anders Norén — Hoch ↑
