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).

https-Fix fuer apt

Das Sicherheitsproblem CVE-2019-3462 in apt (“Content injection in APT http method when using redirects”) ist gefixt worden – in debian (debian security tracker) und Ubuntu (Ubuntu CVE Tracker) und somit auch deren Derivaten (sofern diese nicht irgendwas zurückhalten, ich sage nur Mint). So weit, so gut.

apt ist nun nicht irgendwas, sondern das Package Management Tool debian-basierter Distributionen. Das checkt Repositories und deren Inhalte und installiert daraus Pakete, also auch bei jedem Update. Welche Server und Repositories, steht in “/etc/sources.list” und/oder “/etc/sources.list.d/*.list”. Also sollte man überprüfen, ob da nicht über http statt https angefahren wird.

Jetzt kann man aber nicht blauäugig überall ein “s” für secure dazumalen, denn der Stand der Mirrors dazu ist aus einem Land vor unserer Zeit.

So gibt es https für archive.ubuntu.com, immerhin der Mainserver (!), bis heute nicht, nicht mal – und das ist der Hit – für security.ubuntu.com (für packages.ubuntu.com schon, das ist aber nur eine Search Engine, die dann eben auf die Mirrors linkt). Bei den offiziellen (Load balancing) Mirrors sieht es kaum besser aus. Das ist noch nett ausgedrückt. Der südafrikanische Mirror (einziger für Afrika), hat kein https, sämtliche 13 asiatischen sind nicht sicher, von den 12 amerikanischen ist es wenigstens die Hälfte. Und das tolle Europa? Von den 13 Mirrors weiß 1 (in Worten einer) etwas von https, der französische. Also nichts mit ach so sicherheitsbewußtem Deutschland (beim Server der TU Dresden ist man schon froh, wenn der überhaupt funktioniert, weshalb seit Ewigkeiten in uude davon abgeraten wird).

In siduction sollte man auch mal “/etc/apt/sources.list.d/*.list” überprüfen. Die Listen des letzten offiziellen Releases vom Mai sind dahingehend nicht aktuell. So kennt ftp.uni-stuttgart.de nach wie vor nur http (und ftp…), ftp.spline.de (FU Berlin) jedoch auch https. Man sollte also bspw. dahin wechseln.

Nachtrag: Wie wichtig der apt-Fix ist, zeigt das Release von debian 9.7, das in dem vergleichsweise dazu riesigen Image als einzige Änderung das Fitzelchen gefixten Code enthält (Paket base-files).

Der letzte Absatz im pro-linux-Artikel mit dem “problemlos weiternutzen” ist allerdings nicht weit gedacht. Welches Tool hat denn das Update von apt installiert? Dann hätte man schon AllowRedirect=false setzen müssen, wie von devil aufgeführt. Oder manuell von einem offiziellen Server über https ziehen, sha256-checken und mit dpkg installieren.

Ubuntu: vaapi unter chromium entfernen

Man sollte wissen, was man installiert hat, erst recht als Linux-User.

Jener weiß es offensichtlich nicht. Er spricht von “google-chrome” in Version 71.0.3578.98 (schon der Zusatz 64 bit wäre überflüssig, da es Google Chrome für Linux seit langem nur noch für x86_64, also nicht x86_32, gibt).

Google Chrome ist längst weiter, schon die Abfrage unter siduction ergibt für chromium, die OSS-Variante, 72.0.3626.53-1. Dagegen ist genannte 71er derzeit genau die für chromium unter Ubuntu Xenial bis Disco.

Wir halten also fest, er hat chromium und nicht google-chrome installiert. Und jetzt müßte man sich auch mal richtig informieren, vor allem, wenn man Support geben will. pro-linux.de berichtet, daß ein längst bereitstehender, jedoch wegen möglicher Probleme bislang nicht freigeschalteter, Patch in chromium übernommen worden ist – in Fedora und Ubuntu. In letzterem ist es ein unsägliches Snap-Paket. In den chromium-Settings Hardware-Unterstützung deaktiviert zu haben, genügt dabei offenbar nicht.

Den proprietären Treiber nvidia (technisch besser als der freie nouveau, Kunststück bei Infos unter Verschluß, aber ständig inkompatibel zu bestimmten Kernel- und VBox-Versionen) nicht installieren, stattdessen nouveau nutzen wollen, kann ich verstehen (ich fahre auch nur noch nouveau nach ehedem langjährigem Support meinerseits für nvidia auf diesem Portal). Am besten, man kickt dieses unsägliche Snap und damit eben auch dieses Paket.

1
2
sudo apt purge snapd
sudo apt autoremove

Zudem kann man chromium mit Variablen starten.

2019-01-24, Nachtrag: Besagter Threadstarter, seit 11 Jahren dabei, sieht noch nicht mal, was er falsch macht, daß er unsauber arbeitet. Er schafft es auch nicht selbst aus diesem Chaos heraus. Aber Lamento gegen nvidia. Installationen und Reparaturen selbst verkorkster nvidia-Installationen habe ich hunderte Male erklärt (Suchmaschine → Hilfe zur Selbsthilfe). Das ist der Hauptgrund, weshalb ich mich dort nach langjährigem Support ausgeklinkt habe.

Ubuntu: Kernel-Inkonsistenzen

Das muß mir mal jemand erklären…

PackagePPAReleaseUpdatesProposed
bionic/linux4.15.0-44.474.15.0-20.214.15.0-43.464.15.0-44.47
bionic/
linux-hwe
4.18.0-14.15
~18.04.1
4.18.0-13.14
~18.04.1
4.18.0-14.15
~18.04.1
cosmic/linux4.18.0-14.154.18.0-10.114.18.0-13.144.18.0-14.15
disco/linux4.18.0-11.124.19.0-11.12

…nicht wirklich.

Nach dem Desaster vor einem Jahr (1, 2, 3), bei dem Canonical (sicherlich nicht nur) bei mir jegliche Reputation verloren hat (Unbrauchbarmachung von Hardware – nur wer auf CSM only gesetzt gehabt hat, ist auf entsprechenden Boards dem GAU entgangen – und vor allem der Umgang mit dem massiven Problem), ist man dort seitdem von Konservatismus beseelt, sozusagen ins Gegenteil verfallen (wenn man mal annimmt, bislang seien sie up-to-date gewesen, zumindest in ihrem Rahmen).

Read more “Ubuntu: Kernel-Inkonsistenzen”

VirtualBox: Installation ueber .run

Altägyptisch oder bleeding edge. Aktuelles Beispiel: In siduction wird anders als in sid Kernel 4.20 installiert (towo ist da glücklicherweise agil). Wer VirtualBox aus den debian-Repositories nutzt, bekommt bislang nur 5.2.22, das jedoch inkompatibel zu Kernel 4.20 ist.

VBox 6.0.0 ist kompatibel zu Kernel 4.20. Man kann zwar das VBox-Repo einbinden, daraus aber nur für debian stable und oldstable installieren, was im Normalfall unter sid(uction) wegen Dependencies fehlschlägt. Für Ubuntu gebaute Pakete in debian installieren ist auch nicht die gescheiteste Idee (auch wenn die für Bionic momentan laufen sollen).

Dann sollte man so flexibel sein und die .run-Files nutzen, statt wie ein User im siduction-Forum zu jammern, er wolle nur installieren, was “über apt oder dpkg” geht, und deshalb bei der letzten 4.19 bleiben (von der Paketverwaltung abgesehen, was er meint und womit er natürlich Recht hat, erntet er meinerseits dennoch Unverständnis, man fährt doch keine bleeding-edge-RRD, um ausgerechnet beim Kernel stehenzubleiben bzw. zurückzugehen). Fremdpakete aus Sicht der Distribution sind es so und so, aber in diesem Fall bzw. aus Sicht VBox’ sind sie das Original.

Das Ganze ist auch nicht schwieriger, mehr noch, man kann das so unter diversen Distributionen durchführen, bspw. unter siduction und antergos die jeweils selben .run-Files (braucht sie also auch nur 1x ziehen) und bis auf sudo vs. root-Terminal gleich. Zudem kann man Testbuilds nutzen, die ihrerseits ggf. Fixes ggü. dem letzten Release enthalten. Der einzige Nachteil ist lediglich, daß man sich selbst um neue Versionen kümmern muß (und das Interesse für derlei setze ich bei Usern, die bewußt brandaktuelle Distributionen fahren, voraus).

Ich selbst nutze seit längerem VirtualBox*.run unter (bis vor einiger Zeit noch Lubuntu,) siduction, antergos (die gemischte Groß-/Kleinschreibung für solche Namen ist übrigens kein ständiger Fehler meinerseits, falls das jemand annimmt, sondern jeweilige Eigenschreibweise). Insbesondere durch die nicht aufhörenden Probleme mit dem Lubuntu-Host seit Kernel 4.15 (nur dort, nicht in siduction und antergos, reproduzierbare Freezes unterschiedlicher VMs und das Suchen nach den Ursachen) haben mich das jeweils aktuelle Testbuild installieren lassen, mittlerweile mache ich das standardmäßig (nur nicht, wenn das Release gerade mal neuer ist) und fahre damit sehr gut. Natürlich weiß ich, was das bedeutet und kann damit umgehen.

.

Installation VirtualBox 7.0.14 über .run

  1. Ein ggf. installiertes Extension Pack deinstallieren:
    1
    
    sudo VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
  2. Eine ggf. installierte VBox-deb-Version deinstallieren:
    1
    2
    
    killall -9 virtualbox 
    sudo apt purge virtualbox*
  3. Zum Kompilieren der Kernel-Module nötige Pakete installieren:
    1
    
    sudo apt install build-essential dkms linux-headers-$(uname -r)
  4. VirtualBox*.run ziehen:
    1
    2
    
    cd ~/Downloads/
    wget https://download.virtualbox.org/virtualbox/7.0.14/Oracle_VM_VirtualBox_Extension_Pack-7.0.14.vbox-extpack
  5. Aktuelle VBox-Version installieren:
    1
    
    sudo sh Virt*
  6. Weiter geht es in meinem Tutorial VirtualBox: Repository in Ubuntu hinzufügen mit Punkt 8, “Entsprechende Version des Extension Packs ziehen”.

Soll ein so installiertes VBox wieder deinstalliert werden, sollte zuerst wie oben geschrieben das Extension Pack deinstalliert werden, danach VBox selbst (das EP bliebe anderenfalls erhalten, aber nicht nutzbar):

1
sudo sh Virt* uninstall

.

Update 2024-01-16: Aktualisiert auf v7.0.14.
Update 2023-10-17: Aktualisiert auf v7.0.12.
Update 2023-07-18: Aktualisiert auf v7.0.10.
Update 2023-04-17: Aktualisiert auf v7.0.8.
Update 2023-01-17: Aktualisiert auf v7.0.6.
Update 2022-11-18: Aktualisiert auf v7.0.4.
Update 2022-10-19: Aktualisiert auf v7.0.2.
Update 2022-10-10: Aktualisiert auf v7.0.0, VBox-6.x-Schiene entfernt.
Update 2022-09-29: VBox-7.0-Schiene hinzugefügt.
Update 2022-09-01: Aktualisiert auf v6.1.38.
Update 2022-07-20: Aktualisiert auf v6.1.36.
Update 2022-04-19: Aktualisiert auf v6.1.34.
Update 2022-01-18: Aktualisiert auf v6.1.32.
Update 2021-11-22: Aktualisiert auf v6.1.30.
Update 2021-10-19: Aktualisiert auf v6.1.28.
Update 2021-07-28: Aktualisiert auf v6.1.26.
Update 2021-07-20: Aktualisiert auf v6.1.24.
Update 2021-04-29: Aktualisiert auf v6.1.22.
Update 2021-04-20: Aktualisiert auf v6.1.20.
Update 2021-01-19: Aktualisiert auf v6.1.18.
Update 2020-10-20: Aktualisiert auf v6.1.16.
Update 2020-09-04: Aktualisiert auf v6.1.14.
Update 2020-07-14: Aktualisiert auf v6.1.12.
Update 2020-06-05: Aktualisiert auf v6.1.10.
Update 2020-05-14: Aktualisiert auf v6.1.8.
Update 2020-04-09: Aktualisiert auf v6.1.6.
Update 2020-02-20: Aktualisiert auf v6.1.4.
Update 2020-01-15: Aktualisiert auf v6.1.2.
Update 2019-12-11: Aktualisiert auf v6.1.0.
Update 2019-10-15: Aktualisiert auf v6.0.14.
Update 2019-09-03: Aktualisiert auf v6.0.12.
Update 2019-07-16: Aktualisiert auf v6.0.10.
Update 2019-05-14: Aktualisiert auf v6.0.8.
Update 2019-04-16: Aktualisiert auf v6.0.6.
Update 2019-01-28: Aktualisiert auf v6.0.4.
Update 2019-01-15: Aktualisiert auf v6.0.2.