Schlagwort: apt

Ausmusterung und Anheuerung mit Fast-Desaster

Es ist soweit – ich mustere alte Hardware aus, was bei mir extrem selten vorkommt. Ich versuche Altgeräte solange zu nutzen, solange der Kram noch geht und eine halbwegs vernünftige Anwendung möglich ist. Das mag betriebswirtschaftlich  wegen fehlender Geschäftsausgaben nicht sinnvoll sein, aber für Umwelt und Ressourcenschonung besser. Aber jetzt ist mein Terra Notebook fällig.

Das habe ich in schon vor einigen Jahren in mein Büro nach Eppstein verlagert, um da einen PC dauerhaft zu haben. Das Terra-Notebook hat Win 10 und Mint Linux im Dualboot und bisher immer wieder mal gute Dienste geleistet. Aber die letzte Zeit bricht reproduzierbar nach wenigen Minuten die Internet-Verbindung zusammen, wenn ich über Tethering per SmartPhone im Internet bin. Da das sowohl unter Windows als auch Linux der Fall ist, ist wohl der WLAN-Adapter fertig. Zwar könnte man den noch austauschen oder einen externen Adapter verwenden, aber wenn es an einer Ecke zu bröseln beginnt, sind andere Probleme nicht weit. Das Terra-Notebook hat den Ruhestand auch verdient, denn dessen Kauf kann ich ganz genau noch terminieren – 30.12.1999.

Ich werde nun meinen Mac Mini da wieder hinschaffen. Der ist von 2012 und auch nicht mehr taufrisch (Macmini6,2), aber eben nur halb so alt. Darauf habe ich bisher Dualboot mit einem alten macOS Sierra und Mint Linux 22, aber den ganzen macOS-Kram brauche ich echt nicht mehr, zumal der seit etwa 10 Jahren nicht mehr von Apple unterstützt wird. Nun bin ich als Vorbereitung mit ChatGPT daran gegangen, den gesamten Rechner neu zu konfigurieren, um die Ressourcen vollständig mit Linux zu nutzen. Aber ChatGPT hat mich dabei sukzessive ins Desaster geführt.

Linux war nicht auf der SSD (/dev/sda), sondern der HDD (/dev/sdb) installiert. Ich wollte deshalb ein neues Linux auf der SSD installieren  und den Rest plattmachen. Aber ich habe es auch nach Stunden und trotz Hilfe von ChatGPT nicht hinbekommen, dass der Mac Mini von einem USB-Stick gestartet ist. Da ist durch das Apple-Zeug viel blockiert und verbogen, dass nicht einmal Grub beim Hochfahren anzuzeigen ist und EFI sich auf-Teufel-komm-raus nicht umbiegen lässt.

Also kam ich auf die Idee, Linux weitgehend auf der HDD zu lassen und nur Teile wie home auf die SSD zu verlagern. Da hatte ich vorher Platz geschaffen und den alten macOS-Kram weggeräumt – also paritioniert, soweit das ging.

ChatGPT meinte dann, dass auch var und tmp auf die SSD sollten, um das System performanter zu bekommen. Damit ging die Katastrophe los, denn die Verlagerung von var hat (vermutlich) die zig folgenden Probleme bewirkt. Die Trennung von Linux auf zwei physische Platten (zudem eine schnell, eine langsam) löst u.a. Timing-Probleme aus. Plötzlich gab es beim Start zig Fehlermeldungen und auch keine GUI mehr. Jeder weitere Korrekturvorschlag von ChatGPT hat das System mehr zerstört bis hin zum Verbröseln von Python, Plymouth, X-Server, LightDM und anderen ganz elementaren Bibliotheken und Programmen.

Erst nach zig Stunden Arbeit (SSH war zumindest immer möglich) war ich zumindest wieder soweit, dass zumindest apt und dpkg halbwegs ok waren. Nur lightdm hat ChatGPT wirklich so verfriggelt, dass bei einem lokalen Monitor nicht einmal eine Konsole mehr aufgetaucht war. Glücklicherweise ging wie gesagt SSH noch, aber das System war komplett in einem „Halbzustand“ ohne GUI, mit dem man wirklich gar nichts anfangen konnte. Die Wahl war verschrotten oder wo anderes Hilfe zu suchen. ChatGPT habe ich aber zum Teufel geschickt, da die Tipps schon genug Schaden verursacht hatten.

