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.

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!

Lubuntu 19.04 Disco Dingo torrent

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.

·

Update: End of Support 2020-01.

VirtualBox: Kernel 5.0 nun auch im Guest

VirtualBox 6.0.4 kommt mit Kernel 5.0.x zurecht – aber nur im Host. In einer Linux-VM bislang nur ohne GuestAdditions, auch nicht mit 6.0.5er Testbuilds oder auch 6.0.97er Development Snapshots – bis heute.

Endlich (und wir sind schon bei Kernel 5.0.4, 5.1 liegt bereits als rc2 vor) werden mit VBoxGuestAdditions_6.0.5-129577.iso die Module gebaut (Nachtrag: mittlerweile sind höhere Testbuilds erschienen). Es können damit aktuelle Kernels in Virtual Machines bzw. auch entsprechend aktuelle Linux-Distributionen (antergos, siduction) in VMs genutzt oder getestet werden (selbst LDisco ist seit kurzer Zeit nach ewigem Stillstand auf aktuellen Kernel gewechselt – mit 5.1 wird das allerdings bis zum Release nichts mehr).

Die GA allein sollten zwar genügen, ich setze freilich seit langem insgesamt aktuelle Testbuilds von VBox, GA und EP ein (so nicht gerade mal ein Release aktueller sein sollte…für einen kurzen Zeitraum).

Update 2019-04-16: VBox 6.0.6 ist erschienen.

Xenial-Kernel baut nicht mit VBox 6.0.4

Kurzhinweis: Nach diversen User-Berichten (genauer seit Tagen immer wieder gleichen Anfragen) sollen im Host Kernel-Module der Ubuntu-Kernel-Version 4.4.0-143.169 nicht mit VBox 6.0.4 gebaut werden können.

Lösungsmöglichkeiten:

  • Vorgänger-Kernel verwenden
  • Nachfolger-Kernel 4.4.0-144.170 (proposed) installieren
  • HWE-Stack installieren, also mit derzeit Cosmic-Kernel 4.18.0-16.17 oder 4.18.0-17.18 (proposed)
  • Mainline-Kernel 5.0.4 installieren

Ferner natürlich noch Distupgrade auf Bionic.2 oder besser saubere Installation von Bionic.2 oder Cosmic (oder gleich LDisco daily build).