Category: arch_based

LXQt: Shortcuts ohne Funktion

axt

Wenn Tastenkombinationen keine Reaktion mehr zeigen, merkt man erstmal, wie sehr man selbst darauf baut. LXQt-Shortcuts funktionieren nicht mehr (wenn nicht mal über ctrl+alt+t ein Terminal gestartet werden kann, was ich hier ständig mache, ist das schon hart, hrr).

Sobald der Desktop aufgebaut ist, erscheint folgende Message:

lxqt-panel
Removable media/devices manager: Global shortcut 'X86Eject' cannot be registered

Ich untersuche das Problem seit Freitag (da ist es erstmals aufgetreten, testing ist in einer hier installierten arch-basierten Distribution prinzipiell aktiviert). Es ist irrelevant, welcher Window Manager genutzt wird (openbox, xfwm4). Zwischenzeitlich habe ich schon angenommen gehabt, ich hätte die Ursache gefunden bzw. zumindest einen Workaround.

lxqt-globalkeysd kann nicht gestartet werden. Dies kann man sehen unter:

LXQt Configuration Center → Session Settings → Basic Settings → Global Keyboard Shortcuts

An der Stelle kann man den Dienst starten, freilich überlebt dieser keinen Reboot oder Relogin.

Unter

LXQt Configuration Center → Autostart → Application Autostart → LXQt Autostart

habe ich “lxqt-globalkeysd” mit “Wait for system tray” als Workaround hinzugefügt. Hilft allerdings nicht zuverlässig. Im Moment funktioniert’s, was nicht daran liegen muß.

Zum Thema kann man fast nichts finden. Vor 5 Jahren ist das Fehlerbild schon mal aufgetreten (nicht bei mir, ich habe damals LXDE genutzt). Damals soll geholfen haben:

PCmanFM → Preferences → Volume → disable “Mount removable media automatically whe they are inserted” und disable “Show available options for removable media when they inserted”

Ist hier aber auch nicht einwandfrei reproduzierbar.

arch/LXQt: Gruppierte Fenster im Panel nicht waehlbar

axt

Laufen mehrere Instanzen eines Programmes, werden deren Fenster in einem Panel gruppiert. Das bedeutet, in bspw. LXQt-Panel erscheint nur 1 Tab für eine Programmgruppe, geht man darauf, klappt das Panel vertikal bzw. horizontal (je nach Anordnung des Panels) auf, man kann das gewünschte Fenster anklicken.

Man spart damit also massiv Platz. Hat man z.B. Thunderbird geöffnet, will eine eMail schreiben, sind das schon mal 2 Fenster, im Tb-Tab gruppiert. Benötigt man für die eMail Informationen aus dem ebenfalls geöffneten Filemanager oder Browser, wechselt man dorthin und wieder zurück.

Seit Mitte der Woche sind gruppierte Fenster aber nicht mehr klickbar. Der jeweilige Tab öffnet sich zwar (es fällt schon auf, daß man dazu überhaupt klicken muß, denn eigentlich ist es ein Mouseover), man sieht die einzelnen Einträge, beim Klick darauf schließt sich aber sofort die Auswahl.

Mit ctrl+tab kann man zwar die Fenster weiterhin wechseln, sind jedoch viele geöffnet, braucht das länger.

Eine Falschkonfiguration in z.B. panel.conf ist es nicht, ich nehm’s vorweg, nicht das Panel selbst ist die Ursache.

Ich habe diverse Bugtracker als RSS-Feeds aboniert. In dem von arch findet sich tatsächlich FS#70386 – LXQt panel doesn’t allow to select any grouped window von gestern Nachmittag. Offensichtlich sind kürzliche Änderungen in bestimmten qt5-Paketen in arch ursächlich.

Als Workaround kann man die jeweils letzte Version ohne den Namenszusatz “kde” installieren. Hat man diese noch in “/var/cache/pacman/pkg/” liegen, kopiert man diese einfacherweise in ein leeres Verzeichnis, um von dort mit “pacman -U *” zu installieren. Wer sein System sauber hält, hat die freilich nicht mehr und zieht sie sich von archive.archlinux.org:

1
2
3
4
5
6
7

mkdir -p ~/Downloads/arch/oldver/qt5/
cd ~/Downloads/arch/oldver/qt5/
wget https://archive.archlinux.org/packages/q/qt5-base/qt5-base-5.15.2-5-x86_64.pkg.tar.zst
wget https://archive.archlinux.org/packages/q/qt5-declarative/qt5-declarative-5.15.2-1-x86_64.pkg.tar.zst
wget https://archive.archlinux.org/packages/q/qt5-svg/qt5-svg-5.15.2-2-x86_64.pkg.tar.zst
wget https://archive.archlinux.org/packages/q/qt5-wayland/qt5-wayland-5.15.2-1-x86_64.pkg.tar.zst
yay -U *

