qt5-Transition

In siduction (der Name sid für debian unstable kommt nicht von ungefähr, der Junge in “Toy Story”, der stets sein Spielzeug kaputtmacht) will ein beiläufiges “apt update; apt full-upgrade” heute Morgen kurz nach 4 über hundert Pakete in den Orkus spülen, mit autoremove dann noch mal das Doppelte. Hängt natürlich davon ab, was man installiert hat (hier LXQt, dazu diverse Qt-basierte Pakete wie krusader oder auch vlc, eigentlich habe ich nur gehofft, daß die brandaktuelle v3.0.5 schon in den Repos liegt).

Es läuft wieder einmal eine qt5-Transition. Da nichts zu irgendwas kompatibel ist, gilt alles oder nichts. Alles gibt’s noch nicht. Wer jedoch davon unabhängige Pakete aktualisieren will oder muß, kann wie folgt mit root-Rechten auf hold setzen:

1
apt-mark hold libqt5core5a

Die Geschichte sollte man freilich nicht vergessen, sprich nach der Transition wieder mit unhold markieren.

2018-12-28: Btw., mittlerweile liegt vlc 3.0.5 (changelog) in den Repositories. ;)

2018-12-29: libqt5core5a kann und sollte wieder auf unhold gesetzt werden.

systemd-240, haengendes Plasma

Derzeit gibt es Probleme mit systemd-240-1 in sid(uction). Sie äußern sich in hängendem Plasma (sprich KDE), aber auch, wenn man dieses DE nicht in Gänze verwendet, sondern nur diverse Qt-Programme mit einem anderen DE (hier LXQt), Krusader bspw. Hier hat es sich so geäußert, daß Krusader an sich zwar augenscheinlich gelaufen ist, man aber darüber ein simples .zip-Archiv nicht hat entpacken können (zuerst nimmt man natürlich an, dieses sei korrupt).

Aber auch Java-Programme wie TV-Browser (ohnehin schon äußerst mädchenhaft bei der Akzeptanz der verwendeten JRE-Version – ich frage mich, wann man dort endlich auf 11 springt oder zumindest akzeptiert) brechen mit einem Wust an Errors ab.

Erster Workaround ist das Zurückgehen auf systemd=239-5.6 plus dessen Abhängigkeiten und das Setzen von “apt-mark hold” dieser Pakete gewesen. Funktioniert, ist jedoch nicht nötig, es genügt das Erzeugen eines .conf-Files

1
echo "* hard nofile 524288" | sudo tee -a /etc/security/limits.d/systemd.conf

mit folgendem Reboot. Hat man sudo nicht installiert, dann logischerweise ohne in einer root-Shell oder tty oder klassisch mit einem Editor.

Update 2018-12-28: Da ja nun systemd-240-2 auf den Mirrors liegt – es soll beschriebene Probleme beheben (systemd.conf könnte man theoretisch wieder entfernen, ich laß es einstweilen).

Ein komplettes d-u ist derzeit durch die qt5-transition nicht möglich, aber man kann systemd auch durch reinstall updaten.

Update 2019-01-05: In antergos, ARCH-basiert, ist es übrigens immer noch systemd 239.370-1, mit 240.0-1 aus testing werden weitere Probleme berichtet (bspw. chromium mit D-Bus-Errors). 240.0-2 gibt es bereits, jedoch noch in testing (und hier installiert).

Die Python ist gefunden

Irgendwas ist anders…

$ sudo sh Virt*
Verifying archive integrity... All good.
Uncompressing VirtualBox for Linux installation.............
VirtualBox Version 5.2.23 r127309 (2018-12-08T13:13:52Z) installer
Installing VirtualBox to /opt/VirtualBox
Python found: python, installing bindings...
 
VirtualBox has been installed successfully.

Python found? Echt jetzt? ;-)

Na klar ist Python installiert, immer schon, in quasi jeder Linux-Distribution, aber diese Routine hat bis jetzt stets was von “Python 2.x not found: python, not installing bindings” erzählt. Bekannte fehlerhafte Ausgabe seit Ewigkeiten, funktioniert hat das trotzdem (Python 2.x und 3.x sind üblicherweise parallel installiert, da es immer noch auf 2.x aufsetzende Programme gibt).

Liegt’s an ewig währenden Transitions in sid(uction) oder gar an einem nicht mehr für möglich gehaltenen Fix in VBox (ungerade Versionsnummern wie 5.2.23 sind Testbuilds)? Oder ist der Fix ein Versehen und bei der nächsten Version dürfen wir die liebgewonnene Ausgabe wieder begrüßen? ;-)

libasound2-Workaround

siduction ist derzeit tonlos, hat man auf libasound2* 1.1.7-1 aktualisiert. Die im Paket libasound2-plugins enthaltenen Softlinks in “/etc/alsa/conf.d” zeigen auf “/usr/share/alsa/alsa.conf.d” (dort liegt im Moment lediglich pulse.conf) und damit ins Leere.

Ein Downdate auf 1.1.6-1+b1 würde es zwar umgehen, ist aber nicht nötig. Es genügt ein simples Umbenennen mit root-Rechten von “/etc/alsa/conf.d” mit anschließendem Reboot.

1
mv /etc/alsa/conf.d{,_bak}

2018-11-04: Das Update auf 1.1.7-2 (changelog) reicht die fehlenden 11 .conf-Files nach. Da die Softlinks neu geschrieben werden, kann obige Umbenennung nun entfernt werden:

