Category: linux

VBox 6.0.13 laeuft mit Kernel 5.3 im Host

axt

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.

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 arch-based und mit 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

axt

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

axt

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

axt

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.

usrmerge, nachtraeglich

axt

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.

Firefox: Add-ons deaktiviert

axt

Es ist mal wieder ein Weltuntergang. Jedenfalls, schenkt man manchen Usern Glauben, die da behaupten, ohne Add-ons sei Firefox nicht zu gebrauchen, also denen, die Fx mit ach so wichtigen Add-ons zukleistern. Seit heute Nacht werden in Fx automatisch Add-ons deaktiviert, weil bei mozilla.org Verantwortliche den Ablauf des entsprechenden Zertifikats verpennt haben.

Interessanterweise werden nicht sämtliche disabled, bspw. NoScript – das ist ein unverzichtbares Add-on – läuft weiter. Wer also nicht sonstige installiert und aktiviert hat, merkt davon nichts. Installieren, auch manuell, wird freilich mit dem falschen Hinweis abgelehnt, das .xpi sei corrupt (auch NoScript).

Der Vorgang zeigt aber nicht nur die Verschlafenheit bzgl. Zertifikaten, sondern vor allem die Unfähigkeit und den Unwillen von Usern zur Recherche. Seit ~3:00 (!) gibt es einen Bugreport auf bugzilla.mozilla.org und seitdem bis jetzt, Nachmittag, 41 (!) Duplicates, also weitere (nunmehr geschlossene) Bugreports desselben Problems.

Bei mozilla.org hat man sich ob der Zahl fortwährender Postings leicht genervt gezeigt (discourse.mozilla.org ist offensichtlich seit Stunden permanent überlastet), aber zumindest gg. Mittag eine Interimlösung mit einem Zwischenzertifikat bereitgestellt.

Zum Zeitpunkt des Schreibens dieses Postings ist Fx 66.0.4 Candidate Build 1 angeboten, dann aber wieder entfernt worden, freilich ohnehin bloß für Redmond OS. Mittlerweile ist Directory Listing für download-installer.cdn.mozilla.net/pub/firefox/candidates/ disabled.

Solange hotfix-update-xpi-intermediate@mozilla.com-1.0.2-signed.xpi ziehbar ist (manuell in Fx zu installieren, allerdings nicht in den ESR-Versionen), ist das jedoch völlig ausreichend. Auch nur ein .xpi-File, das funktioniert aber. Und danach auch wieder installierte Add-ons sowie das Installieren von Add-ons.

Update 2019-05-05, 19:30: Mozilla hat Fx 66.0.4 mit einem Fix bereitgestellt (bei Erststart wird automatisch der eventuell zuvor im User-Profil unter extensions abgelegte intermediate-Fix gelöscht). Gefixte 60er ESR- und 67.0b-Versionen fehlen allerdings noch.

Update 2019-05-05, 21:00: Mittlerweile liegt auch 60.6.2esr vor.

VirtualBox: certificate verification failed

axt

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

axt

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

axt

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

axt

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.