Will­kom­men im Zwie­licht

Noch eine kleine Unannehmlichkeit bei Monkey Island: mit dem erzwungenen Start im X11-Kompatibilitätsmodus suchte sich das Programm (natürlich…) den falschen Monitor aus.

Mit dem folgenden Workaround ließ sich das unter KDE Plasma einfach lösen:

• z.B. mit Alt-Tab aus dem laufenden Spiel rausspringen, so daß man an die Taskleiste drankommt.
• Einenn Rechtsklick auf den Programmeintrag machen und dort unter „Mehr“ den Haken bei „Vollbild“ entfernen:

• Nun kann wird das Programm in einem Fenster dargestellt.
• Auf den gewünschten Monitor verschieben und dort maximieren.
• X11 und damit XWayland merkt sich den Monitor und startet das Programm dort dann immer – Problem gelöst.

Auf Vollbild schaltet Monkey Island dann beim nächsten Start von selber, daher habe ich mir nicht die Mühe gemacht, den Haken wieder zu setzen.

Das Zeug, was in der Bude zu machen war, ist erledigt, und die Linse für das Mikroskop ist noch nicht da – also kann einfach mal wieder ein bißchen gezockt werden. Auch mal sehr entspannend. Und da sich aufgrund irgendeiner miesen Laune des Spiels meine Speicherstände zu Divinity Original Sin 2 mit einer nüchternen Fehlermeldung in Luft aufgelöst haben (… und der Ordner nicht im Backup mit drin war…grmbl…) kommt nun Return to Monkey Island zum Zug.

GOG unterstützt bei seinen Linux-Spielen übrigens ausdrücklich kein Wayland, wie der Meister lernen durfte – daher erkennt das Spiel keine Mausklicks.

Zum Beheben muß das Spiel unter X11-Emulation gestartet werden: Entweder man setzt Exec=env QT_QPA_PLATFORM=xcb vor den Startbefehl im Shortcut des Startmenüs oder man fügt in den Lutris-Einstellungen für das Spiel eine Umgebungsvariable „QT_QPA_PLATFORM“ mit dem Wert „xcb“ ein. Da hat sich die Suche wegen OBS vor kurzem direkt doppelt gelohnt.

Willkommen zurück, Mr. Fleetwood… Keepgood… Threepwood :-)

Update 29.12: Fertig. Hm… also, Herr Gilbert, wäre dieses Spiel statt Monkey Island 1 gemacht worden, hätte es den Rest der Serie niemals gegeben. Und mit der Grafik kann ich dabei wohlgemerkt durchaus leben – mit der Ausnahme von Elaine vielleicht, die sich von der höchst wort- und schlagkräftigen Gouverneurin der Vergangenheit irgendwie in eine dümmlich lächelnde unterbeschäftigte Sozialpädagogin im Piraten-Faschingskostüm verwandelt hat. Immerhin konsequent – die Optik paßt dazu, wie sie sich verhält.
Das Spiel als solches fällt unter die Kategorie „kurz und ohne jede Tiefe, aber mal ganz nett, wenn man es für nen Fünfer auf dem Grabbeltisch findet“. Aber auch nur, wenn man neben Elaine die Szenen geistig ausblendet, an dem der Autor sich den belehrend erhobenen Zeigefinger nicht verkneifen konnte. Die sind auch weder spielrelevant noch kann man irgendwas durch eine andere Entscheidung im Spiel dran ändern, sondern sie sind offensichtlich nur drin, weil irgendeine Volltröte es für nötig befunden hat, daß Adventures heutzutage unbedingt gewaltfrei und belehrend sein müssen und beispielsweise einfach so Bäume fällen voll pöhse ist und so.
Das Ende dagegen… ja, Ron Gilbert mag bekanntlich keine Enden. Dieses hier ist aber finde ich… sehr vorsichtig ausgedrückt unerfüllend, daran hat auch die Begründung im versiegelten Brief (Menüpunkt „Sammelalbum“) nix geändert. Der Herr der Ringe endet schließlich auch nicht damit, daß Frodo in Wirklichkeit als Kassierer im Supermarkt arbeitet, da auf dem Klo eingepennt ist und Sauron aus der Lautsprecherdurchsage zusammenphantasiert hat oder sowas. Und ja, das (vergleichbare) Ende von Monkey Island 2 fand ich auch schon scheiße.

