endeavouros 2019-12-03

Nachdem der monatliche Build endeavouros 2019-11-19 zurückgezogen worden ist (natürlich 5 min nachdem ich die 1.6 GiB gezogen gehabt habe, 8-)), kurz genannte Probleme habe ich freilich nicht verifizieren können und hätte das Image durchaus verwendet, ist gestern Nachmittag der Snapshot 2019-12-03 als Final veröffentlicht worden.

VBox-(upstream-)Probleme (VMSVGA, vboxsf) bestehen fort, sind jedoch nicht dringlich, da umgehbar.

Project Leader Bryan Poerwoatmodjo (Bryanpwo) schreibt zwar, “this interim release is just to address the Kalu problem”, aber es ist weit mehr als nur das einfach zu deinstallierende kalu (dessen Abhängigkeiten beißen sich mit denen von pacman, verhindern daher Aktualisierungen, und wird zudem nicht weiterentwickelt), werden doch Grundkomponenten Kernel, Mesa, Systemd und weiteres aktualisiert.

Wer neu installiert, will ja nicht gerade das Oktober-Image oder gar das August-Image (der Vorschlag ist gestern in einem Thread bei einem Wayland-Problem eines Users gefallen…bei einer Rolling Release Distribution) verwenden, um hernach quasi alles updaten, sprich neu ziehen, zu müssen.

User mit bereits laufendem System interessiert’s (erstmal) nicht, nur wenn man das aktuelle Image als Sicherheit im Werkzeugkasten haben will.

Btw., Bryanpwo (NL). Dieser ist äußerst rührig. Bspw. habe ich ihm vorgestern kurz geschrieben, daß Links im Light-Theme des Forums farblich nur schwer als solche erkennbar sind (das hat man auch gemerkt, wenn User irritiert nachgefragt haben, wo sie denn klicken sollen). Quasi in derselben Minute hat er die Linkfarbe geändert. Spitzenmäßig.

VirtualBox: libvpx5, libvpx6

virtualbox.org bietet derzeit Ubuntu-deb-Pakete nur für die letzten “LTS”-Versionen an. Üblicherweise sind diese auch für die normalen Versionen dazwischen nutzbar, sofern Abhängigkeiten erfüllt werden. So hat man VBox 6.0.14 für Bionic auch unter Cosmic und Disco installieren können. In Eoan schlägt dies allerdings fehl, da “libvpx5 (>= 1.6.0)” durch libvpx6 ersetzt worden ist.

Möglichkeiten – oder, nicht und:

  • Manuelle Installation von libvpx5 aus Disco in Eoan:
    1
    2
    
    wget http://archive.ubuntu.com/ubuntu/pool/main/libv/libvpx/libvpx5_1.7.0-3_amd64.deb
    sudo dpkg -i libvpx5_1.7.0-3_amd64.deb

    Updates dafür gibt es so natürlich keine, man muß sich selbst darum kümmern. Vor allem sollte man diese Geschichte nicht vergessen und sie wirklich nur als temporäre Sache sehen und libvpx5 bei nicht-mehr-Nutzung wieder purgen.

  • Für Eoan gibt’s 6.0.14-dfsg mit der Abhängigkeit “libvpx6 (>= 1.6.0)” in den Ubuntu-Repositories. Bis Ubuntu wie üblich wieder abgehängt wird, kann man diese Version installieren, vorher aber tunlichst die virtualbox.org-Version deinstallieren.
  • Alternativ zu deb-Paketen kann man .run installieren (für Updates gilt dasselbe). Benötigt man Testbuilds (bspw. ist VBox 6.0.15-134529 mit Kernel 5.4-rc7 im Host kompatibel), kommt man sowieso nicht umhin.

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.