Category: linux

Lubuntu 20.04 Focal Fossa torrent

axt

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 2021-08-26: Link auf Point Release 3 gesetzt.
Update 2021-02-04: Link auf Point Release 2 gesetzt.
Update 2020-08-06: Link auf Point Release 1 gesetzt.

Bodhi Linux…Gruss aus der Gruft

axt

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

axt

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.

arch: initramfs-linux-fallback.img, errors during the build

axt

Mit in arch aktiviertem testing wird derzeit mittels mkinitcpio initramfs-linux-fallback.img mit einer error-Msg gebaut:

~$ sudo mkinitcpio -p linux
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.5.5-arch1-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 5.5.5-arch1-1
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: wd719x
==> WARNING: Possibly missing firmware for module: aic94xx
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
  -> Running build hook: [fsck]
cp: cannot stat '(builtin)': No such file or directory
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
~$

Warning, daß errors… ;) Wie man sieht, tatsächlich nur für fallback, nicht normal. Das Gleiche ergibt sich, wenn man für einen etwaigen Notfall linux-lts-image (das wäre 5.4, so weit sind andere Distributionen noch nicht mal) installiert hat. An der Kernel-Version liegt es also nicht.

Postings über die Jahre mit dieser Ausgabe sind durchwachsen. Einer meint, er habe den Komprimierer in “/etc/mkinitcpio.conf” geändert. Gut, kann man ja mal probieren – vielleicht gibt’s mit default gzip ja ein Problem – so am halboffenen Herzen, grin. Interessant ist’s allemal (xz dürfte die beste Komprimierungsrate haben, dafür dauert dann mkinitcpio deutlich länger, man braucht auch gar nicht komprimieren, wenn man cat setzt), löst aber das Problem nicht.

In anderen Threads wird von nvidia oder VBox gesprochen. Hier nix nvidia, sondern nouveau. VBox ist freilich vor zwei Tagen in v6.1.4 erschienen (wie üblich habe ich sämtliche 6.1.3er Testbuilds installiert gehabt, ohne Trara). Schrittweise Testdeinstallation von virtualbox-host-modules-arch, des ExtensionPacks und VBox’ selbst…außer Spesen nix gewesen.

Um es nun ;) kurz zu machen, ursächlich ist kmod 27-1. Mit 26-3 läuft mkinitcpio sauber durch.

  1. Installation von kmod-26-3-x86_64.pkg.tar.xz aus dem PackageCache: 
    1

    sudo pacman -U /var/cache/pacman/pkg/kmod-26-3-x86_64.pkg.tar.xz
  2. kmod in “/etc/pacman.conf” mit “IgnorePkg = kmod” auf hold setzen.
  3. initramfs*.img neu bauen: 
    1

    sudo mkinitcpio -p linux

Wenn man sowas macht, muß man

  • auf Abhängigkeiten achten (andere Pakete, die ggf. mit gedowngradet werden müssen),
  • diese Änderung im Hinterkopf behalten, denn die stellt selbstverständlich keine Dauerlösung dar, sprich nach Bugfixing ist wieder der Paketeintrag von IgnorePkg zu nehmen.

Hat man den Paketzwischenspeicher bereits geleert gehabt, kann man sich kmod über archlinux.org/packages ziehen (solange es da in 26-3 noch liegt, grin).

Btw., es gibt zwar ein Helferlein namens downgrade, Installationen aus AUR sollte man allerdings auf persönlich wirklich unverzichtbares minimieren. Und so selten, wie derartiges in arch trotz Rolling Release Distribution und aktiviertem testing vorkommt…das ist QA!

Update: Ein zwischenzeitlich erfolgtes Update von mkinitcpio fixt obiges Problem. Ergo in “/etc/pacman.conf” die “IgnorePkg”-Zeile wieder mit “#” auskommentieren und mit pacman aktualisieren.

VBox: stuttering in yt

axt

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.

sid-based: Druckerkonfiguration haengt

axt

In die Druckerkonfiguration system-config-printer geht man eher selten, wenn gewünschte Drucker konfiguriert sind und es nichts zu ändern gibt. Daher fällt dort ein Problem durchaus auch länger nicht auf (nur so kann ich es mir erklären, für das Fehlerbild noch keinen Bugreport für sid gefunden zu haben, nur einen 5 Jahre alten für Red Hat mit Patch). Hier tritt es schon länger auf, üblicherweise gehe ich sowas sofort nach, aber diese Distribution will ich eigentlich schon lange ersetzen.