Es erfolgt eine Warnung, daß gedowngradet werden soll.

Um im nächsten Update-Prozeß diese 4 Pakete nicht gleich wieder zu ersetzen, muß man sie natürlich pinnen. In “/etc/pacman.conf” erweitert man die entsprechende Zeile auf “IgnorePkg = qt5-base qt5-declarative qt5-svg qt5-wayland”.

Vergessen kann man das Ganze nicht, denn z.B. “yay -Syyu” zeigt “ignoring package upgrade” an. Sind dann gefixte Pakete verfügbar, kommentiert man die IgnorePkg-Zeile aus oder entfernt die Paketnamen.

·

Update: Revert the revert, the affected applications have been fixed ;-)

Wenn qt5-base-5.15.2+kde+r171-3 in Abhängigkeit der Aktualität des jeweiligen Mirrors angeboten wird, kann und sollte das Pinning wieder aufgehoben werden.

Blaulichtfilter, Software-Loesung mit redshift

axt

Blau macht glücklich, Blau bedeutet Hoffnung. Aber wo viel Licht, da viel Schatten. ;-) Man soll nachts nach stundenlanger Arbeit am Rechner weniger gut einschlafen können, man sei noch auf Tagmodus, und das, obwohl die Augen schneller ermüden. Wobei das natürlich auch eine Frage des sehr viel höheren Kontrasts gegenüber meist abgedunkeltem Raum ist.

Sei’s drum, jedenfalls gibt es neuere Monitore mit Blaulichtfilter (manchmal als smartLight vermarktet), auch manche Smartphone-Displays besitzen derartiges, mehr oder eher weniger brauchbar (dort, wo ich es ausprobiert habe, würde ich es ausschalten). Das bedeutet nicht, es kommt kein Blau mehr durch, man sieht nur noch Rot. =:-)

Wer keinen solchen Monitor besitzt, wird nicht über OSD ständig die Farbtemperatur (wer vor heutiger Allerweltsknipserei mit Grundlagenwissen fotografiert hat, kennt das mit Tageslichtfilm und Kunstlichtfilm, aber selbst bei s/w mit Vorsatzfiltern) ändern wollen, es gibt Software-Lösungen wie redshift (das ist kein neues Programm, aber manche scheinen Schwierigkeiten mit der Einrichtung zu haben). In Abhängigkeit des Standorts und der Uhrzeit wird eben jene Farbtemperatur über den XServer mit xrandr angepaßt.

Die Installation ist simpel:
arch-basiert:

1

# pacman -S redshift redshift-gtk

debian-basiert:

1

# apt install redshift redshift-gtk

Es ist auch ohne das grafische Frontend möglich. Zur Bestimmung des Standorts kann man geoclue installieren, nur dafür ist es aber keineswegs nötig. Sinnvollerweise erstellt man einfach eine Konfigurationsdatei ” ~/.config/redshift.conf” mit entsprechendem Inhalt. Auf der Site des Projekts kann man ein Muster ziehen und an die eigenen Verhältnisse anpassen. Das Ganze ist wirklich sehr einfach, gut dokumentiert (ich entferne im folgenden File diese Zeilen auch nicht, füge im Gegenteil hilfreich sein könnende Sites ein).

Die eigenen Koordinaten, also den Breiten- und Längengrad, kann man bspw. über dateandtime.info erfahren. Für Leipzig sind dies Breitengrad 51°20.3772′ N, Längengrad 12°22.2774′ O. Einzutragen sind

lat=51.20
lon=12.22

Die zu wechselnde Farbtemperatur in Kelvin kann man sacht wählen

temp-day=6500
temp-night=6200

oder stärker, so man dies will.

Sinnvoll ist der Eintrag

transition=1

für einen fließenden Übergang.

Soll nur ein bestimmter Screen betroffen sein, ist dieser anzugeben, anderenfalls kann man die Zeile auch mit einem Semikolon auskommentieren.

Speichern, redshift-gtk starten! Das ist über Icon im Startmenu möglich, aber natürlich auch in einem Terminal, z.B. zum Testen. Über das Glühlampen-Icon kann man redshift auch schnell zu oder abschalten und auch in den Autostart eintragen.

Kleiner Hinweis noch, in einer VM funktioniert das nicht (das Programm als solches schon), das müßte man im Host durchführen.

Nachfolgend eine “~/.config/redshift.conf”:

Read more “Blaulichtfilter, Software-Loesung mit redshift”

CUPS: Drucker nicht mehr angezeigt

axt

Wenn seit etwa einer Woche (in Abhängigkeit, welche Distribution installiert ist, ob man in arch testing aktiviert und wann geupdatet hat) keine Drucker mehr als installiert angezeigt werden, fängt man nicht unlogisch an, die neu installieren zu wollen, auch cups nicht.