1
rm -R /etc/alsa/conf.d_bak

Vulnerability in systemd (CVE-2018-15688)

Bei der aktuellen Vulnerability CVE-2018-15688, systemd betreffend, können sich zumindest sid(uction)-User wieder zurücklehnen, d-u für systemd 239-11 vorausgesetzt. Freilich fahren Server nicht mit sid (und normale Linux-User auch nicht). Also sollte man da Licht ans Rad machen, sowohl seitens der Maintainer in den Distributionen – der Fix ist seit 11 Tagen durch Lennart Poettering bereitgestellt – als auch der Admins (und User, selbstredend).

Btw., “Red Hat would like to thank Ubuntu Security Team for reporting this issue.” (Zitat von access.redhat.com/security/cve/cve-2018-15688). Abgesehen davon, daß das UST nur weitergeleitet hat, Danksagungen durch Canonical an eine andere Distribution sind mir bisher nicht erinnerlich.

Lubuntu mit LXQt

LXQt

siduction hat vor weit über 4 Jahren als erste Distribution einen Flavor mit LXQt angeboten gehabt, damals natürlich noch mit der niedrigen Version 0.7 (wobei unter Linux bzw. bei OSS 0.x-Versionsstände nur aussagen, daß noch nicht sämtliche geplanten Funktionen enthalten sind), aktuell ist 0.13.

Nach Jahren der Versprechungen, bei der nächsten Version wolle man, blabla, und einem “Lubuntu-Next”-Paralleltestlauf steigt man mit dem am Donnerstag erscheinenden Lubuntu 18.10 endlich auf LXQt um.

Read more “Lubuntu mit LXQt”

grub zurueck zu pure ASCII

Das grafische Grub-Menu in siduction widerspricht meinem Schönheitsempfinden. Lieber pure ASCII (bin ich eh ein Fan von).

In einer root-Shell ausführen:

1
2
apt purge patience-grub-theme
update-grub

Vergißt man das Aktualisieren von grub, ist dieser zwar nichtgrafisch, weil schlicht entsprechende Files weg sind, aber es kommt zu einer Fehlermeldung, daß “/usr/share/grub/themes/patience/theme.txt” nicht gefunden wird. Weitergebootet wird nach einigen Sekunden trotzdem.

Danach sollte man sich ansehen, ob man nicht bei einem

1
apt --purge autoremove

zu deinstallierende Pakete doch noch brauchen könnte, bspw. die Icons. In einer siduction-Test-VM würden “breeze-cursor-theme* creativecommons3* patience-lxqt-artwork* patience-sddm-settings* siduction-icons*” gepurged werden. Will man das nicht, setzt man gewünschte(s) Paket(e) zuvor auf manuell installiert, im Beispiel:

1
apt-mark manual siduction-icons*

Liquorix-Kernel

Steven Barrett (erinnert mich irgendwie an TBBT, grin) bewirbt seinen Liquorix-Kernel als the better distro kernel, “gebaut mit der besten Konfiguration (…) für Desktop-Systeme, Multimedia und Gaming” (sinng.).

Ob nun “the best” in jedem Fall tatsächlich das Beste ist, sei dahingestellt (das klingt nach unsäglicher 1-Click-Wartung). Fakt ist, daß Steven Barrett seit vielen Jahren ein sehr hohes Maß an Kontinuität beweist (und das ist äußerst selten). So habe ich Liquorix-Kernel schon unter sidux/aptosid installiert gehabt (aus Interesse, nicht für konkretes). Seit der Einstellung der 32-bit-Unterstützung für siduction (man kann ein solches Image zwar noch installieren oder siduction 32 bit installiert haben, erhält aber keine towo-Kernel-Updates mehr) wird sogar quasioffiziell auf Liquorix-Kernel verwiesen.

Debian-Systeme also. Wenig bekannt ist, daß auch Liquorix-Kernel für Ubuntu (dessen Kernel sind anders paketiert) über ein launchpad.net-PPA bereitgestellt werden. Wer nicht ununterbrochen manuell aktuellere Kernel-Pakete aus den Ubuntu-Repositories klauben, deren automatische Installation einbinden oder aktuelle Mainline-Kernel ziehen will, kann Liquorix-Kernel als Alternative nutzen.

Zur Installation (ob nun unter Debian oder Ubuntu) muß sicherlich nicht viel gesagt werden.

Unter zwei nativen Installationen (i3 und C2D, Systeme, die ich alleinig in der Fa. nutze), zu dem Zeitpunkt noch LArtful/64, mittlerweile LBionic/64, tritt jeweils ein anderer Fehler beim Boot auf. Keiner im Sinne von Stichflamme, sondern von bestimmter Operation fehlgeschlagen (failed), sprich der Boot läuft trotzdem weiter und scheinbar ohne negative Auswirkungen.

Je nach Auftreten sind entsprechende Bootoptionen zu setzen:

  • “kfd: kgd2kfd_probe failed”
    modprobe.blacklist=amdkfd
  • “DMAR: Failed to map DMAR1”
    Hier könnte man zwar

    intremap=off

    setzen, eine bessere Bootoption ist jedoch

    intel_iommu=pt

    DMAR (DMA Read Request) wird damit im Kernel disabled, KVM unterstützt jedoch weiterhin IOMMU und Interrupt Remapping.

Update 2018-09-02: Siehe auch Warnung vor Liquorix-Kernel!