Fedora: Installationsprozess korrumpiert den Speicher

Guten Morgen,

ich hätte nicht gedacht, daß so etwas heutzutage noch möglich ist angesichts der ganzen Speicherschutzmechanismen, aber soeben hat ein Update den Speicher meines PCs durchgerüttelt:

Neu Hinzugekommen:

2020-07-06T08:01:56Z SUBDEBUG Installed: kernel-core-5.7.7-100.fc31.x86_64
2020-07-06T08:01:59Z SUBDEBUG Installed: kernel-modules-5.7.7-100.fc31.x86_64
2020-07-06T08:02:11Z SUBDEBUG Installed: kernel-5.7.7-100.fc31.x86_64
2020-07-06T08:02:11Z SUBDEBUG Installed: kernel-modules-extra-5.7.7-100.fc31.x86_64
2020-07-06T08:02:18Z SUBDEBUG Installed: kernel-devel-5.7.7-100.fc31.x86_64
2020-07-06T08:04:18Z SUBDEBUG Installed: kmod-nvidia-5.7.7-100.fc31.x86_64-3:440.100-1.fc31.x86_64
2020-07-06T08:04:42Z SUBDEBUG Installed: kmod-VirtualBox-5.7.7-100.fc31.x86_64-6.1.10-1.fc31.x86_64

Pakete aktualisiert:

2020-07-06T08:01:52Z SUBDEBUG Upgrade: linux-firmware-whence-20200619-109.fc31.noarch
2020-07-06T08:01:52Z SUBDEBUG Upgrade: linux-firmware-20200619-109.fc31.noarch
2020-07-06T08:02:06Z SUBDEBUG Upgrade: blender-fonts-1:2.83.1-1.fc31.noarch
2020-07-06T08:02:07Z SUBDEBUG Upgrade: blender-1:2.83.1-1.fc31.x86_64
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl100-firmware-39.31.5.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl1000-firmware-1:39.31.5.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl105-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl135-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl2000-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl2030-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl3160-firmware-1:25.30.13.0-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl3945-firmware-15.32.2.9-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl4965-firmware-228.61.2.24-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl5000-firmware-8.83.5.1_1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl5150-firmware-8.24.2.2-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6000-firmware-9.221.4.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6000g2a-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6000g2b-firmware-18.168.6.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl6050-firmware-41.28.5.1-109.fc31.noarch
2020-07-06T08:02:16Z SUBDEBUG Upgrade: iwl7260-firmware-1:25.30.13.0-109.fc31.noarch
2020-07-06T08:02:18Z SUBDEBUG Upgrade: libertas-usb8388-firmware-2:20200619-109.fc31.noarch
2020-07-06T08:02:18Z SUBDEBUG Upgrade: kernel-headers-5.7.7-100.fc31.x86_64

Bei einem dieser Prozesse hat es dann die Schrift in Cinnamon irgendwie zerrissen. Möglich wäre, daß das Update von Blender-Fonts dafür verantwortlich ist. Allerdings kommt der Font laut Schriftenvoreinsteller gar nicht zum Einsatz. Es könnte also alles gewesen sein.

Also passt ein bisschen auf, wenn Ihr heute Updates einspielt, ein direkter Reboot danach wäre sinnvoll!

Dual-Monitor Wallpapers mit Hydrapaper

Update-Mailinglisten sind eigentlich ein Quell von Langeweile, aber ab und zu fällt einem ein Paket ins Auge, das man noch nicht kennt. So etwas ist mir heute, also „vor einer Woche“ aus Eurer Perspektive, aufgefallen: Hydrapaper. Ein Wallpaperprogramm für Gnome und Cinnamon Desktops.

Zwei Monitore – Zwei Hintergrundbilder

Ich habe mich schon lange auf diesen Moment gefreut, denn er löst ein uraltes Cinnamonproblem: die Hintergrundbilder werden nur für einen der beiden Monitor korrekt skaliert, auf dem anderen ist es nur verzerrt zusehen.

Hydrapaper löst das Problem, auch wenn es eigentlich etwas anderes erreichen will, nämlich, daß man zwei verschiedene Hintergrundbilder benutzen kann.