Fantasygeschichten und Adventures sollen doch bitte losgelöst von den Niederungen der Realität bleiben, finde ich. Dieses Spiel hier ist dagegen… tja, was? Am ehesten wohl eine softwaregewordene Midlife-Crisis.

Mal wieder ein Fall von „manchmal ist es so einfach…“: auf dem frisch auf MX Linux 25 mit Debian Trixie-Unterbau und Wayland laufenden OBS Studio suchte der Meister die Screen-Recording-Funktion vergebens.

Nun gebe man das mal in die Suchmaschine seiner Wahl ein. Da findet man alles mögliche. Wer nicht einfach flucht und zu X11 zurückwechselt, zwingt entweder OBS wieder zurück zu X (das dann wiederum mit XWayland in Wayland läuft), oder er sucht sich Plugins, die je nach Wahl des Programmierers dann auf unterschiedliche andere Schnittstellen zugreifen.

Dabei ist die Sache zumindest für das OBS 30.2.3 aus dem Debian-Repository ganz einfach: man installiere sich das Paket „obs-plugins“ (liegt ebenfalls im Repository) – und schon ist die Bildschirmaufnahme wieder da.

Bei der Gelegenheit kann man auch gleich noch die Pakete „obs-pipewire-audio-capture“ und „qpwgraph“ nachinstallieren. Ersteres ermöglicht Soundaufnahmen direkt über den Pipewire-Soundausgang, und das zweite ist eine Art Software-Steckbrett, mit dem man x-beliebige Ein- und Ausgänge von Pipewire miteinander verbinden kann. Also genau das, was ein Kabel zwischen Soundkartenaus- und -eingang oder ein virtueller Loopback-Audio-Treiber wie VBCable oder LoopBeAudio unter Windows tut – nur viel flexibler. Damit interessiert es einen schlicht und ergreifend nicht mehr, wenn irgendeine Software nur den PC-Soundausgang, nicht aber eine Aufnahmesoftware bedudeln will…

Die Kisten zuhause können nun per IPv6 ins Netz, und Pihole filtert brav.

Nun geht es darum, von außen auch wieder ins eigene Netzwerk zu kommen und so nebenher auch unterwegs auf dem Handy via Pihole die Werbung nachhaltig auszuräuchern.

Dafür braucht man einen IPv6-fähigen DynDNS-Service – und nachdem hier Wireguard nicht in der von AVM kastrierten Version auf der Fritzbox, sondern auf dem Raspi mit Pihole läuft (Vorteil u.a.: man kann die Verbindung sichern und wiederherstellen…), muß die Ansteuerung des DynDNS-Services von der Fritzbox zum Raspi verlagert werden, weil der Raspi seine eigene IPv6 festlegt (wir erinnern uns… SLAAC…). Dafür gibt es- neben reichlich dummen Lösungen wie dietpi-ddns, die stumpf alle x Minuten den DynDNS-Server zumüllen, auch ddclient. Der wird von des Meisters DynDNS-Provider empfohlen, weil er so helle ist und nur bei einer Änderung ein Update sendet, so daß man keine Problem kriegt, wenn der DynDNS-Provider eine Beschränkung der Updates hat.

Allerdings ist dieses Stück Software leider auch ein Musterbeispiel an Frickelarbeit. Die Dokumentation ist höflich ausgedrückt diffus. Die Einstellungen in der Konfigurationsdatei scheinen sich bei jeder der letzten Versionen verändert zu haben, weswegen auch die Anleitung bei deSEC für IPv6 nicht funktioniert. Und die Version 3.10.0, die Debian-Systeme in der Paketverwaltung anbieten, funktioniert aufgrund eines Bugs mit IPv6 sowieso nicht richtig.

Daher hier – nach geraumer Zeit des Rätselratens – eine ausführliche Installationsanleitung:

Nachdem nun die Rechner grundsätzlich mal eine IPv6-Verbindung haben, sollen natürlich auch Unbound und Pihole ihren Job für IPv6-Adressen tun.

Der erste Schritt ist Unbound. Dafür habe ich die entsprechende Anleitung hier passend aktualisiert.

