Transitions

Wer Distributionen wie siduction oder einfach nur sid fährt (das sind keine normalen Rollings Release Distributions wie Arch basierte, sondern sid ist debian unstable, Dev-Version, siduction nicht viel mehr), sollte wissen, was Transitions bedeuten, und beim Anstoßen von Updates genau hinsehen. Wenn da bei einem

1
sudo apt update; sudo apt full-upgrade

locker ein paar hundert Pakete als “to remove” angezeigt werden – und das fällt schon optisch auf – gerät man nicht in Panik (“Y” ist großgeschrieben und ein Return wäre fatal) und bricht selbstverständlich mit “n” ab. Gibt es in einem Forum dafür jeweils “upgrade warnings”, ist das zwar nett, aber nicht unbedingt nötig (wobei da manche unverständlicherweise trotzdem immer wieder aus allen Wolken fallen, weswegen ich das Thema erneut aufgreife).

Solche Transitions können auch länger dauern, perl zuletzt ~2 Wochen. Und kaum ist das gegessen, geht’s aktuell mit qt5 (auf Qt 5.12) weiter.

Abbruch bedeutet freilich gar keine Updates, sprich auch keine anderen. Man kann bestimmte Pakete auf hold setzen, abhängende Pakete (die es ja eben vielfach in neuer Version noch nicht gibt) werden so ebenfalls nicht mit aktualisiert bzw. wird nicht einfach alles ‘runtergeworfen, weil unvollständig. Bspw. bei der perl-Transition ist es nur das Paket perl gewesen:

1
sudo apt-mark hold perl

Bei der letzten qt5-Transition hat (hier) das Paket libqt5core5a genügt. Diesmal nicht ganz, ich habe noch qtbase5-dev dazunehmen müssen:

1
sudo apt-mark hold qtbase5-dev libqt5core5a

So kann man relativ gefahrlos upgraden (sofern man das bei siduction überhaupt sagen kann). Ist komplett umgestellt, setzt man die Pakete wieder auf unhold

1
sudo apt-mark unhold qtbase5-dev libqt5core5a

und aktualisiert. Das ist dann ein kleiner Nervenkitzel. ;)

Btw., auch wenn mal nur 1…2 Pakete deinstalliert werden sollen, überprüft man das. Meist werden sie durch neuere, die im Paketnamen tatsächlich eine höhere Zahl beinhalten, ersetzt.

Lubuntu 19.10 Eoan Ermine torrent

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

Torrent für Lubuntu Eoan Ermine:

(Ja, bei cdimage.ubuntu.com schafft man immer noch kein https.)

Ein weiteres Stück entfernt Canonical Ubuntu von dem, was Linux ausmacht. chromium ist mit hanebüchener Begründung nur noch als snap verfügbar, nicht mehr als .deb über die Paketverwaltung.

Der Codename für das April nächsten Jahres erscheinende Ubuntu 20.04, wieder Long Term Sleeping, lautet Focal Fossa.

Linuxium integriert 32-bit-EFI-Bootloader

Manchmal hat man so Eingebungen. Ich habe kürzlich ein LDisco-Image mit isorespin.sh veredelt, noch ohne es praktisch testen zu können. ;) Dieses Script schreibt Linuxium (Ian Morrison), um einen UEFI32-Bootloader in ein Ubuntu64 zu integrieren (Canonical/Ubuntu sind ja unfähig/zu ignorant dafür). Billigst-Notebooks (~220 €) haben leider sowas. Dort kann man weder ein Linux 32 bit noch ein Linux 64 bit booten und installieren (oder live zum Retten ach so wichtiger, aber eben nicht gesicherter Dateien auf verkorksten Win-Installationen).

Sein Blogpost dazu – nur dazu – ist (sicherheitshalber) in LibO gecopypastet 64 A4-Seiten lang. =:-)

Aber das Image bootet auch mit BIOS/CSM, UEFI64 und eben UEFI32. Bisher sind mir kaum solche Notebooks untergekommen, obwohl es die schon seit Jahren gibt, bzw. habe ich auch keine zeitliche Möglichkeit zum Testen gehabt. Kurz nach der Erstellung hab’ ich doch zuerst ein billig-Tablet mit x5 auf dem Tisch gehabt. Das hat schon mal gebootet, allerdings mit einem Black Screen geendet. Gut, hätte man sicherlich noch mit Boot-Optionen deichseln können.