man sieht zwei verschiedene Hintergrundbilder und die Hydrapapers gui.

Die roten Balken sind natürlich in Echt nicht darauf zusehen 😉

Indirekt ist damit auch der Weg frei, je eine ratiokorrekte Bildversion pro Monitor einzusetzen, oder, mit etwas Krita Magie, gleich ein Bild über zwei Monitore korrekt zu verteilen 🙂

So sähe das aus. Aber man muß das nicht machen, denn genau dafür gibt es den Hintergrundbildmodus „gespannt“ in Cinnamon, der zieht ein Bild, wenn es denn genau paßt, auch über beide Monitore.

Das sieht übrigens nur dann gut aus, wenn die beiden Monitore optisch gleich hoch sind, ansonsten bekommt man einen lustigen Versatz ins Bild, was dann echt uncool wirkt. Zwei gleiche Monitore sind da ratsam, weil sonst auch noch Helligkeit, Kontrast und Farbraumabdeckung zu den Problemen hinzukommen.

Alternative zum Grafikprogramm

Bevor Ihr aber mit Krita oder Photoshop ans Werk geht, solltet Ihr Euch überlegen, ob es nicht einfacher wäre, das in der Konsole zu erledigen:

convert Bilder/Wallpapers/godafoss-4k.jpg -crop 3200×1080+0+0 Bilder/Wallpapers/Beide.png

Das Bild vom Goðafoss ist 6448×2350 Pixel groß, was für zwei 3k Bildschirme passt, aber nicht auf einen FullHD und einen alten 1280er Monitor. ImageMagick liefert hierfür die Lösung, da man über den Befehl convert pixelgenau Bilder schneiden kann, was mit Krita eine Geduldsprobe darstellt, vorsichtig ausgedrückt 😉 So ist der Job in Millisekunden erledigt.

Wer noch skalieren muß, der kann das auch in einem Rutsch erledigen:

convert Bilder/Wallpapers/godafoss-4k.jpg -crop 1280×1080+1920+0 -resize 1280×1024 Bilder/Wallpapers/Rechts.png

ImageMagick wird gern auf Servern eingesetzt um Thumbnails von Bildern zu erzeugen, aber das kann soviel mehr … 😉

Anmerkung zu -crop: WeitexHöhe+Xoffset+Yoffset . Ja, ist gewöhnungsbedürftig 🙂

Links: https://gitlab.com/gabmus/HydraPaper

ein kleines Weihnachtswunder

Oh Binärbaum, Oh Binärbaum,
wie verzweigt sind Deine Äste.

Ein kleines Weihnachtswunder hat sich in der Gemeinde zugetragen: Scott Leigh, mein gelegentlicher Erzfeind im Bugzilla ;), hat einen meiner Bugreports ohne Kampf akzeptiert und ein Update bereit gestellt 😀 Danke, Scott 😉

Zieht Euch die Updates für Fedora 28, dem grade hier viel Gescholtenen, einfach auf Koji und ..

cinnamon-4.0.7-1.fc28
cinnamon-screensaver-4.0.3-1.fc28
cinnamon-translations-4.0.2-1.fc28
muffin-4.0.5-1.fc28

installiert Sie mit : dnf update ./muffin*rpm ./cinnamon*rpm

Natürlich funktioniert der Befehl nur dort, wo die RPMs vom Download liegen, aber das wußtet Ihr ja schon 🙂

Ich wünsche Euch noch ein schönes Restweihnachten und einen gemütlichen Jahreswechsel, jetzt ohne Fehlende-icons-im-Toolbar-Problem 😉

 

Wenn Cinnamon ständig crashed

Warum immer in der Weihnachtszeit ? Die sollte doch so friedlich sein. Mein Laptop war anderer Meinung. Vor zwei Wochen erst auf Fedora 26 aktualisiert und seit Mittwoch crasht Cinnamon in Endlosschleife in seinen Rückfallmodus, ohne irgendeine brauchbare Spur zu hinterlassen. Na gut, Challenge Accepted!

Die Versuchsreihe

