Die Lösung ist die Eigenschaften der Virtuellen Maschine aufzurufen, hier die Volle Auflösung des Retina Display verwenden zu aktivieren und nach dem Anmelden im Kali Linux Desktop Kali HiDPI Mode zu wählen. Nach einem Restart sollte alles beim alten sein.

Nach dem aus sicherheitsupdategründen erzwungenen Upgrade auf macOS 26.3 mit einem anschließenden Update auf VMware 25H2 war dies einer der kleinen Schluckauf, welche ich zu bewerkstelligen hatte.

Hier haben wir wieder ein „Henne und Ei“-Problem.
Zwar sind die Cookies richtig kopiert worden und auch die Dateien sind zugänglich, sie lassen sich ja via Browser aufrufen, aber leider ist ytdlp veraltet. Bis ein neues Image für Tube Archivist erscheint, muss man sich mit der Variable TA_AUTO_UPDATE_YTDLP helfen.

Mit dieser Variable in der Compose-Datei und dieser den Wert release mitgeben. Nach einem Neustart des Containers wird eine neue Version von ytdlp heruntergeladen und die Videos können wieder lokal gespiegelt werden.

TA_AUTO_UPDATE_YTDLP = release

Was bei mir so vor der Eingabe des LUKs Passwortes und dem Starten von Debian vorbeihuschte, hatte mich dann doch einmal interessiert:

0.21027?] DMAR: [Firmware Bug: No firmware reserved region can cover this
MRR T®x00000000cd800000-0x00000000c/rFTfffl, contact BIOS vendor for Fixes
0.4880091 ACPT Error: Needed type tReferencel, found (Integerl ( ptrual_
→ (20220331050-665
0. 488035] ACPT Brror: AE AML OPERAND_TYPE, While resolving operands for tOp codeNane unavailable] (20220331/dswexec-431)
0. 488052] ACP Error: Aborting method PR.CPUO. PDC due to previous error (AE_AML, OPERAND TYPE) (20220331/psparse-529)
1.9383933 DMAR: DRHD: handling fault status reg 3
1.9384083 DMAR: EDMA Read NO_PASID] Request device [00:16.7] fault addr Oxc cdf1000 [fault reason Ox02] Present bit in context entry is clear
1.938649] DMAR: DRHD: handling fault status reg 2
1.9386563 DHAR: COMA Write NO_PASID] Request device [00:16.7] fault addr 0x ccdf/000 [fault reason 0x02] Present bit in context entry is clear
1.9386963 DMAR: DRHD: handling fault status reg 2
1.938702J DMAR: CDMA Write NO_PASID] Request device [00:16.7] fault addr 0x
ccd/P000 [fault reason 0x02] Present bit in context entry is clear

Kurz und knapp, es ist ein Fehler im BIOS, welcher schon seit 2013 besteht und vom T440 bis an den T460 weitergereicht wurde.
Lenovo behebt den Fehler, welcher bekannt ist nicht.
Jemand hat den zugehörigen Thread im Jahr 2018 erstellt, zwei Jahre nach dem Erscheinen des T460.

Lenovo kocht natürlich auch nur mit Wasser. Ich hätte mir jedoch mehr Support gewünscht, besonders wenn dies sogar unter Windows einen Bluescreen verursacht. Hier hätten doch einige Geschäftskunden unerfreut gewesen sein müssen. Schade, dass Firmen, welche ich als zuverlässig aufgrund Ihre Historie ansah, jenes nicht mehr sind. Gerade betreffend ThinkPads wäre es mir doch sehr wichtig.
Lenovo hatte mich schließlich mit einem Montagsthinkpad P53 enttäuscht, sodass ich mich zunächst für Apple Silicon entschied.
Aber wie man sieht, immer noch ThinkPads nutze 😉

Die Lösung wäre ein acpi=off , noacpi oder acpi=strict in der Konfiguration von grub zu setzen.
Weiterführende Informationen zu den Kernelparametern

Nach einem Update auf Nextcloud 31.0, Hub 10, hatte ich im Backend folgende Meldung die Meldung:

Falsches Zeilenformat in Ihrer Datenbank gefunden. ROW_FORMAT=Dynamic bietet die beste Datenbankleistung für Nextcloud. Bitte aktualisieren Sie das Zeilenformat in der folgenden Liste:…

Folgender SQL-Befehl fixt die Datenbank

mysql -u root -p -D DATENBANKNAME -N -e"
SELECT CONCAT(
 'ALTER TABLE ', TABLE_SCHEMA, '.', TABLE_NAME, ' ',
 'ROW_FORMAT=DYNAMIC;'
) 
FROM INFORMATION_SCHEMA.TABLES
WHERE ENGINE='InnoDB' AND ROW_FORMAT <> 'DYNAMIC';" | mysql -u root -p DATENBANKNAME

Ich empfehle vorher ein Datenbankbackup mit z.B. mydumper vorzunehmen

Da auf meinem Server einige Container laufen, wurde durch mein Rollout des Containers Tubearchivist der Platz langsam eng.

Hier habe ich mich entschlossen, den Standardspeicherplatz von Docker auf eine der 6 TB Datenpools zu verschieben. Das Umschreiben des Servicekonfigurationsdatei innerhalb von SystemD wäre hier der falsche Weg. Der richtige Weg ist hier JSON-Konfigurationsdatei des Daemon von Docker umzuschreiben. Falls diese noch nicht angelegt ist, muss diese angelegt werden.

Erstellen des neuen Datenspeicherplatzes für Docker

mkdir /data/IronWolf1/DOCKER_DATA

Stoppen des Dockerdienstes

systemctl stop docker && systemctl status docker && docker ps

Kopieren der Daten in das neue Verzeichnis

rsync -avxP /var/lib/docker/ /data/IronWolf1/DOCKER_DATA

Erstellen der Datei /etc/docker/daemon.json

{<br />"data-root":"/data/IronWolf1/DOCKER_DATA"<br />}

Neustarten des Dienstes Docker

systemctl restart docker.service

Überprüfen, ob der Standardspeicherort übernommen wurde. Hierzu habe ich Vaultwarden als Beispiel genommen

docker inspect vaultwarden/server:latest |grep WorkDir<br />"WorkDir":"/data/IronWolf1/DOCKER_DATA/overlay2/b419d698e9ba693188a2f517f53891702a25ea20f974993aca879206818ab328/work"

Der Inhalt des alten Verzeichnisses /var/lib/docker kann nun gelöscht werden