Category: arch_based

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.

endeavouros release

axt

Nachdem der monatliche Build endeavouros 2019-11-19 zurückgezogen worden ist (natürlich 5 min nachdem ich die 1.6 GiB gezogen gehabt habe, 8-)), kurz genannte Probleme habe ich freilich nicht verifizieren können und hätte das Image durchaus verwendet, ist gestern Nachmittag der Snapshot 2019-12-03 als Final veröffentlicht worden.

VBox-(upstream-)Probleme (VMSVGA, vboxsf) bestehen fort, sind jedoch nicht dringlich, da umgehbar.

Project Leader Bryan Poerwoatmodjo (Bryanpwo) schreibt zwar, “this interim release is just to address the Kalu problem”, aber es ist weit mehr als nur das einfach zu deinstallierende kalu (dessen Abhängigkeiten beißen sich mit denen von pacman, verhindern daher Aktualisierungen, und wird zudem nicht weiterentwickelt), werden doch Grundkomponenten Kernel, Mesa, Systemd und weiteres aktualisiert.

Wer neu installiert, will ja nicht gerade das Oktober-Image oder gar das August-Image (der Vorschlag ist gestern in einem Thread bei einem Wayland-Problem eines Users gefallen…bei einer Rolling Release Distribution) verwenden, um hernach quasi alles updaten, sprich neu ziehen, zu müssen.

User mit bereits laufendem System interessiert’s (erstmal) nicht, nur wenn man das aktuelle Image als Sicherheit im Werkzeugkasten haben will.

Btw., Bryanpwo (NL). Dieser ist äußerst rührig. Bspw. habe ich ihm vorgestern kurz geschrieben, daß Links im Light-Theme des Forums farblich nur schwer als solche erkennbar sind (das hat man auch gemerkt, wenn User irritiert nachgefragt haben, wo sie denn klicken sollen). Quasi in derselben Minute hat er die Linkfarbe geändert. Spitzenmäßig.

·

2020-05-09: endeavouros 2020.05.08 (endeavouros-2020.05.08-x86_64.iso.torrent).
2020-04-11: endeavouros 2020.04.11 (endeavouros-2020.04.11-x86_64.iso.torrent).
2019-12-24: endeavouros 2019.12.22 ist freigegeben worden.

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 wie endeavouros.

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 mit endeavouros und 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.