Zunächst mal sollte man checken, ob man vielleicht ein neues Update bekommen hat und dies das Problem löst. Tat es nicht, weil keines kam.

Ok, jetzt müßte man doch mal nachsehen, was da unter der Haube los ist. Also „journalctl -xe | grep -i cinnamon“ eingegeben und … nichts.

Ok, versuchen wir es ohne den Filter : „journalctl -xe“ und siehe da, jede Menge rote Crashmeldungen in diversen Libs, aber leider kein Hinweis, was da der Auslöser sein könnte. Auch 1 Stunde später, und diverse andere Logs und Webseiten später, senkte sich vom Baum der Erkenntnis die rote Kartenfrucht herab.

Der Reinstall

Ein klares Signal, einen Reinstall durchzuführen, also als Root eingegeben:

dnf reinstall „cinnamon*“

Und wieder in Cinnamon einloggen… args.. gleiches Ergebnis. Hmm.. da hat es wohl noch mehr zerlegt… uff. Also, ‚ dnf reinstall „*“ ‚ eingegeben, also die ersten 80 Pakete bereits runter geladen waren, wollte ich aber doch noch mal etwas anderes austesten.

adduser -s /bin/bash testuser
passwd testuser

Und dann mal als Testuser einloggen. Oh… Das geht ja … Da ist dann wohl doch nur die Session defekt. Dann hauen wir die halt weg:

rm -rf ./.config/cinnamon-session ./.local/share/cinnamon ./.cinnamon

Danach ist der Account so jungfräulich, daß Cinnamon alles wieder sauber anlegt und oh Wunder, dann geht es auch wieder mit dem Login 😀

Man muß natürlich alles neu einstellen,aber das ist ein kleiner Preis. Was meine Session/Einstellungsdaten genau getroffen hatte, wird man wohl nie erfahren 😉

 

Cinnamon – Das fehlende Icon

Problem:

Nach dem Update auf Fedora 26 zeigte die Schnellstartleiste ein leeres Iconfeld:

Schnellstartleiste ohne Icon

Schnell stellte sich heraus, daß es sich dabei um die NVIDIA-Settings handelte. Beim eingestellten ICON-Theme gnome :

Themeeinstellungen mit Gnome

 

gibt es nun aber gar kein Icon dafür, weswegen der Platz leer bleibt.

Alle Versuche, das durch direktes Zuweisen in der Desktop Datei unter /usr/share/applications  zubeheben, schlugen fehl.
Die Desktopdatei wurde immer wieder auf die Defaulteinstellungen „Icon=nvidia-settings“  zurückgesetzt.

Da wird wohl rohe Kraft nötig sein, um das System vom Gegenteil zu überzeugen! 😀

Die Lösung

Das läßt sich schnell beheben, wenn man einen Theme hat, so wie MINT-Y, der ein Icon dafür bereitstellt :

cp /usr/share/icons/Mint-Y/apps/256/nvidia-* /usr/share/icons/gnome/256×256/apps/

Dann noch schnell das Theme Cache erstellen :

gtk-update-icon-cache –force /usr/share/icons/gnome/

Ab sofort ist da wieder ein Icon, wo es hingehört. Dies muß man als Rootuser machen :

Iconleiste mit Icon drin

 

 

 

 

 

 

Linux – 10 FPS mehr auf Gnome

Einem kleinen Verdacht nachgehend, ich habe unter Linux die rohe Framerate von EVE Online auf Cinnamon und Gnome (X-Server) verglichen, beides mit den gleichen CPU/Memory/Grafikkarte/Grafikeinstellungen.

Nicht überraschend kam dabei raus, daß Gnome statte 10 FPS mehr beim internen FPS Counter von EVE schafft, als Cinnamon. Angefühlt hat sich das so schon immer, auch im 2D Betrieb. Wenn damals nicht der blöde Fenster-Zieh-Ruck-Bug unter Gnome gewesen wäre, der monatelange nicht behoben wurde und bei dem man wahnsinnig werden konnte, würde ich das als Desktop ja heute noch benutzen. Ich denke, daß der echte X-Server immer noch schneller ist, als Wayland. Um das zu prüfen, habe ich auch mit Gnome unter Wayland getestet.