Mit CUPS als solchem liegt man jedoch nicht falsch, man checkt, ob der Service läuft:

1
2
3
4
5
6

$ systemctl status cups
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; disabled; vendor preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● cups.socket
       Docs: man:cupsd(8)

Also nicht, richtig vermutet. Kann man den Daemon mit

1

# systemctl start cups

starten, sprich funktioniert das Drucken wieder (aber nur für diese eine Session), weiß man schon mal, alles ist richtig installiert. Bis auf die Kleinigkeit, daß eben der Daemon nicht automatisch gestartet wird. Sieht man selbstverständlich bei Updates hin, sollte aufgefallen sein, daß sich kürzlich bzgl. cups etwas geändert hat. Man prüft in den Changes. Ab Zeile 190 “# rename the systems service files” wird man bestätigt, daß 5 Files “org.cups.cups*.*” in “/usr/lib/systemd/system/” umbenannt worden sind. Nun sollte man wissen, daß auf diese über Softlinks zugegriffen wird. Die zeigen aber auf nicht mehr existente Files.

Man sollte den Daemon nochmal stoppen, auch, um hernach gleich zu sehen, ob’s funktioniert hat:

1

# systemctl stop cups

Da man sauber arbeitet, löscht man zuerst die toten Links:

1

# systemctl disable org.cups.cupsd

Nun legt man die neuen Softlinks an:

1

# systemctl enable --now cups

Mit der Option “now” wird erreicht, daß das Gewünschte sofort aktiv ist, kein Reboot oder extra Start nötig.

Status-Check:

1
2
3
4
5
6
7
8
9
10

$ systemctl status cups
● cups.service - CUPS Scheduler
     Loaded: loaded (/usr/lib/systemd/system/cups.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2020-11-23 18:10:42 CET; 31s ago
TriggeredBy: ● cups.path
             ● cups.socket
       Docs: man:cupsd(8)
   Main PID: 859 (cupsd)
     Status: "Scheduler is running..."
(...)

Done.

arch: “-bash: append_path: command not found”

axt

Über ssh auf ein arch-basiertes System eingeloggt bringt folgende Ausgabe, ggf. auch mehrfach untereinander:

-bash: append_path: command not found

Check auf profile* in /etc:

/etc$ ls -la profile*
-rw-r--r-- 1 root root  811 Aug  6  2018 profile
-rw-r--r-- 1 root root 1020 Sep  3 00:30 profile.pacnew
 
profile.d:
(...)

Bei einer Aktualisierung ist ein neues profile geschrieben, aber sicherheitshalber unter verändertem Filename gespeichert worden. Dies sollte man vergleichen. Entscheidet man sich für die neue Konfiguration, ist profile zu löschen (oder meinetwegen zu sichern) und dann profile.pacnew in profile umzubenennen:

/etc$ sudo mv profile{,_old}
/etc$ sudo mv profile.pacnew profile

arch: qbittorrent startet nicht

axt

Wer arch/testing aktiviert hat, kann derzeit qbittorrent nicht nutzen. Wenn scheinbar nichts passiert, ruft man ein Programm in einem Terminal auf und erhält in diesem Fall folgendes:

$ qbittorrent 
qbittorrent: symbol lookup error: qbittorrent: undefined symbol: (...)

Über einen Bugreport kommt man zum Hintergrund und findet auch eine Diskussion dazu. Bis die eigentliche Ursache behoben ist, kann man sich mit einem Workaround behelfen: man installiert die derzeitige Version aus stable (oder man nutzt transmission).

$ sudo pacman -S "libtorrent-rasterbar=1:1.2.8-1"
[sudo] password for axt: 
warning: downgrading package libtorrent-rasterbar (1:1.2.10-1 => 1:1.2.8-1)
(...)

Damit die nächste Aktualisierung das nicht gleich wieder zunichte macht, muß man das Paket auf hold setzen:

$ sudo nano /etc/pacman.conf

Hier fügt man “libtorrent-rasterbar” hinzu:

IgnorePkg   = libtorrent-rasterbar

Probe auf’s Exempel:

$ sudo pacman -Syyu
(...)
:: Starting full system upgrade...
warning: libtorrent-rasterbar: ignoring package upgrade (1:1.2.8-1 => 1:1.2.10-1)
 there is nothing to do

Vergessen kann man’s so nicht. Man sollte die Sache natürlich im Auge behalten, d.h., bei einem Fix das Paket wieder auf unhold setzen.

Update 2020-09-23: “1:1.2.10-2” enthält einen Fix, funktioniert → libtorrent-rasterbar wieder aus IgnorePkg entfernen!

Neo2 unter Xubuntu

axt

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”

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.