Hilfe kam von DeepSeek, was zwar hämisch die Maßnahmen von ChatGPT auseinander genommen (wie ein Arzt die Behandlungsversuche seines Vorgängers), aber auch tatsächlich sinnvolle Hilfe geleistet hat.

Ich habe XDM nun als Grafikmanager. Das funktioniert und langt mir. Auch die anderen Probleme, die mir ChatGPT reingewürgt hat (etwa ein komplettes weiteres Linux im home-Verzeichnis und zerstörtes Python etc.), konnte ich mit Hilfe von DeepSeek in den Griff bekommen. Zwar ist jetzt nur noch home auf der SSD, aber DeepSeek fand sogar eine einfache Lösung, wie ich schreibend die noch vorhandene alte macOS-Partition nutzen kann (ChatGPT meinte, das ginge unter Linux nur lesend).

Mit Linux läuft die Kiste jetzt wirklich noch gut, denn so schlecht macOS aus meiner Sicht ist, so gut ist die Apple-Hardware an sich. Mit 16 GB RAM und SSD ist selbst die Kiste von 2012  durchaus noch konkurrenzfähig, wenn das Betriebssystem passt.

Timeshift

Oha. Eben habe ich mir doch glatt mein Mint Linux zerschossen und musste es mittels Timeshift wiederbeleben. Also nicht Linux selbst, sondern im Grunde nur Python. Aber das hat apt und apt-get samt der kompletten Anwendungsverwaltung ins Grab gezogen. Nix ging mehr mit Aktualisieren, Bereinigen oder Neuinstallieren. Das zerbröselte Python hat jedesmal zum Abbruch der Aktionen geführt. Richtig brutal. Dabei wollte ich bloß das kleine Problem beseitigen, dass bei meiner Installation von Python unter meinem Mint Linux 22 pip nicht installiert ist. „Timeshift“ weiterlesen

Was ein Gefuddel für Android

Nachdem mir die Raspberry PIs als auch vergleichbare Platinen im Moment einfach zu teuer sind, habe ich mich daran gemacht, ein uraltes Notebook, dass ich vor einigen Monaten mit Deepin Linux neu eingerichtet habe, für die Cordova-Entwicklung einzurichten. Das ist zwar fertig, liegt aber sowieso da rum und einen Test war es mir wert.

Im Grunde geht das Einrichten von Cordova ja auch recht einfach, wenn es nicht die elenden Fallen geben würde.
Einmal ist da im Fall von Android das Problem mit der Java-Version. So richtig geht es – falls man für Android die App erstellen will – nur mit Java 8 bzw. dem JDK 8. Das Problem habe ich schon vor gefühlten Ewigkeiten bemerkt und mir immer damit geholfen, dass ich eben Java 8 installiert habe. Neben den aktuellen Versionen. Leider ist es dann aber blöde, weil man für Gradle-Skripte (zumindest die vorgefertigten von Cordova) die Default-Version von Java auch auf eben dieses Java 8 umstellen muss. Das geht in Linux (Debian, Ubuntu, Mint und Derivate) so:

sudo update-alternatives --config java

In der Folge kann man zwischen den installierten Java-Versionen auswählen und eine davon zur Default-Version machen. Aber dann muss man dann auch noch JAVA_HOME korrekt setzen. Etwa so:

env JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

export JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

Ging unter Deepin als normaler User, aber komischer Weise hat das als root nicht funktioniert bzw. die Einstellungen wurden nicht übernommen. Letztendlich habe ich viel rumgebastelt, wieder viel gelernt, bin aber wie so oft im Grunde gescheitert.
Wobei das Problem mit Java 8 ist vermutlich ein ganz anderes, als man vermutet. Denn vor einigen Monaten hatte ich eine Schulung rund um Java EE gehalten und da hatten wir bei JSF ein ähnliches Problem. Die Meldung sah so aus als wäre die Version von Java nicht passend bzw. zu alt, obwohl sie neuer als die geforderte/angezeigte Version war. Ganz wie hier bei Cordova. Aber dann ist mir aufgefallen, dass die Versionsnummern in dem Framework nur einstellig (!) evaluiert wurden. Also Java 11 oder Java 17 werden als Java 1 interpretiert. So was vermute ich mittlerweile auch bei Cordova bzw. den Gradle-Skripten. Man müsste es mal mit Java 9 testen, aber dazu habe ich im Moment keine Zeit.
Letztendlich ist aber sowieso das Hauptproblem dieses elende Android-Gefuddel. Das Android-SDK und die Android-Tools etc. habe ich nach und nach alle installiert, aber ständig kam die Meldung, dass das Zeug nicht da wäre. Genaugenommen hat das Gradle-Skript diese Meldung gebracht. Letztendlich habe ich sogar das Android Studio auf dem uralten Notebook mit Deepin installiert, dort diverse Fernzugriffservice eingerichtet und gestartet, alle möglichen SDK-Versionen nachinstalliert und sogar ein Cordova-Template im Android Studio als Plugin eingerichtet.
Resultat – das Gradle-Skript weigert sich, die Android-Ressourcen zu finden. Und selbst das Android Studio nimmt dieses Gradle-Skript und kennt sich quasi dann selbst nicht mehr.