Kurz danach so ein mickriges Captiva mit Atom Z, 2 GiB RAM abzgl. shared mem und MMC mit krummem 30-GiB-Wert. Mit Linuxium-Lubuntu live einwandfrei gelaufen (das Paket für den WLAN-NIC wird bei der Erstellung des Images integriert, funktioniert dann ootb). Für das, was die Kundin mit dem Billigteil anstellen will, hätte dieses Gesamtpaket völlig gereicht und vor allem Ressourcen nicht unnötig belegt. Aber es hat eben ein Betrübssystem, x86_32, sein sollen…schade drum. Und nach Installation von LibO, AR und Chromium-based Edge und trotz Aufräumens nach kumulativer Updates gerade noch soviel frei, um auf 1909 upgraden zu können (gut, das sind von 1903 mit aktuellem Patchlevel aus nur 20 KiB, aber mit 20H1 wird es dann wieder die übliche Größe). Wenn sie bis dahin diszipliniert mit dem Space umgeht.

Nächster Proband. MacBook 2,1, Baujahr 2007. Liegt eigentlich schon auf dem Schrott, was dann doch ärgert. Verbaut ist ein Intel T7400 Merom, also C2D, sprich 64-bit-Erweiterung, 2 GiB RAM abzgl. shared mem für den GMA950. Dort geht quasi außer der uralten OSX-Version gar nichts aktuelles drauf, jedenfalls nicht von Stick und auch nicht vom Slot-in-ODD.

Einer erneuten Eingebung folgend habe ich heute besagtes Linuxium-LDisco von Stick (das ziehe ich natürlich mit dd drauf) gebootet und installiert. Ja, das damalige Cupertino-EFI ist was sehr spezielles gewesen, also damals schon (Consumer-Mainboards haben zu der Zeit noch kein UEFI gehabt). Jedenfalls bootet das auch Linuxium-präpariert, ja, dauert. Im EFI-/GPT-Mode installiert (manuelle GPT-Partitionierung artet gegenüber MBR aus, automatisch schafft’s der Installer aber auch nicht). Nach Reboot von HDD läuft es dann auch. ;)

Da ich hier die gesamte Zeit isorespin.sh so hochhalte, das Script (am Ende mit Binärteil, der 32-bit-Bootloader) ist für die eigentliche Sache Spitze, keine Frage. Aber mal eben so ist nicht, man sollte sich schon damit beschäftigen. Es startet ein Frontend, so man es mit installiert, aber jedes, wirklich jedes, Fenster hat andere Maße, was enorm nervt. Da wird auch nichts gespeichert.

Auch keine der zahlreichen Optionen, um sie bei einem weiteren Testlauf zuerst laden zu können. Hier liegt echt Potential für nächste Versionen. So ist es ratsam, beim ersten Mal mit Frontend laufen zu lassen, um aus dem Logfile (wird überschrieben, also extra speichern) wesentliche Optionen für die folgenden Starts in einem Terminal zu nehmen, also nicht mehr grafisch. Das ist dann auch nicht schwerer, im Gegenteil auch sehr viel schneller, Stichwort bash-history.

VBox 6.0.13 laeuft mit Kernel 5.3 im Host

Vor zwei Tagen ist Kernel 5.3 erschienen, die ersten Distributionen beginnen, ihn auszuliefern. Klar, keine verstaubten á la Long Term Sleeping, sondern die, die stets vorn dran sind, so arch bzw. arch-basierte wie endeavouros.

Mit VirtualBox hat man bis gestern auch keine 5.3rc nutzen können. Mit Testbuild VirtualBox-6.0.13-133347-Linux_amd64.run (GA 6.0.13-133316, EP 6.0.13-133347) wird nun ordentlich gebaut, VMs starten und laufen. Tests mit endeavouros und siduction als Hosts.

Btw., VBox 6.1.0b1 ist erschienen (dev-snapshots auf der testbuilds-site sind bereits höher, mehr bleeding edge geht dann aber nicht). Wie ich vor 4 Wochen schon geschrieben habe, VBoxVGA ist nun entfernt worden, es ist also auf VBoxSVGA oder, dort, wo es nicht crashed, VMSVGA zu wechseln.

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.