Update 8.12.25: Als nächstes sorgen wir dann dafür, daß der Raspi den hinteren Teil seiner IPv6-Adresse (die „Interface ID“) festlegt. Mein Raspi interessiert sich nach einer Neuverbindung der Fritzbox aus mir unklaren Gründen nämlich einen Dreck dafür, wenn man die an der Fritzbox ebenso wie die IPv4-Adresse unter „Heimnetz –> Netzwerk –> [Einstellungen des Raspis] –> Heimnetz –> IPv6-Interface-ID“ fest vorgibt. (An sich ist das zu erwarten, wenn man wie der Meister unter „Heimnetz –> Netzwerk –> Netzwerkeinstellungen –> weitere Einstellungen (ganz unten) –> IPv6-Einstellungen –> DHCPv6-Server im Heimnetz“ nur die Option „Nur DNS-Server zuweisen“ aktiv hat und daher DHCPv6 an der Fritzbox nicht aktiv ist – nur warum übernimmt der Raspi das in anderen Fällen dann trotzdem?)

Zum Festlegen gibt es zwei Optionen:

• Entweder man stellt dafür einfach in der dhcpd.conf die Mac-Adresse der Netzwerkkarte ein – das mag ich nicht, weil die dann hardwaregebunden ist – da hat man Spaß bei einem Austausch des Raspis.
• Oder man definiert dafür ein IPv6-Token, mit dem die Interface ID festgelegt wird. Das klingt doch besser.

Dietpi ist da ein wenig undankbar, weil man da eigentlich die Netzwerkinterfaces über dietpi-config einstellen soll – andere Programme sind nicht vorhanden. Allerdings hat das Programm von IPv6-Tokens noch nichts mitbekommen… daher ist hier erstens Handarbeit fällig und zwar mangels komfortablerer Alternativen so wie vor zwanzig Jahren: über die „interfaces“-Datei.

Wir öffnen also die Datei /etc/network/interfaces, stellen fest, daß man die nicht editieren soll, weil dietpi-config sie ggf. überschreibt – und erstellen dann mit sudo nano /etc/network/interfaces.d/ipv6settoken eine neue Datei namens „ipv6settoken“ mit folgendem Inhalt:

iface eth0 inet6 auto  
up ip token set ::abba:eeff:ffdd:abba dev $IFACE

Mit einem sudo /etc/init.d/networking restart gefolgt von ip token kann man das Ergebnis dann testen und sollte folgende Antwort erhalten:

token ::abba:eeff:ffdd:abba dev eth0

Damit ist dieses Theater seitens des Raspi erledigt. In der Fritzbox sollte man nun denselben Wert auch bei „Heimnetz –> Netzwerk –> [Einstellungen des Raspis] –> Heimnetz –> IPv6-Interface-ID“ eintragen, damit sich die beiden nicht in die Quere kommen. Dann wird der Wert auch bei vorhandenen Portfreigaben übernommen.

Nun folgt Pihole: das ist dazu seit einiger Zeit problemlos in der Lage; es holt sich auch dann IPv6-Adressen von Unbound, wenn man Unbound nur mit seiner IPv4-Adresse unter „Custom DNS Servers“ eingetragen hat. Einstellungen muß man seit Version 6 keine mehr vornehmen.

Mit einem

dig -t aaaa google.de @127.0.0.1

kann man testen, ob Pihole die Adresse richtig auflöst.

Nun kommt die Fritzbox dran, hier muß man Pihole als DNS auch für IPv6 eintragen. Hierzu benötigt man die feste interne IPv6-IP des Raspis, auf dem Pihole läuft. Hierzu im Terminal oder der SSH-Konsole

ip -6 addr

eingeben und die mit dem in der Fritzbox bei „Unique Local Addresses –> ULA-Präfix manuell festlegen“ festgelegten Präfix (Standard ist „fd00“, also im Zweifelsfall danach suchen) beginnende IP-Adresse suchen (die Option aktivieren, sofern nicht bereits geschehen). Falls zwei davon auftauchen, die nehmen, wo nicht „temporary“ hintendran steht. Dieselbe Adresse sollte auch in der Fritzbox unter „Heimnetz –> Netzwerk –> [Einstellungen des Pihole-Raspis] –> Heimnetz –> IPv6-Adresse –> IPv6-ULA“ stehen. Leider unterscheidet die Fritzbox nicht zwischen einer temporären und einer festen ULA, daher muß man bei aktiven Privacy Extensions zwingend auf dem Rechner nachgucken, welche die richtige ist (edit: dieser Punkt scheint sich mit einem der letzten Fritzbox-Updates erledigt zu haben, seitdem steht nur noch an einer ULA-Zeile in der Fritzbox „Temporary“!). Diese Adresse merken, die muß in der Fritzbox auch noch an diesen beiden Stellen eingetragen werden:

• einmal unter „Heimnetz –> Netzwerk –> Netzwerkeinstellungen –> weitere Einstellungen (ganz unten) –> IPv6-Einstellungen –> DNSv6-Server im Heimnetz –> Lokaler DNSv6-Server“
• und einmal an derselben Stelle, wo Pihole auch schon für IPv4 einzutragen ist, nämlich unter „Internet –> Zugangsdaten –> DNS-Server“. Hier bei „DNSv6-Server –> Bevorzugter DNSv6-Server“ die IP von Pihole festlegen.

Spätestens nach einem Neustart sollte Pihole dann auch als DNS-Server für IPv6-Anfragen genutzt werden.

Das war einfach – es folgen erst DynDNS und dann Wireguard, und das wird lustiger, weil da die Tücken von IPv6 voll reinhauen…

Über kurz oder lang wird man um den Rotz ja nicht herum kommen, also beschäftige ich mich gerade damit, wie man denn

• die Fritzbox
• PiHole
• und die Wireguard-Verbindung ins Heimnetz (und von da aus wieder nach draußen) IPv6-tauglich kriegt.

Erstmal kommt die Fritzbox dran, sofern das der Provider nicht schon getan hat. Was man da wählen muß, hängt sehr vom Internetprovider ab. Eine allgemeine Anleitung von AVM dazu gibt es hier: IPv6 in FRITZ!Box einrichten.

Wichtig ist, daß unter Heimnetz–> Netzwerk–> Netzwerkeinstellungen –> weitere Einstellungen (ganz unten) –> IPv6-Einstellungen –> Unique Local Addresses der Punkt „Unique Local Addresses (ULAs) zuweisen“ aktiv ist – sonst kriegen die Rechner keine lokale „fd00“-Netzwerkadresse.

Weiterhin kann man unter „Internet –> Zugangsdaten –> IPv6“ auch „DHCPv6 Rapid Commit“ abschalten – damit werden nur zwei Nachrichten zwischen Router und Gegenstelle beim Verbindungsaufbau vom DSL eingespart und die Stabilität des Verbindungsaufbaus erhöht. Mit „IPv6-Adresse der FRITZ!Box zufällig festlegen“ sorgt man außerdem dafür, daß sich Angreifer nicht ganz so leicht auf die Fritzbox einschießen können.

Als zweites kommen alle im lokalen Netz befindlichen Rechner dran. Üblicherweise nehmen die inzwischen meist eine von der Fritzbox angebotene IPv6-Adresse ohne weiteres Zutun. Sonst muß man in den Verbindungseinstellungen die IPv6-Unterstützung aktivieren – bei einem Linux mit KDE z.B. in den Systemeinstellungen unter „Verbindungen“.

Aber damit ist es nicht getan. Warum? Da IPv6 um die Jahrtausendwende konzipiert wurde, als man rückblickend einfach nur naiv und blöde war und dachte, daß es doch eine total tolle Idee sei, ein jedes Gerät direkt im Internet auffindbar und eindeutig identifizierbar zu machen, hat man da ja einiges anders und aus meiner ganz persönlichen Sicht dümmer gemacht als bei IPv4. Ja, ich weiß, irgendwelche Admins von Großnetzwerken werden mir da energisch widersprechen, aber ich persönlich *mag* abgeschlossene private 192.xxx.xxx.xxx-Netzwerke hinter einem Router und die Logik, daß alles per NAT vom Router weitergereicht muß. Der hat damit erstens auch automatisch mit dem DHCP-Server den Daumen drauf , welche IP ein Gerät bekommt, zweitens was denn raus- oder rein kann, und drittens erlaubt das, daß mein Drucker intern eine feste IP, nach draußen aber eine gänzlich andere dynamische hat – was mit IPv6 bzw. zumindest mit dem, was eine Fritzbox dabei hat, und richtiges NAT66 gehört nicht dazu, so schlicht und einfach nicht möglich ist. Dort erhält ein Gerät nämlich nur den vorderen Teil der IP (den Präfix) vom Router vorgegeben. Den hinteren Teil dagegen denkt es sich anhand seiner festen Hardware-MAC-Adresse selber aus – und die reicht üblicherweise völlig, um das Gerät zu eindeutig identifizieren. Privacy? War damals kein Thema.

