Ubuntu: snap verhindern

Von Anbeginn bedient sich Linux Mint an Ubuntu (Mint-User faseln seit jeher etwas von “dem besseren Ubuntu”, um zeitgleich in ubuntuusers.de Support zu verlangen, was entsprechende Sympathiewerte…einbringt).

Man könnte sagen, endlich gibt Mint Ubuntu nun etwas zurück, ungewollt und indirekt.

Der Reihe nach. Mint sperrt die Installation von Paketen des unsäglichen Canonical-Eigengewächses snap, indem der Daemon snapd nicht nur nicht vorinstalliert ist, sondern dessen Installation verhindert wird. Diverse Websites wollen nun ausgerechnet diese positive Entscheidung aushebeln, indem sie groß und breit erklären, wie man eine bestimmte Datei löscht. Meine Güte!

So versteigt sich omg!ubuntu in “Nemo as a super user”, um dort das File zu löschen. Ein grafischer Filemanager mit root-Rechten wird dann auch noch als “the good ol’ fashioned way”, die gute altmodische Art, verkauft.

Was steht nun drin und kann man’s nicht erst recht in Ubuntu(-Derivaten) setzen?

Mit einem Editor schreibt man in ein File “/etc/apt/preferences.d/nosnap.pref”:

Package:	snapd
Pin:		release a=*
Pin-Priority:	-10

Mit “sudo apt purge snapd” wird der Daemon gepurget, mit “sudo apt update” aktualisiert man Paketquellen und Paketquelleninhalte.

Sollte man nun snapd wieder installieren wollen, pff, meldet z.B. synaptic unerfüllte Abhängigkeiten, apt erzählt dagegen etwas von “E: Package ‘snapd’ has no installation candidate”.

Über die Nachteile dieses snap-Craps, das wie andere dieser gegenseitig konkurrierenden App-Systeme bestehende Linux-Paket-Management-Systeme konterkariert, muß man sich nicht mehr groß auslassen. In Foren fällt auf, daß unbedarfte User gar nicht merken, ob sie da gerade ein .deb oder so einen Müll, der sich auch nicht sauber ins System integriert, sprich nicht oder nicht vollständig mit anderer Software interagiert, installieren. Fällt bei fehlendem snapd flach.

Das Wesentliche, was dann unter Ubuntu nicht mehr installiert werden kann, weil es schlicht für nach 18.04 nicht mehr in den Repositories liegt (mit fadenscheiniger Begründung seitens Canonicals), ist freilich chromium. Man könnte in den sauren closed-source-Apfel beißen und chrome installieren…oder einfach zu einer vernünftigen Linux-Distribution greifen.

Neo2 unter Xubuntu

Man (also ich, grin) löst bekanntlich gern IT-Probleme anderer. Als Stichwortgeber dazu kann uude sehr vereinzelt noch herhalten (dessen Forum ist ansonsten längst nicht mehr auf absteigendem Ast, sondern schlichtweg im Loch, muß nur noch wer zuschaufeln, das einstmals gute Wiki verödet auch nur noch).

Ein User kann das sehr spezielle Keyboard-Layout Neo2 unter Xubuntu 20.04 nicht laden, weder live noch im installierten System. Bereits für XBionic hat er dazumal einen Bugreport verfaßt gehabt.

Read more “Neo2 unter Xubuntu”

Lubuntu 20.04 Focal Fossa torrent

Der Tradition halber die Kurzinfo: Heute im Laufe des Tages wird Lubuntu 20.04 freigegeben.

Torrent für Lubuntu Focal Fossa:

Die erste “LTS”-Version mit LXQt und nur noch x86_64. Spätestens mit EoS von LBionic in einem Jahr ist Schluß mit LXDE (zumindest als fertiges Image) und x86_32. Für Rechner (hauptsächlich Notebooks und Netbooks) mit x86 ohne 64-bit-Erweiterung (Pentium M bis Core Duo, eine ganze Reihe Atom) dürfte es sich dann quasi bis auf Debian erledigt haben. Letzteres wäre aber auch jetzt schon sinnvoll, lehnt man diesen snap-Unsinn Canonicals ab, insbesondere, wenn man Chromium (was es für Ubuntu und -Derivate eben seit Eoan nur noch als snap gibt) nutzen will. Man muß ja nicht das langsam wieder einstaubende stable nehmen, den sid-Treibsand auch nicht, sondern kann testing installieren.

Wer auf halbwegs zeitgemäßer Hardware permanent aktuell fahren will, nutzt sowieso sinnvollerweise eine Rolling Release Distribution, eine echte, versteht sich.

Update 2020-08-06: Link auf Point Release 1 gesetzt.

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?

Read more “Bodhi Linux…Gruss aus der Gruft”

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.