Ergebnis: Gnome unter Wayland bringt auch nur 160 FPS in EVE, genau wie Cinnamon, welches wohl auch schon mit Wayland arbeitet.

Jetzt fragt sich der eine oder andere natürlich, wieso einen 10 FPS Unterschied bei 160 FPS stören, die könnte der Monitor ja eh nicht darstellen. Stimmt, kann er nicht, aber wenn man Let’s-Play Videos von Games macht, muß man Screenrecording einsetzen. Dies leidet unter der schlechteren Performance von Wayland, so daß man auf den Aufnahmen später ggf. störendes Tearing hat. Und das würde ich nicht auf Youtube zeigen wollen, weil das dem Image von Linux mal echt schaden würde. GGf. müßte man mal den extra für Games gemachten Capturemodus des OpenGL Hacks versuchen, der soll noch extra FPS bringen. Fragt sich nur, ob das auch das Tearing bekämpfen würde, weil ja nichts aus dem GFX Speicher ausgelesen würde. „Kommen Sie, Watson! Es lohnt sich vielleicht dieser Spur nachzugehen.“ 🙂

Fazit: Ein „Hoch“ auf den X-Server .. alt, aber schneller 😉

Cinnamon Screensaver locked den Desktop nicht mehr

Es ist mal wieder soweit, der halbe Desktop (Linux) Planet ist in Gefahr, naja, fast 🙂

Das Problem

Der Cinnamon-Screensaver 3.4.1-1 lockt den Bildschirm nicht mehr, wenn er soll. Das öffnet natürlich fatale Sicherheitslücken in allen Bereichen, denn wenn der Bildschirmschoner angeht, lockt sich auch i.d.R. der Bildschirm, so daß ein Anderer den PC nicht übernehmen kann. Steht man nun von seinem Platz auf, gibt man mit der 3.4.1-1 die Kontrolle über seinen PC auf.

Und so beheben wir das Problem für Fedora

Zunächst öffnen wir eine ROOT Konsole, als User geht es leider nicht zu beheben. Dann entfernen wir als Root das Paket von PC :

rpm -e --nodeps cinnamon-screensaver

Von der Webseite „https://koji.fedoraproject.org/koji/packageinfo?packageID=16651“ laden wir uns die alte Version 3.4.0-1 passend zu unserem OS z.B. Fedora 25 x86_64  herunter . Danach installieren wir diese Version:

rpm -i ./cinnamon-screensaver-3.4.0-1.fc25.x86_64.rpm

Nun editieren wir noch die /etc/dnf/dnf.conf und tragen bei „exclude“ „exclude=cinnamon-screensaver*“ ein, andernfalls  wird der screensaver gleich wieder geupdated, wenn der nächste Cronjob dafür läuft.

Jetzt melden wir den aktuellen Benutzer vom Desktop ab und gleich wieder an. Das war es dann auch schon.

Bei Fedora ist ein entsprechender Bugreport am laufen, so daß mit einem Fix in den nächsten Tagen zu rechnen ist.

Update 26.6. 2017:

Leight Scott hat schnell reagiert und ein neues Paketupdate gepusht, welches das Problem behebt. Wer also cinnamon-screensaver in der dnf.conf gesperrt hat, kann die Sperre wieder aufheben.

 

 

 

Cairo-Dock unter Gnome und Cinnamon betreiben

Eye Candy ist immer wieder ein Thema bei Linux, denn man kann es ja auch mal schön haben wollen, statt immer nur Konsole sehen zu müssen 😉
Eins der Must-Haves ist dann wohl Cairo-Dock, daß bei Fedora per DNF nachinstallierbar ist. Zusammen mit Cinnamon und Gnome, sieht das alles dann schon richtig gut aus.

Wer Eye Candy auf seinem Desktop/Laptop bevorzugt , z.B. um Windowsuser blass werden zu lassen, wie cool doch der Nicht-Apple so aussehen könnte 😉 der findet in Cairo den richtigen Partner.
Cairo-Dock ist nur ein Dock, also kein Windowmanager und damit kann man es unter Gnome-Cinnamon-Xfce usw. einsetzen.