Immerhin ist man irgendwann auf die Idee gekommen, daß „eindeutig identifizierbar“ eventuell nicht der Weisheit letzter Schluß war, und hat wenigstens die „Privacy Extensions“ in den IPv6-Standard hineingebastelt, mit denen sich ein Gerät dann nicht nur eine externe und eine interne IPv6-Adresse gibt, sondern auch eine zweite externe (und ggf. auch eine zweite interne), deren hinterer Teil dann variabel ist – zumindest sofern das im Betriebssystem des Geräts auch aktiviert wurde. Sofern einem der Provider dann noch freundlicherweise regelmäßig einen neuen Präfix zuteilt (was aber keineswegs sicher ist, schließlich gibt es genug IPv6-Adressen), kommt man damit dann wieder auf eine variable IP. Mit Glück will der Provider Geld verdienen und setzt die Kunden deshalb im Standard auf dynamische Präfixe. Falls nicht, freut sich halt jede Marketingfirma, der einen tracken will.

Im Ergebnis haben wir dann für jedes Gerät nicht eine IP, sondern derer vier bis fünf, eventuell auch sechs – einfach weils offenbar Spaß macht, Adressen zu verschenken:

• eine feste globale IPv6-Adresse („global unique address“ = „GUA“)
• eine temporäre globale IPv6-Adresse, die durch die Privacy Extensions erzeugt wurde
• eine feste lokale „fe80“-IPv6-Adresse („LLA“ = „link local address“), die nur zur internen Kommunikation im Netzwerk dient
• eine feste lokale „fd00“-IPv6-Adresse („ULA“ = „unique local address“), die der Kommunikation im internen Netzwerk dient, wie es die 192.xxx-Adressen bei IPv4 tun
• ggf. eine temporäre lokale „fd00“-IPv6-Adresse, die durch die Privacy Extensions erzeugt wurde
• … und eventuell in einem größeren Netzwerk auch noch eine „site-local unicast address“ (SLA), deren Sinn sich dem Maschinisten nicht erschließt.

Nachdem temporäre Adressen einen Zwischenstatus „gilt noch, aber nur noch für eingehende Verbindungen“ haben, können da auch noch eine oder mehrere temporäre „veraltete“ temporäre Adressen hinzukommen. Maximale Unübersichtlichkeit also…

Aber gut, hoffen wir mal das beste und schalten als erstes bei jedem einzelnen Rechner im Netzwerk (man bedanke sich bei dem Erfinder von SLAAC – der „Stateless Address Autoconfiguration“ dafür) die Privacy Extensions an. Bei Windows und MacOS darf der geneigter Leser selber suchen – bei Linux (zumindest den Debian-Derivaten) sind die Privacy Extensions per Default ABGESCHALTET und es gibt (natürlich) mehrere Wege der Aktivierung.

Prüfen kann man das mit den folgenden Befehlen:

• „cat /proc/sys/net/ipv6/conf/all/use_tempaddr“
• „cat /proc/sys/net/ipv6/conf/default/use_tempaddr“
• „cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr“ (sowie allen weiteren Ethernetanschlüssen)
• „cat /proc/sys/net/ipv6/conf/wlan0/use_tempaddr“ (sowie allen weiteren WLAN-Anschlüssen)

Die Ausgabe sollte immer „2“ sein. Falls nicht, muß man die Privacy Extensions aktivieren. Offenbar am zuverlässigsten geht das, indem man direkt die Kerneleinstellung anpaßt. Hierzu im Ordner /etc/sysctl.d eine Datei namens 40-ipv6.conf erstellen und dort eintragen:

# IPv6 Privacy Extensions als Default für zur Laufzeit erzeugte Verbindungen aktivieren
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2

# IPv6 Privacy Extensions für eth0 aktivieren
net.ipv6.conf.eth0.use_tempaddr = 2
# Zulässige Lebensdauer für eingehende Pakete = 24h (Default ist eine Woche)
net.ipv6.conf.eth0.temp_valid_lft = 86400
# zulässige Lebensdauer für ausgehende Pakete = 12h (Default ist 24h)
net.ipv6.conf.eth0.temp_prefered_lft = 43200

# IPv6 Privacy Extensions für wlan0 aktivieren
net.ipv6.conf.wlan0.use_tempaddr = 2
# Zulässige Lebensdauer für eingehende Pakete = 24h (Default ist eine Woche)
net.ipv6.conf.wlan0.temp_valid_lft = 86400
# zulässige Lebensdauer für ausgehende Pakete = 12h (Default ist 24h)
net.ipv6.conf.wlan0.temp_prefered_lft = 43200