Irgendwann hatte ich die Faxen dicke, denn so schön Deepin Linux von der Oberfläche auch ist – es hat so ein paar Macken, die ich von der administrativen Seite nicht wirklich gut finde. Und der VNC- als auch RDP-Zugriff haben darauf ums Verrecken nicht funktioniert. Nur ssh – auch mit X-Umleitung von einem anderen Linux-Rechner.
Apropos anderer Linux-Rechner – das ist mein Terra-Notebook, auf dem ich Windows 10 und Mint Linux im Dualboot betreibe. Unter Windows habe ich das Cordova (auch für Android) mit Visual Studio 2017 im Griff (und im Prinzip auch mit dem Android Studio – das macht aber keinen Spass). Die Linux-Version kann ich aber seit Monaten nicht mehr aktualisieren oder da ein Programm installieren. Die Sache hier war für mich der Anlass, dass Problem mal anzugehen. Denn egal was ich probiert habe die letzte Zeit – mit der Fehlermeldung, dass die Quellen nicht zu lesen wären, haben sämtliche Aktualisierungsversuche als auch Installationsversuche abgebrochen.
Ich bin nun auf den Lösungsansatz gestoßen, dass man die Datei mit einem geeigneten Repo füllen sollte. Etwa das:

sudo nano /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu bionic main restricted

Habe ich gemacht – keine Wirkung!
Dann habe ich endlich die Meldung genauer angesehen – Linux hat nicht die Datei /etc/apt/sources.list beim Installieren/Aktualisieren ausgelesen, sondern die Datei /etc/apt/sources.list.d/vivaldi.list.
Aus irgendeinem Grund wurde der Pfad umgebogen. Wo genau, habe ich noch nicht raus, aber einfach das Repo da reingeschrieben. Und gut ist es – aktualisieren und installieren geht wieder.
Jetzt kann ich auch mal den Linux-Rechner nutzen und versuchen, da Cordova-Apps für Android zu kompilieren. Wenn das auch da nicht geht, habe ich ja immer noch Visual Studio 2017 und meinen Docker-Container.

Und so ganz unwahrscheinlich ist es nicht, dass ich darauf beschränkt bleibe. Denn bei dem Mint-Linux ist node.js und damit auch npm in einer alten Version dabei. Was nicht schlimm wäre, wenn nicht jede Art der Installation, die ich versucht habe, immer diese uralte Version 8 installiert hätte. Mit apt bzw. apt-get entfernt, neu installiert, andere Quellen genommen, verschiedene Package-Manager ausprobiert -> immer die Version 8, obwohl es schon die Version 18 gibt. Ein Problem führt bei den ganzen Aktionen – wie eigentlich immer – zum nächsten.

Ich bin jetzt auf das Level zurückgegangen, dass ich die Quellcodes von Git geholt und dann bei mir neu kompiliert und installiert habe.

Also klassisch

git clone https://github.com/joyent/node.git

Und dann:

./configure
make
make install

Dazu gibt es im Netz eine ziemlich gute Anleitung.

Der kleine Hinweis dort, dass das Kompilieren ein „bisschen länger“ dauert, war aber untertrieben. Ich bin mit der Erwartung von vielleicht 30 Minuten maximal in den make-Befehl rein und nach gut 5 Stunden war noch kein Ende zu sehen. Das Zeug ist dann über Nacht durchgelaufen und heute morgen war es erledigt. Das dauert also brutal lang, wobei mein Terra-Notebook auch schon in die Jahre gekommen ist.

Anyway – die Sache ging durch und nun habe ich node.js bzw. npm in der Version 18. Cordova ist damit auch eben fix installiert und wie es mit Android aussieht, schaue ich mir später an. Das ist ja die einzige kritische Stelle.