Bodhi Linux…Gruss aus der Gruft

Möglicherweise denkt der Eine oder Andere, ich hätte einen uralten Bodhi-Linux-Blogpost ‘rausgekramt. Tatsächlich ist nach langem Siechtum und einem dortigem Fahnehochhalten-Artikel letzten Juni heute Bodhi Linux 5.1.0 released worden.

Symptomatisch: je weniger Manpower, desto mehr Versionen.

Bodhi Linux setzt bekanntlich auf Ubuntu Long Term Sleeping auf, hier also 18.04. Wenn dessen offizielle Flavors wie Lubuntu EoS erreicht haben, also in 1 Jahr, ist automatisch Schluß mit x86_32. Wozu dann jetzt noch eine solche Bodhi-Version?

Zumal man offensichtlich dafür einen eigenen Kernel anbietet, einen ohne PAE. Mit der Bootoption forcepae kann man bekanntlich seit über 6 Jahren auch die normalen Ubuntu-Kernel auf Pentium M booten – und um die ist es sehr lange Zeit noch gegangen und ganz sicher nicht um VIA-eSchrott.

Dann spleist man weiter auf in x86_64 Xenial-Urkernel und HWE-Kernel (als wenn man die nicht selbst wechseln könnte). Die Behauptung “The Standard release does not push kernel updates on the user.” ist dabei völliger Unsinn, klar gibt es Kernel-Updates, aber kein solches Kernel-Upgrade (auf HWE). Alles andere wäre auch ein Sicherheitsfiasko.

Zuguterletzt findet sich dann noch eine Version mit allerlei Paketen von Anwendungen (als wenn man die nicht bei Bedarf mit 1 apt-Zeile selbst installieren könnte).

Das Ende des Promotionvideos zeigt die angeblichen Minimum Requirements. Ja, vor Zeiten, so um 2013 herum, ist Bodhi Linux tatsächlich mal relativ genügsam gewesen. Ich habe es einige Male installiert und genutzt gehabt, hauptsächlich in VMs, im Host, sprich Hauptsystem, allerdings einige Jahre Lubuntu mit Enlightenment, vergleichbar. Das ist freilich schon ewig her (ich bin dann wieder zurück auf damals LXDE, schon weil e17 EoS gewesen ist), aber auch da ist eine Angabe 512 MiB Blödsinn gewesen, auch schon mit e17 (und mit e18 und e19 sowieso). 1.5…2 GiB haben es damals schon sein sollen und möglichst nicht die mieseste GPU (sowas wie VBoxVGA mit OpenGL in Software), um auch etwas sinnvolles damit anstellen zu können.

Jeff Hoogland ist mit den Enlightenment-Devs nicht konform gegangen und hat e17 als Moksha geforkt gehabt. Was bedeutet, alles allein stemmen zu müssen. Daß er nicht der Langzeitdurchhaltestärkste ist, ist wahrlich kein Geheimnis (und auch jetzt steht er längst nicht mehr in der ersten Reihe, mal wieder).

Wie auch immer, sieht man sich das Video an, glaubt man sich um 8 Jahre zurückversetzt. Wie auf der Website die gleiche farbliche Geschmackskatastrophe. Man könnte sagen, so gut wie alle (irgendwo ziehbaren) Themes haben diesen Kaugummi-Kindergarten-Touch (viele kommen von Russen, die mögen das wohl), aber Jeff selbst hat die Releases und die Site nie in was anderes getaucht gehabt. Ich habe damals zwei der extrem seltenen halbwegs seriös wirkenden Themes verwendet gehabt (eines für e17, eines für e18+ – das kommt ja noch dazu, die sind nicht kompatibel zwischen den EFL-Versionen).

Etwas positives hat Enlightenment für mich unterm Strich tatsächlich gebracht: die Mehrfachmöglichkeiten zum Start von Programmen (wie auch bei anderen DEs) habe ich für mich als völlig überzogen gesehen, aber über Rechtsklick irgendwo auf dem Desktop, wo man gerade ist, prima. Nun, das hätte man auch bei OpenBox ohne drübergelegtes LXDE oder modern LXQt. Am schnellsten geht’s eh mit Tastenkombi Terminal und dort ‘reingetippt. ;)

Zurück zu Bodhi Linux. Muß man sich’s heute noch antun? Wohl kaum.

VBox: shared clipboard in v6.1.4

