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!

Uebergang auf GCC5

Seit 2 Wochen läuft in debian sid die Transition auf GCC5 und damit natürlich auch in siduction. Dieser Übergang ist kein wirklicher, sondern ein Bruch. Entsprechend bringen seitdem Aktualisierungsversuche enorme Abhängigkeitsprobleme. Als User ganz einfach nichts zu machen, sprich keine Updates fahren (und damit das System potenziellen Sicherheitsrisiken auszusetzen), wie im siduction-Forum wiederholend geraten wird, halte ich für eine schlechte Idee, zumal das noch lange dauern wird, bis sämtliche betroffenen Pakete angefaßt worden sind. Selbstredend auch Augen zu und durch.

Da derzeit testing und sid wenig auseinander liegen, habe ich bis auf weiteres das unstable-Repository durch das von testing ersetzt (alle anderen bleiben). Funktioniert hier in einer VM seit 14 Tagen einwandfrei. Ist zwar nicht mehr ganz so aktuell, aber lauffähig, man bekommt keinen Herzkasper, wenn da x-undneunzig Pakete deinstalliert werden sollen. ;)

Aus siduction mach testuction:

1
2
3
su
sed -i 's!debian/ unstable main!debian/ testing main!g' /etc/apt/sources.list.d/debian.list
apt-get update

Rückgängig Machen sollte klar sein:

1
sed -i 's!debian/ testing main!debian/ unstable main!g' /etc/apt/sources.list.d/debian.list

Welches Unbill dann zu erwarten ist, insbesondere je länger das dauert, kann ich jetzt freilich noch nicht sagen.

kernel-remover in Ubuntu

siduction kernel-remover

Ältere bzw. nicht mehr benötigte Kernels werden unter Ubuntu nicht automatisch deinstalliert (was seine Richtigkeit hat). Ewig und 3 Tage hat es gedauert, bis durch ein “apt-get autoremove” dies (für Linux-Beginners, denen sonst /boot auf separater Partition vollläuft) mit berücksichtigt worden ist, wobei nur “alles oder nichts” möglich ist (selbstverständlich kann man das immer in einem Terminal oder in Synaptic bewerkstelligen).

Andere Distributionen können das besser. In siduction kann man das kleine Tool kernel-remover laufen lassen. Der Aufbau der Kernel-Pakete von debian sid und Ubuntu unterscheidet sich, weshalb es interessant gewesen ist, kernel-remover einfach mal in einer Lubuntu-Trusty-VM auszuprobieren (für derlei hat man sowas ja). Dazu habe ich extra unterschiedliche Kernels wie einen Mainline-Kernel (die ich sonst nicht verwende) und unterschiedliche Dev-Versions aus Wily installiert.

Read more “kernel-remover in Ubuntu”