Mitdenken

Viel hilft viel…oder noch mal und nochmal…wie bei der Kundin, die unter Win95 den DOS-Treiber ihres ATAPI-CD-ROMs über 30x installiert gehabt hat, irgendwann muß das doch gehen, nich’ wahr (endlose config.sys und autoexec.bat). Mit installiertem Mainboard-Chipset-Driver gibt’s aber nur einen “Kompatibilitätsmodus” (und der wird im DevMan auch angezeigt), sprich das wird gar nichts. Nicht zu reden davon, daß sie damit das stets zu knappe Conventional Memory (wir erinnern uns, 640 KiB, bis 1 MiB Upper Memory Area, darüber High Memory Area) zugepflastet gehabt hat.

An dieses Erlebnis denke ich stets, wenn User Schritt-für-Schritt-Anleitungen tumb abarbeiten, Fehlerausgaben und Warnungen ignorieren und ohne Mitdenken einfach alles wiederholen.

In diesem aktuellen Beispiel versucht jemand, an jenem Portal vor 6 Jahren registriert, meine Anleitung Installation HP Linux Imaging and Printing abzuarbeiten. Daß sie funktioniert, kann ich Rückmeldungen verschiedener User entnehmen, selbst bin ich auch schon danach gegangen (viel später, als ich sie geschrieben habe). Statt bereits bestehende Probleme zu beheben und auch mal aufzuräumen (die Unsauberkeit, der Batzen nicht mehr benötigter Pakete würden mich stören), wird hplip-3.19.8.run gezogen und nochmal und nochmal…sieht man an der durch wget automatisch angehängten Zahl, er ist schon bei “.6”, also 7x.

Es wird überhaupt nicht gelesen, daß hplip bereits installiert ist, Drüberbügeln keine gute Idee ist, daß es einen SegFault gibt etc. Da geht man nicht einfach zum nächsten Punkt.

Ich habe im Blogpost jetzt die Option “-O” hinzugefügt. Das durch wget gezogene File wird mit nachfolgendem Filename gespeichert. Das ist z.B. bei solchen generischen Sachen wie latest.zip sinnvoll. Nötig ist sie in diesem Fall also nicht. Aber zumindest gibt’s bei wiederholtem Ziehen kein Hochzählen, es bleibt bei dem einen File.

Nichtsdestotrotz: Schritt-für-Schritt-Anleitungen schreibe ich natürlich, um anderen zu helfen (und teils auch für mich zur Dokumentation, wenn ich andere Rechner bearbeite). Wer aber nicht logisch mitdenkt, ist bei Linux und Rechnern insgesamt falsch. Bestenfalls reiner Bediener einzelner Anwendungsprogramme, in die er eingewiesen worden ist.

Btw., der Treiber für seinen HP LaserJet Pro P1102 ist in den Repositories für Ubuntu Bionic enthalten, das Gewürge mit externem hplip überhaupt nicht nötig. So ist das, wenn man sich nicht informiert.

Umzug auf neuen vServer der Distribution siduction

Durch den seit Freitag laufenden Umzug der Linux-Distribution siduction auf einen neuen virtuellen Server gibt es seitdem hier und da Probleme, die jedoch schnell gelöst werden. So können Services ausfallen oder wie im folgenden Beispiel Zertifikate noch nicht korrekt eingebunden sein:

Err:3 https://packages.siduction.org/extra unstable Release
  Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected.  Could not handshake: Error in the certificate verification. [IP: 164.68.115.91 443]
Err:4 https://packages.siduction.org/fixes unstable Release
  Certificate verification failed: The certificate is NOT trusted. The name in the certificate does not match the expected.  Could not handshake: Error in the certificate verification. [IP: 164.68.115.91 443]

Das Zertifikatsproblem ist nun gelöst (in der Zwischenzeit hat man auch auf einen anderen Server, bspw. auf spline.de, ausweichen können), aber nun kann folgendes auftreten:

W: Failed to fetch https://packages.siduction.org/extra/dists/unstable/main/Contents-amd64  Could not handshake: Error in the pull function. [IP: 164.68.115.91 443]
W: Failed to fetch https://packages.siduction.org/fixes/dists/unstable/main/binary-amd64/Packages  Could not connect to packages.siduction.org:443 (164.68.115.91). - connect (111: Connection refused) [IP: 164.68.115.91 443]
W: Failed to fetch https://packages.siduction.org/fixes/dists/unstable/main/Contents-amd64  Unable to connect to packages.siduction.org:https: [IP: 164.68.115.91 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.