Fehlerbild: system-config-printer läßt sich starten, über Kontextmenu Properties/Settings/Make and Model/Change öffnen sich automatisch noch die Fenster “Choose Driver” und “Searching”, letzteres, leer, schließt sich aber nicht, man muß system-config-printer abschießen.

Für unstable und testing ist derzeit 1.5.12-1 aktuell, in buster 1.5.11-4. Vorweg, diese Version zeigt das Problem nicht (und glücklicherweise ist es system-config-printer und nicht etwas anderes, was nicht zusammenspielt), also installieren wir sie, sprich system-config-printer in Version 1.5.11-4 mit dessen Abhängigkeiten.

Ein

1

sudo apt install -t=buster system-config-printer=1.5.11-4

läuft hier nicht, da buster ja nicht in sources.list.d steht (und nein, das fügen wir nicht hinzu). Aber wir können die Pakete manuell ziehen (ich habe natürlich noch sha256sum laufen lassen und verglichen):

  1. Erstellen des Download-Directorys und Wechseln dorthin:

    1
2

    mdir -p ~/Downloads/system-config-printer_buster/
cd ~/Downloads/system-config-printer_buster/
  2. Ziehen der Pakete:

    1
2
3
4

    wget http://ftp.debian.org/debian/pool/main/s/system-config-printer/system-config-printer_1.5.11-4_all.deb
wget http://ftp.debian.org/debian/pool/main/s/system-config-printer/system-config-printer-common_1.5.11-4_all.deb
wget http://ftp.debian.org/debian/pool/main/s/system-config-printer/python3-cupshelpers_1.5.11-4_all.deb
wget http://ftp.debian.org/debian/pool/main/s/system-config-printer/system-config-printer-udev_1.5.11-4_amd64.deb
  3. Installation der Pakete:

    1

    sudo dpkg -i *
  4. Hold setzen:

    1

    sudo apt-mark hold system-config-printer

Selbstverständlich sollte man nun selbst ein Auge auf ein fixendes Update haben. Ist eines erschienen, setzt man auf unhold und aktualisiert:

1
2

sudo apt-mark unhold system-config-printer
sudo apt update; sudo apt full-upgrade

VirtualBox: libvpx5, libvpx6

axt

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.

Transitions

axt

Wer Distributionen wie siduction oder einfach nur sid fährt (das sind keine normalen Rollings Release Distributions wie Arch basierte, sondern sid ist debian unstable, Dev-Version, siduction nicht viel mehr), sollte wissen, was Transitions bedeuten, und beim Anstoßen von Updates genau hinsehen. Wenn da bei einem

1

sudo apt update; sudo apt full-upgrade

locker ein paar hundert Pakete als “to remove” angezeigt werden – und das fällt schon optisch auf – gerät man nicht in Panik (“Y” ist großgeschrieben und ein Return wäre fatal) und bricht selbstverständlich mit “n” ab. Gibt es in einem Forum dafür jeweils “upgrade warnings”, ist das zwar nett, aber nicht unbedingt nötig (wobei da manche unverständlicherweise trotzdem immer wieder aus allen Wolken fallen, weswegen ich das Thema erneut aufgreife).

Solche Transitions können auch länger dauern, perl zuletzt ~2 Wochen. Und kaum ist das gegessen, geht’s aktuell mit qt5 (auf Qt 5.12) weiter.

Abbruch bedeutet freilich gar keine Updates, sprich auch keine anderen. Man kann bestimmte Pakete auf hold setzen, abhängende Pakete (die es ja eben vielfach in neuer Version noch nicht gibt) werden so ebenfalls nicht mit aktualisiert bzw. wird nicht einfach alles ‘runtergeworfen, weil unvollständig. Bspw. bei der perl-Transition ist es nur das Paket perl gewesen:

1

sudo apt-mark hold perl

Bei der letzten qt5-Transition hat (hier) das Paket libqt5core5a genügt. Diesmal nicht ganz, ich habe noch qtbase5-dev dazunehmen müssen:

1

sudo apt-mark hold qtbase5-dev libqt5core5a

So kann man relativ gefahrlos upgraden (sofern man das bei siduction überhaupt sagen kann). Ist komplett umgestellt, setzt man die Pakete wieder auf unhold

1

sudo apt-mark unhold qtbase5-dev libqt5core5a

und aktualisiert. Das ist dann ein kleiner Nervenkitzel. ;)

Btw., auch wenn mal nur 1…2 Pakete deinstalliert werden sollen, überprüft man das. Meist werden sie durch neuere, die im Paketnamen tatsächlich eine höhere Zahl beinhalten, ersetzt.

Lubuntu 19.10 Eoan Ermine torrent

axt

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

axt

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.