Die Vielfalt an Effekten ist erweiterbar, aber auch schon so der Hammer. Was ein bisschen blöd voreingestellt ist, sind die Abmaße des Docks, aber das läßt sich leicht anpassen. Die Konfigurationsoberfläche ist mannigfaltig mit Optionen ausgestattet, so daß man da ganz leicht den Überblick verlieren kann:

Probleme gibt es eigentlich nur mit der Positionierung, wenn neue Bildschirmkonstellationen zusammen  kommen, da zickt es ein bisschen, aber am Ende klappt auch das. Wie man sehen kann, hat jemand vergessen, daß Konfigtool richtig zu layouten, aber wer sieht das schon dauernd 😀 Unter Cinnamon war es einfacher das Dock an die richtige Stelle zu bekommen, als mit Gnome, dafür ist Gnome schneller.

Nachdem ich 2 Stunden lang damit rumgespielt habe, kann ich sagen, daß wenn ich jetzt noch einen Monitor im MacDesign hätte, das wohl bei mir im Dauereinsatz wäre. Wobei der Rechner dann im Foyer stehen würde, hinter Glas, damit den jeder sieht 😉

Gnomefehler bei Libinputupdate beheben

Da kommt aus heiterem Himmel ein Update für Cinnamon und Gnome kann plötzlich nicht mehr richtig mit der Maus scrollen. Und jetzt ?

In dem Beitrag über die Anpassungen zu den Mausgeschwindigkeiten, die bei Gnome set einiger Zeit nicht mehr sauber funktionieren, wird gezeigt, wie man sein Eingabegerät ermittelt:

~]$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ImPS/2 BYD TouchPad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ UVC Camera (046d:081b) id=8 [slave keyboard (3)]
↳ Eee PC WMI hotkeys id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]

Meins ist die ID 11, was an einem bekannten Kernelbug zur Erkennung von Touchpads liegt.

Seit dem besagten Update scrollte meine Maus mit dem Scrollrad falsch rum, was unter Cinnamon komischerweise korrekt funktionierte.  Dank der Liste verfügbarer Eigenschaften des „Touchpads“ :

~]$ xinput list-props 11
Device 'ImPS/2 BYD TouchPad':
    Device Enabled (151):    1
    Coordinate Transformation Matrix (153):    1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    libinput Accel Speed (289):    -0.500000
    libinput Accel Speed Default (290):    0.000000
    libinput Accel Profiles Available (291):    1, 1
    libinput Accel Profile Enabled (292):    1, 0
    libinput Accel Profile Enabled Default (293):    1, 0
    libinput Natural Scrolling Enabled (294):    1
    libinput Natural Scrolling Enabled Default (295):    0
    libinput Send Events Modes Available (273):    1, 0
    libinput Send Events Mode Enabled (274):    0, 0
    libinput Send Events Mode Enabled Default (275):    0, 0
    libinput Left Handed Enabled (296):    0
    libinput Left Handed Enabled Default (297):    0
    libinput Scroll Methods Available (298):    0, 0, 1
    libinput Scroll Method Enabled (299):    0, 0, 0
    libinput Scroll Method Enabled Default (300):    0, 0, 0
    libinput Button Scrolling Button (301):    2
    libinput Button Scrolling Button Default (302):    274
    libinput Middle Emulation Enabled (303):    0
    libinput Middle Emulation Enabled Default (304):    0
    Device Node (276):    "/dev/input/event3"
    Device Product ID (277):    2, 5
    libinput Drag Lock Buttons (305):    <no items>
    libinput Horizonal Scroll Enabled (278):

konnte ich mit einem Einzeiler die Scrollrichtung wieder umdrehen:

xinput set-prop 11 289 -0.5 2>/dev/null           # Mausgeschwindigkeit mit LibInput
xinput set-prop 11 294 0 2>/dev/null                # Scrollradrichtung

Komisch, das sowas im Testlauf nicht gefunden wird…

Update: 13.12.2016

Der neue Kernel 4.8.13 behebt das Problem, weil die PS/2 Mäuse jetzt als Maus erkannt werden un dnicht mehr als Touchpads.