Nach dem Leeren des DNS-Caches, sofern aktiviert,

1
$ sudo /etc/init.d/dns-clean restart

sind die Fehlauflösungen korrigiert.

VBox: shared folders crashen VMs

Seit VBox v6.0.10 lassen Shared Folders VMs crashen, Windows-VMs, wohlgemerkt, Linux-VMs sind nicht betroffen. Host spielt dabei keine Rolle. Beim versuchten Öffnen eines Shared Folders verkleinert sich das Bild der VM auf einen Ausschnitt, gefolgt von einem nur kurz zu sehenden Systemcrash (so einen mit Smiley). Es ist sogar möglich, daß man nicht mehr auf einen (anderen) virtuellen Desktop des Hosts kommt und man sinnvollerweise über eine virtuellen Konsole rebootet. So das gelingt.

Dies ist reproduzierbar bis inkl. 6.0.11-132407. Ursächlich sind nicht VBox selbst, das Extension Pack sowieso nicht, sondern die Guest Additions, die das SF-Modul beinhalten. GA installiert und SF aktiviert zu haben, zeigen noch nichts, erst beim Öffnen gibt’s einen brachialen Absturz. Um das nicht aus Versehen auszulösen, ist das Deaktivieren von SF erstmal naheliegend.

Mit aktuellem VBoxGuestAdditions_6.0.97-132468.iso scheint das Problem behoben worden zu sein. Das Öffnen eines Shared Folders und diverser Files darin funktioniert wieder wie gewohnt.

Auch, wenn man gemeinhin versionsgleich arbeiten sollte, man braucht nicht die Development Snapshots aller drei Teile installieren, also nicht von VBox und ExtPack, nur genannte GuestAdds.

2019-09-03: Nach mehreren Testbuilds ist nun 6.0.12 final erschienen.
2019-08-10: Mit dem GA-Testbuild 6.0.11-132500 vom -09 ist das Problem auch behoben.

endeavouros, das Image

endeavouros logo
Spielt man mit Links, kann man mit ein wenig Phantasie endeavouros bereits ziehen, auch wenn auf der Website noch nicht offiziell verkündet. Ich bin fair und verrate ihn nicht. :-p

Jedoch weise ich auf bekannte Probleme der Installation hin. Diese hat es auch bei der dritten Vorabversion gegeben (neben kleineren Geschichten). Gerade was die Partitionierung oder (von mir sowieso abgelehntes) Dualboot angehen, sollte man bedacht vorgehen.

Genaugenommen ist das Ganze mit den Problemen noch kein Final Release, aber sei’s drum! Von einer Verschlüsselung derzeit noch abgesehen (ursächlich diese Calamares-Version, upstream zu beheben) ist alles umgehbar.

Tip von mir noch zu einer Installation in einer VBox-VM: Sowohl CSM/MBR als auch UEFI/GPT sollten möglich sein, jedoch sollte als virtuelle GPU VBoxSVGA, nicht VMSVGA (der VMware-Treiber) gewählt werden. Bei letzterer bleibt das Booten einfach stehen.

Nachtrag: So, jetzt ist endeavouros offiziell freigegeben.

Btw., auf Nachfrage Interessierter nach einem Torrent meint Bryanpwo, Project Leader, “Later this week (…).”. Dabei wäre es gerade direkt nach Freigabe, also jetzt, besonders sinnvoll. Man merkt, wie der Server (Strato…) in die Knie geht.

Eine knappe halbe Stunde danach ;) hat das Team weitere Links auf github bereitgestellt, auch zu endeavouros-2019.07.15-x86_64.torrent. Prima.

antergos’ Reinkarnation: endeavouros

EndeavourOS

Der Name

Der Name der neuen arch-basierten Distribution birgt verdammt viel Potential einer Falschschreibung, insbesondere die englische Schreibung statt der amerikanischen (wie schon beim namentlichen Space Shuttle, auf das sich die Protagonisten beziehen). Dazu das Anfangs-“e” und/oder “os” versal oder nicht. Auch, wenn ich gemeinhin die jeweiligen Eigenschreibweisen verwende, werde ich nicht schreiend durchgängig großschreiben, sondern wie bei anderen Linux-Distributionen gezieltes Understatement, also endeavouros (und auch so gesprochen).

Nein, Namen sind nicht Schall und Rauch, im Gegenteil mit Logo/Schriftzug Aushängeschild. Freilich bekommen sie erst durch den Inhalt Bedeutung. Nun, gegenüber antergos (abgeleitet vom galicischen Wort für Ahnen) erscheint mir die Hernahme eines bestehenden und bedeutungsbesetzten Wortes nicht einfallsreich (beim Logo hat es auch einen besseren Vorschlag gegeben).