Falls man mehrere Netzwerkanschlüsse/WLAN-Karten hat, müssen die Einträge dafür manuell ergänzt werden. Nach einem Neustart werden die Einstellungen übernommen. Prüfen kann man das, indem man in der Kommandozeile „ip -6 addr“ eingibt, in der Ausgabe sollte dann eine Zeile mit einer IPv6-Adreesse und dem Hinweis „scope global temporary dynamic“ auftauchen.

Damit sollte nun von jedem PC aus der Aufruf einer IPv6-Testseite wie z.B. https://test-ipv6.com/ erfolgreich funktionieren und der erste Schritt ist getan.

Für die netzinterne Kommunikation muß man bei Windows 10 (und vermutlich auch 11) außerdem festlegen, daß die interne IP bevorzugt genutzt wird – Linux macht das automatisch. Das geht nur über die Kommandozeile mit den folgenden Befehlen:

netsh
interface
ipv6
add pref fc00::/7 60 10
add pref fd00::/8 60 10
show pref (--> Ausgabe kontrollieren: sind die ergänzten Präfixe aufgeführt?)
commit
exit

Weiter gehts mit Pihole und Unbound.

Urlaub!! Endlich!

Hier war die ganze Zeit so relativ wenig los, weil der Meister nach der Arbeit einfach keinen Bock mehr hatte – Projekte mit idiotischen Zeitplänen sind einfach nur die Pest!

Nun gut, die kommenden Wochen kann mich

• die Arbeit im allgemeinen und
• ein jeder verkackte Frühaufsteher, der mich vor zwölf irgendwo hinzitieren will im besonderen

mal kreuzweise im Arsche lecken. Ja, Chef, Du bist gemeint.

Als erstes ging es mit dem Rechner von $mylady weiter, der nun endgültig auf Linux umgestellt wird. Microsoft hat hiermit endgültig im gesamten Haushalt verschissen.

Nur eins wollte mal wieder nicht… Lutris. Und ich hatte natürlich beim letzten Versuch schon wieder vergessen, die Fehlersuche und vor allem die Lösung zu notieren. Daher hier ein für alle Mal:

• wenn Ihr Lutris installiert, dann installiert am besten ERST die hier angegebenen Dependencies und DANN Lutris. Es funktioniert oft auch andersrum, aber nicht immer.
• vor allem aber: wenn Ihr ein scheinbar funktionierendes Lutris habt,
  • das Euch aber bei jedem Versuch ein Spiel zu installieren einen „Error 256“ um die Ohren haut
  • und Euch beim Start über die Kommandozeile die folgende Fehlermeldung dazu ausgibt, obwohl Wine selbst prima funktioniert…

warning: /home/ichbins/.local/share/lutris/runners/wine/wine-ge-8-26-x86_64/bin/wine cmd.exe /c echo '%AppData%' returned empty string, error message "" 
------------------------------------------------------
Monitored process exited.
Initial process has exited (return code: 256)
All processes have quit
Exit with return code 256
DEBUG    2025-05-29 18:34:00,571 [monitored_command.on_stop:228]:Process 5365 has terminated with code 256
DEBUG    2025-05-29 18:34:01,274 [commands._monitor_task:445]:Return code: 256
ERROR    2025-05-29 18:34:01,274 [errors.__init__:19]:Befehl beendet mit dem Code 256
ERROR    2025-05-29 18:34:01,275 [exception_backstops.error_wrapper:81]:Error handling timeout function: Befehl beendet mit dem Code 256
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lutris/exception_backstops.py", line 79, in error_wrapper
    return handler(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/lutris/util/jobs.py", line 127, in wrapper
    repeat = func(*a, **kw)
             ^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/lutris/installer/commands.py", line 447, in _monitor_task
    raise ScriptingError(_("Command exited with code %s") % command.return_code)
lutris.installer.errors.ScriptingError: Befehl beendet mit dem Code 256

… dann habt Ihr gute Chancen, daß Ihr einfach nur eben diese Dependencies vergessen habt zu installieren, obwohl dieser Fehler alles mögliche suggeriert, nur nicht das. Ein verdammter vergessener Befehl – und man sucht sich den ganzen Tag doof und dusslig, warum die Sau nicht will…

Lutris und Wine bauen halt Windows nach, da muß man sich wohl auch auf Fehlermeldungen einstellen, die genauso kryptisch sind…