Category: sid_based

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

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.

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.

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.

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.

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.

https-Fix fuer apt

axt

Das Sicherheitsproblem CVE-2019-3462 in apt (“Content injection in APT http method when using redirects”) ist gefixt worden – in debian (debian security tracker) und Ubuntu (Ubuntu CVE Tracker) und somit auch deren Derivaten (sofern diese nicht irgendwas zurückhalten, ich sage nur Mint). So weit, so gut.

apt ist nun nicht irgendwas, sondern das Package Management Tool debian-basierter Distributionen. Das checkt Repositories und deren Inhalte und installiert daraus Pakete, also auch bei jedem Update. Welche Server und Repositories, steht in “/etc/sources.list” und/oder “/etc/sources.list.d/*.list”. Also sollte man überprüfen, ob da nicht über http statt https angefahren wird.

Jetzt kann man aber nicht blauäugig überall ein “s” für secure dazumalen, denn der Stand der Mirrors dazu ist aus einem Land vor unserer Zeit.

So gibt es https für archive.ubuntu.com, immerhin der Mainserver (!), bis heute nicht, nicht mal – und das ist der Hit – für security.ubuntu.com (für packages.ubuntu.com schon, das ist aber nur eine Search Engine, die dann eben auf die Mirrors linkt). Bei den offiziellen (Load balancing) Mirrors sieht es kaum besser aus. Das ist noch nett ausgedrückt. Der südafrikanische Mirror (einziger für Afrika), hat kein https, sämtliche 13 asiatischen sind nicht sicher, von den 12 amerikanischen ist es wenigstens die Hälfte. Und das tolle Europa? Von den 13 Mirrors weiß 1 (in Worten einer) etwas von https, der französische. Also nichts mit ach so sicherheitsbewußtem Deutschland (beim Server der TU Dresden ist man schon froh, wenn der überhaupt funktioniert, weshalb seit Ewigkeiten in uude davon abgeraten wird).

In siduction sollte man auch mal “/etc/apt/sources.list.d/*.list” überprüfen. Die Listen des letzten offiziellen Releases vom Mai sind dahingehend nicht aktuell. So kennt ftp.uni-stuttgart.de nach wie vor nur http (und ftp…), ftp.spline.de (FU Berlin) jedoch auch https. Man sollte also bspw. dahin wechseln.

Nachtrag: Wie wichtig der apt-Fix ist, zeigt das Release von debian 9.7, das in dem vergleichsweise dazu riesigen Image als einzige Änderung das Fitzelchen gefixten Code enthält (Paket base-files).

Der letzte Absatz im pro-linux-Artikel mit dem “problemlos weiternutzen” ist allerdings nicht weit gedacht. Welches Tool hat denn das Update von apt installiert? Dann hätte man schon AllowRedirect=false setzen müssen, wie von devil aufgeführt. Oder manuell von einem offiziellen Server über https ziehen, sha256-checken und mit dpkg installieren.

VirtualBox: Installation ueber .run

axt

Altägyptisch oder bleeding edge. Aktuelles Beispiel: In siduction wird anders als in sid Kernel 4.20 installiert (towo ist da glücklicherweise agil). Wer VirtualBox aus den debian-Repositories nutzt, bekommt bislang nur 5.2.22, das jedoch inkompatibel zu Kernel 4.20 ist.

VBox 6.0.0 ist kompatibel zu Kernel 4.20. Man kann zwar das VBox-Repo einbinden, daraus aber nur für debian stable und oldstable installieren, was im Normalfall unter sid(uction) wegen Dependencies fehlschlägt. Für Ubuntu gebaute Pakete in debian installieren ist auch nicht die gescheiteste Idee (auch wenn die für Bionic momentan laufen sollen).

Dann sollte man so flexibel sein und die .run-Files nutzen, statt wie ein User im siduction-Forum zu jammern, er wolle nur installieren, was “über apt oder dpkg” geht, und deshalb bei der letzten 4.19 bleiben (von der Paketverwaltung abgesehen, was er meint und womit er natürlich Recht hat, erntet er meinerseits dennoch Unverständnis, man fährt doch keine bleeding-edge-RRD, um ausgerechnet beim Kernel stehenzubleiben bzw. zurückzugehen). Fremdpakete aus Sicht der Distribution sind es so und so, aber in diesem Fall bzw. aus Sicht VBox’ sind sie das Original.

Das Ganze ist auch nicht schwieriger, mehr noch, man kann das so unter diversen Distributionen durchführen, bspw. unter siduction und antergos die jeweils selben .run-Files (braucht sie also auch nur 1x ziehen) und bis auf sudo vs. root-Terminal gleich. Zudem kann man Testbuilds nutzen, die ihrerseits ggf. Fixes ggü. dem letzten Release enthalten. Der einzige Nachteil ist lediglich, daß man sich selbst um neue Versionen kümmern muß (und das Interesse für derlei setze ich bei Usern, die bewußt brandaktuelle Distributionen fahren, voraus).

Ich selbst nutze seit längerem VirtualBox*.run unter (bis vor einiger Zeit noch Lubuntu,) siduction, antergos (die gemischte Groß-/Kleinschreibung für solche Namen ist übrigens kein ständiger Fehler meinerseits, falls das jemand annimmt, sondern jeweilige Eigenschreibweise). Insbesondere durch die nicht aufhörenden Probleme mit dem Lubuntu-Host seit Kernel 4.15 (nur dort, nicht in siduction und antergos, reproduzierbare Freezes unterschiedlicher VMs und das Suchen nach den Ursachen) haben mich das jeweils aktuelle Testbuild installieren lassen, mittlerweile mache ich das standardmäßig (nur nicht, wenn das Release gerade mal neuer ist) und fahre damit sehr gut. Natürlich weiß ich, was das bedeutet und kann damit umgehen.

.

Installation VirtualBox 7.0.16 über .run

  1. Ein ggf. installiertes Extension Pack deinstallieren: 
    1

    sudo VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack"
  2. Eine ggf. installierte VBox-deb-Version deinstallieren: 
    1
2

    killall -9 virtualbox 
sudo apt purge virtualbox*
  3. Zum Kompilieren der Kernel-Module nötige Pakete installieren: 
    1

    sudo apt install build-essential dkms linux-headers-$(uname -r)
  4. VirtualBox*.run ziehen: 
    1
2

    cd ~/Downloads/
wget https://download.virtualbox.org/virtualbox/7.0.16/Oracle_VM_VirtualBox_Extension_Pack-7.0.16.vbox-extpack
  5. Aktuelle VBox-Version installieren: 
    1

    sudo sh Virt*
  6. Weiter geht es in meinem Tutorial VirtualBox: Repository in Ubuntu hinzufügen mit Punkt 8, “Entsprechende Version des Extension Packs ziehen”.

Soll ein so installiertes VBox wieder deinstalliert werden, sollte zuerst wie oben geschrieben das Extension Pack deinstalliert werden, danach VBox selbst (das EP bliebe anderenfalls erhalten, aber nicht nutzbar):

1

sudo sh Virt* uninstall

.

Update 2024-04-16: Aktualisiert auf v7.0.16.
Update 2024-01-16: Aktualisiert auf v7.0.14.
Update 2023-10-17: Aktualisiert auf v7.0.12.
Update 2023-07-18: Aktualisiert auf v7.0.10.
Update 2023-04-17: Aktualisiert auf v7.0.8.
Update 2023-01-17: Aktualisiert auf v7.0.6.
Update 2022-11-18: Aktualisiert auf v7.0.4.
Update 2022-10-19: Aktualisiert auf v7.0.2.
Update 2022-10-10: Aktualisiert auf v7.0.0, VBox-6.x-Schiene entfernt.
Update 2022-09-29: VBox-7.0-Schiene hinzugefügt.
Update 2022-09-01: Aktualisiert auf v6.1.38.
Update 2022-07-20: Aktualisiert auf v6.1.36.
Update 2022-04-19: Aktualisiert auf v6.1.34.
Update 2022-01-18: Aktualisiert auf v6.1.32.
Update 2021-11-22: Aktualisiert auf v6.1.30.
Update 2021-10-19: Aktualisiert auf v6.1.28.
Update 2021-07-28: Aktualisiert auf v6.1.26.
Update 2021-07-20: Aktualisiert auf v6.1.24.
Update 2021-04-29: Aktualisiert auf v6.1.22.
Update 2021-04-20: Aktualisiert auf v6.1.20.
Update 2021-01-19: Aktualisiert auf v6.1.18.
Update 2020-10-20: Aktualisiert auf v6.1.16.
Update 2020-09-04: Aktualisiert auf v6.1.14.
Update 2020-07-14: Aktualisiert auf v6.1.12.
Update 2020-06-05: Aktualisiert auf v6.1.10.
Update 2020-05-14: Aktualisiert auf v6.1.8.
Update 2020-04-09: Aktualisiert auf v6.1.6.
Update 2020-02-20: Aktualisiert auf v6.1.4.
Update 2020-01-15: Aktualisiert auf v6.1.2.
Update 2019-12-11: Aktualisiert auf v6.1.0.
Update 2019-10-15: Aktualisiert auf v6.0.14.
Update 2019-09-03: Aktualisiert auf v6.0.12.
Update 2019-07-16: Aktualisiert auf v6.0.10.
Update 2019-05-14: Aktualisiert auf v6.0.8.
Update 2019-04-16: Aktualisiert auf v6.0.6.
Update 2019-01-28: Aktualisiert auf v6.0.4.
Update 2019-01-15: Aktualisiert auf v6.0.2.

qt5-Transition

axt

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

axt

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).