Der Inhalt

Aber konzentrieren wir uns auf eben den Inhalt. archlinux ist eine Rolling Release Distribution, d.h., es gibt keine Release Dates wie bei den meisten Linux-Distributionen (bspw. letztes Wochenende debian 10 buster, stable, wie langweilig), sondern laufende Aktualisierung. Das funktioniert sogar sehr gut (siduction versucht das auch, aber debian sid, auf dem es basiert, hat per se permanenten Entwicklungsstatus, ist keine RRD für Produktivsysteme, da knirscht es zuweilen bei Transitions gewaltig). Jedoch ist arch keine Distribution für nach-Jahren-noch-nicht-weiter-Ubuntu-User. Das zeigt schon der nerdige Registrierungsvorgang auf archlinux.org (es ist die Ausgabe einer Shell-Befehlszeile zu copypasten).

Nichtsdestotrotz muß man ja nicht alles unnötig erschweren (wobei…Ubuntu hätte es in den letzten Jahren gutgetan…verspielt). So hat vor etlichen Jahren bereits ein Script Dritter die Basisinstallation zeitgemäß angepackt. Das an sich würde auch heute genügen, es muß keine extra Distribution geben. Hat es aber mit cinnarch, das später zu antergos umbenannt worden ist, da Cinnamon nicht mehr das default DE gewesen ist. Die nicht mal Handvoll Macher haben 7 Jahre durchgehalten. Das ist in diesem Metier beachtlich.

Antergos ist sehr nah an archlinux (gewesen), hat nichts zurückgehalten oder verändert wie Manjaro (das bringt diesem immer wieder Kritik ein), nur wenige zusätzliche Pakete in einem extra Repository angeboten und dazu einen anständigen Installer geliefert (auch, wenn cnchi bisweilen Probleme gehabt hat).

Das hat nun auch den Vorteil, daß man aus einem antergos leicht ein arch zaubern kann (antergos-Repo, das eh abgeschaltet werden wird, ‘raus, daraus installierte Pakete und deren Abhängigkeiten deinstallieren, wenn für nötig erachtet, entsprechendes aus einem AUR ähnlich einem PPA wieder installieren). Ja, strikte arch-User werden auch das anders sehen, von wegen nur arch-User wüßten, was sie installiert haben…haha, dem steht aber so manches trübe Posting entgegen.

Ende und Neuanfang

2019-05-21 haben die Maintainer nun bekanntgegeben gehabt, antergos einzustellen (es ist schon etwas im Busch gewesen, da der monatliche Snapshot ausgeblieben ist). Nach nur sehr kurzer Zeit haben sich jedoch dafür neue Leute aus der bislang zweiten Reihe gefunden, die Distribution unter neuem Namen leicht verändert fortzuführen (z.B. mit calamares statt hauseigenem cnchi). Seitdem gibt es gefühlt soviel Traffic im noch bestehenden antergos-Forum und vor allem im seit 2019-07-02 freigeschaltetem neuem endeavouros-Forum (mit endlich brauchbarer Foren-Software statt dieses miesen WP-Plugins) wie in den letzten Jahren nicht.

Dabei gibt es auch Träumereien mancher, was alles ‘rein sollte (welch ein Unsinn – schlank und so original wie möglich), die meisten antergos-User freuen sich einfach, daß es mit frischem Wind weitergeht. Man sollte freilich wirklich nicht vergessen, daß es derzeit nur 3 Enthusiasten sind. Da man jedoch noch näher an arch bleiben will, als es antergos eh schon gewesen ist, sollte die Sache machbar sein. Und Nischendistribution her oder hin, man könnte jederzeit auf archlinux switchen.

Es sind 3 öffentliche Dev-Versionen erschienen. Für heute, 2019-07-15, ist die Final der sog. offline-Version angekündigt. Gut, das ist ein festes Datum, aber es muß ja mal anfangen. ;-)

usrmerge, nachtraeglich

Mit dem Vorhaben usrmerge wird die historisch bedingte Trennung der Systemverzeichnisse “/bin/” und “/usr/bin/”, “/sbin/” und “/usr/sbin/”, “/lib/” und “/usr/lib/”, “/lib32/” und “/usr/lib32/”, “/libx32/” und “/usr/libx32/” sowie “/lib64/” und “/usr/lib64/” aufgehoben. Entsprechende Verzeichnisse und Dateien werden in ihre jeweiligen Pendants unterhalb “/usr/” verschoben und aus Kompatibilitätsgründen Softlinks für die bisherigen Verzeichnisse erstellt (auf den ersten Blick sieht’s daher in “/” nicht weniger aus). Daraus ergeben sich künftig Verwaltungsvorteile.