In VirtualBox v6.1.4 funktioniert das shared Clipboard zwischen Linux-Host und Linux-Guests nicht (paste ist ausgegraut). Genaugenommen bereits seit VBoxGuestAdditions_6.1.3-135994.iso, zumindest habe ich das Fehlverhalten dort schon bemerkt gehabt, es aber für’s Erste mit dem zu der Zeit gerade neu installierten Host mit anderer Linux-Distribution in Verbindung gebracht. Ursächlich sind aber tatsächlich die GA. Seit 9 Tagen gibt es auch Bugreport und Diskussion(en), wie dem zu begegnen wäre.

Es sind auch wirklich nur die GA, d.h. man kann 6.1.2, die vorige Final, installieren, sicherlich auch ein 6.1.3er dev-build vor obiger Version, so man noch hat.

Seit nicht mal einer Stunde gibt es (endlich wieder) ein aktuelles trunk dev-snapshot (VBoxGuestAdditions_6.1.97-136310.iso), so eine typische Versionsnummer .97 dafür. Damit funktioniert Linux-Host <> Linux-Guest wieder einwandfrei. VirtualBox-6.1.97-136310-Linux_amd64.run muß man nicht installieren.

Lieber mögliche neue Bugs als sichere alte Bugs. ;-)

Update: Statt des Snapshots kann seit 2020-03-04 das jeweils aktuelle 6.1.5er Testbuild verwendet werden.

VBox: stuttering in yt

VMs in VBox eignen sich für wirklich vieles, aber nicht gerade für yt. In Firefox (und wohl auch Chromium) starten Videos nicht wirklich, es wird scheinbar ewig gebuffert. Man muß mehrfach stoppen und starten, bis es weiter geht…ein wenig.

(Nicht nur) in diesen Browsern gibt es unter Linux keine Hardware-Unterstützung durch die GPU, geplant ist bislang auch nichts (nicht mal im closed source Chrome). D.h., das Rendering hat die CPU in Software zu übernehmen. In nativen Linux-Installationen macht sich das nicht bis kaum bemerkbar, so man nicht gerade eine Schippe Sand als CPU hat. In VBox-VMs allerdings eben schon, zumal die GPU-Treiber VBoxSVGA und VMSVGA dahingehend auch nicht die stärksten sind.

In altägyptischen Flash-Zeiten hat es mal den Workaround gegeben, per Rechtsklick (oder auch kleiner Konfigurationsdatei) im Video HW-Unterstützung zu deaktivieren, also das, was eh nicht da ist. Flash, ohnehin nie für Videos gedacht, ist aber tot (und nein, solchen Dreck installieren wir auch nicht, User ohne Plan aus einem bestimmtem Forum), mithin auch diese Einstellmöglichkeit.

Das problematische OpenGL in Hardware ausknipsen hilft bei diesem Fehlerbild auch nicht. Auch nicht, den Original-Firefox zu verwenden statt des Kompilats der jeweiligen Linux-Distribution (in debian gibt es gerade mal ein Problem, was so umgehbar ist). Alles bereits ausprobiert.

In Fx’ “about:config” gibt es mehrere Probanden, die zu testen wären. Ohne die Ursache zu kennen, ist das aber eher ein trial & error. Defaults eines frischen Profils bringen auch nichts.

Nun hat das Ganze früher mal ohne zu stottern funktioniert. Da es für mich aber keine Priorität hat (ja, das gibt es, User ohne Plan aus einem bestimmtem Forum), bin ich dem bislang nicht nachgegangen.

Um zum Punkt zu kommen, yt streamt in VP8/VP9. Eine Hardware-Unterstützung gibt es dafür bisher kaum, wohl aber für H.264. Als Linux- und OSS-Verfechter würde man natürlich lieber ein freies Format verwenden, an der Stelle muß man abwägen.

Allein Codecs installiert zu haben, genügt nicht. Dem Browser muß gesagt werden, daß er H.264 verwenden, d.h. von yt anfordern soll. Gibt’s sicherlich auch eine Möglichkeit unter “about:config”, denn etwas anderes wird das Fx-Add-on h264ify auch nicht verändern. Als Quickfix mag es genügen – und es funktioniert einwandfrei.

Btw., wenn man ein Add-on zum Ändern des User Agents installiert hat, kann man auch eine brauchbare Kombination aus OS und Browser ermitteln, dann wird H.264/mp4 gestreamt und man braucht nichts extra.

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.

Update 2019-12-11: VBox 6.1.0 liegt auch als .deb für Eoan vor, d.h. dort ist libvpx5 keine Abhängigkeit.

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.

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.

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.

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!