Als vorletzte der großen Linux-Distributionen (openSuse fehlt noch) hat das in der Nacht zum Sonntag erschienene debian 10 buster diesen Schritt vollzogen – freilich nur bei einer Neuinstallation. Bei einem Distupgrade ist usrmerge manuell anzuwerfen:

1
# apt install usrmerge

Während der Routine wird der Merge abgefragt. Die Sache ist one way. Verneint man, kann man jedoch auch später noch zusammenführen:

1
# /usr/lib/convert-usrmerge

Beim ersten System (von mittlerweile vier verschiedenen, nativ und VM) habe ich sicherheitshalber X geschlossen und in einem tty durchgeführt, es ist aber nicht nötig, es läuft auch in einem Terminal klaglos durch und dauert nur wenige Sekunden (es wird ja nicht wirklich etwas physisch verschoben). Rebooten sollte man jedoch im Anschluß.

Das Ganze betrifft freilich nicht nur buster, sondern auch debian-basierte Distributionen wie siduction (zumindest die immer noch “aktuell” offiziell verfügbare, mittlerweile fast 14 Monate alte Version – es wird bei sid immer einen Grund geben, gerade jetzt keine neue Version bringen zu müssen/wollen, wundern braucht sich keiner, weshalb man Ankündigungen wie denen zuletzt nach dem Berliner Treffen des Core Teams im April keinen Glauben mehr schenkt) und natürlich auch Ubuntu(-Derivate) 18.04 Long Term Sleeping. Letzteres hat, wen wundert es, eine hornalte Version 17, auch 19.10 dev noch. Es geht damit, man kann (und sollte) aber auch die aktuelle Version 22 aus debian sid verwenden.

Firefox: Add-ons deaktiviert

Es ist mal wieder ein Weltuntergang. Jedenfalls, schenkt man manchen Usern Glauben, die da behaupten, ohne Add-ons sei Firefox nicht zu gebrauchen, also denen, die Fx mit ach so wichtigen Add-ons zukleistern. Seit heute Nacht werden in Fx automatisch Add-ons deaktiviert, weil bei mozilla.org Verantwortliche den Ablauf des entsprechenden Zertifikats verpennt haben.

Interessanterweise werden nicht sämtliche disabled, bspw. NoScriptdas ist ein unverzichtbares Add-on – läuft weiter. Wer also nicht sonstige installiert und aktiviert hat, merkt davon nichts. Installieren, auch manuell, wird freilich mit dem falschen Hinweis abgelehnt, das .xpi sei corrupt (auch NoScript).

Der Vorgang zeigt aber nicht nur die Verschlafenheit bzgl. Zertifikaten, sondern vor allem die Unfähigkeit und den Unwillen von Usern zur Recherche. Seit ~3:00 (!) gibt es einen Bugreport auf bugzilla.mozilla.org und seitdem bis jetzt, Nachmittag, 41 (!) Duplicates, also weitere (nunmehr geschlossene) Bugreports desselben Problems.

Bei mozilla.org hat man sich ob der Zahl fortwährender Postings leicht genervt gezeigt (discourse.mozilla.org ist offensichtlich seit Stunden permanent überlastet), aber zumindest gg. Mittag eine Interimlösung mit einem Zwischenzertifikat bereitgestellt.

Zum Zeitpunkt des Schreibens dieses Postings ist Fx 66.0.4 Candidate Build 1 angeboten, dann aber wieder entfernt worden, freilich ohnehin bloß für Redmond OS. Mittlerweile ist Directory Listing für download-installer.cdn.mozilla.net/pub/firefox/candidates/ disabled.

Solange hotfix-update-xpi-intermediate@mozilla.com-1.0.2-signed.xpi ziehbar ist (manuell in Fx zu installieren, allerdings nicht in den ESR-Versionen), ist das jedoch völlig ausreichend. Auch nur ein .xpi-File, das funktioniert aber. Und danach auch wieder installierte Add-ons sowie das Installieren von Add-ons.

Update 2019-05-05, 19:30: Mozilla hat Fx 66.0.4 mit einem Fix bereitgestellt (bei Erststart wird automatisch der eventuell zuvor im User-Profil unter extensions abgelegte intermediate-Fix gelöscht). Gefixte 60er ESR- und 67.0b-Versionen fehlen allerdings noch.

Update 2019-05-05, 21:00: Mittlerweile liegt auch 60.6.2esr vor.

VirtualBox: certificate verification failed

Derzeit, 2019-04-27, hat download.virtualbox.org ein SSL-Zertifikatsproblem (nicht virtualbox.org selbst). Entsprechend schlagen Updates oder eine Installation aus dieser Paketquelle fehl. Wie ich bereits heute morgen geschrieben habe, kann bis zur Behebung statt https das non-secure-Protokoll http verwendet werden.

Wer nach meiner Anleitung VirtualBox: Repository in Ubuntu hinzufuegen gegangen ist oder dies gerade vorhat, kann sozusagen als Punkt 2 1/2 ausführen:

1
2
sudo sed -i s/https/http/g /etc/apt/sources.list.d/virtualbox.list
sudo apt update

Haben die Admins (sicherlich nicht vor Montag) das Problem behoben, sollte man selbstverständlich auf https zurückgehen:

1
2
sudo sed -i s/http/https/g /etc/apt/sources.list.d/virtualbox.list
sudo apt update

Btw., was das (temporäre) http angeht, ja, nicht schön (Ubuntu-User sollten sich mal diesbzgl. die Mainserver und offiziellen Mirrors ansehen, haarsträubend), aber zumindest oracle_vbox*.asc kommen weiter über https.

Update 2019-04-29: Problem behoben. Ich lasse den Post stehen…für’s nächste Mal. ;) Zumindest ist es ein gutes Beispiel, wofür man das Urgestein sed nutzen kann.

Ubuntu 14.04: End of Support

Von Ausnahmen wie bei Ubuntu 6.06 Dapper Drake und hin und wieder Verschiebungen von Point Releases abgesehen sind einmal angesagte Release Dates bei Ubuntu fix. Nicht so bei EoS oder auch EoL. Vielleicht liegt es daran, weil’s eh keinen mehr sonderlich interessiert (wer jetzt immer noch Trusty fährt, pennt schon seit mindestens Bionic, eher Xenial.1 oder sowieso Utopic). Beim anstehenden EoS von 14.04 Trusty (die Derivate wie Lubuntu sind bereis seit 2 Jahren EoS) ist meist nur von 2019-04 zu lesen. Es gibt aber auch den Stichtag 2019-04-25, also in 3 Tagen.

In distro-info-data_0.39ubuntu1_all.deb liest man dagegen vom 2019-04-17, demnach ist Trusty bereits seit 5 Tagen Geschichte (von der extra zu bezahlenden ESM, Augenwischerei, abgesehen). Dieses Paket für Disco ist übrigens knapp 2 Monate älter als distro-info-data_0.38ubuntu0.3_all.deb für dessen Vorgänger Cosmic.

Letzteres datiert auf 2019-04-18 und beinhaltet den Code Name für Ubuntu 19.10, zumindest den ersten Teil: Eoan. Der zweite, “Eanimal”, ist quasi ein Platzhalter (Update 2019-05-06: Eoan Ermine, sinngemäß “Hermelin in der Morgendämmerung”, Release Schedule).

Ob nun diese oder letzte Woche. Fakt ist EoS für Trusty. Distupgrade oder weit sinnvoller Neuinstallation von Bionic.2 oder Disco. Jetzt!

Lubuntu 19.04 Disco Dingo torrents

Kurz notiert: Heute im Laufe des Tages wird Lubuntu 19.04 freigegeben.

Torrent für Lubuntu Disco Dingo:

Mit x86_32-Images (“i386”) ist es nunmehr auch bei aktuellem Lubuntu vorbei. Von LCosmic32 könnte man noch distupgraden oder über x86-mini.iso LDisco32 installieren. Beruhigend ist das freilich für User, die noch x86-only-CPUs einsetzen (es hält sich der Irrglaube, es handele sich nur um die vorletzten P4-Heizer oder ersten Atoms), nicht, geschehen doch Brüche häufig von jetzt auf gleich. Mindestens ist das Ende absehbar.

Von Cosmic muß bis dessem End of Support im Juli gedistupgradet werden. Wer dagegen tatsächlich noch schlafwandlerisch Ubuntu Trusty einsetzt (Trusty-Derivate sind bereits seit 2 Jahren EoS), hat nur noch 1 Woche Zeit, endlich auf mindestens Xenial zu distupgraden oder besser Bionic oder Disco zu installieren.