Flatpak ist */()$§*#D3§$

Ich fand ja FlatPak schon im letzten Artikel nicht so prall, wegen der ganzen Platzverschwendung, aber das hier topt es grade :

[marius ~]$ /usr/bin/flatpak info "com.belledonnecommunications.linphone/x86_64/4.1.1"
Ref: app/com.belledonnecommunications.linphone/x86_64/4.1.1
ID: com.belledonnecommunications.linphone
Arch: x86_64
Branch: 4.1.1
Origin: com.belledonnecommunications.linphone-1-origin
Commit: bae79f29ce390b6b28254cba0ae63f1bbb8d9a30f50acce422ce5ef1f1839441
Location: /home/marius/.local/share/flatpak/app/com.belledonnecommunications.linphone/x86_64/4.1.1/bae79f29ce390b6b28254cba0ae63f1bbb8d9a30f50acce422ce5ef1f1839441
Installed size: 315,4 MB
Runtime: org.freedesktop.Platform/x86_64/1.6
[marius ~]$ /usr/bin/flatpak update "com.belledonnecommunications.linphone/x86_64/4.1.1"
Looking for updates...
Fehler: com.belledonnecommunications.linphone/x86_64/4.1.1 not installed
[marius ~]$ /usr/bin/flatpak update app/com.belledonnecommunications.linphone/x86_64/4.1.1
Looking for updates...
Fehler: app/com.belledonnecommunications.linphone/x86_64/4.1.1 not installed

Also, mit der original REF, die die INFO Anweisung ausgibt ODER die auch LIST ausgibt, behauptet Flatpak, die Anwendung wäre nicht installiert. Lustigerweise will er die Starten, was übrigens nicht geht, weil die NVIDIA Treiber aktualisiert worden sind und nun die von Flatpak installierten Treiber zu den Treibern nicht mehr passen:

Installiert ist 384.90 , aber Flatpak hat noch 375 im Einsatz :

[marius]$ flatpak list
Ref Options 
com.belledonnecommunications.linphone/x86_64/4.1.1 user,current
org.freedesktop.Platform.GL.nvidia-375-66/i386/1.4 user,runtime
org.freedesktop.Platform.GL.nvidia-375-66/x86_64/1.4 user,runtime
org.freedesktop.Platform/x86_64/1.6 user,runtime

Das Ende von Lied: LinPhone startet nicht mehr 😀 Natürlich updated flatpak auch nichts, wenn man nur „update“ eingibt, was alles aktualisiert laut Manpage, aber es gibt wohl kein Update dafür 😀

Fazit: Tolle Idee son System im System 😀

Aufruf: Nieder mit den Flatpaks und Snappys dieser Welt. Es lebe DNF ! 😉

PS: Zu DNF kommen wir morgen nochmal 😀

Update: Annahme verweigert

Der Red Hat Bugbetreuer hat die Meldung, daß die installierten Flatpakapps nicht gefunden werden, wenn man sie namentlich angibt, als „Kein Bug“/“Kein Supportforum“ abgetan. Also entweder der weiß mehr als wir zu dem Thema, oder er hat leider keine Vorstellung davon, was ein Bug in Flatpak sein könnte 🙂

Mal sehen was per Github vom Projektmaintainer kommt :  https://github.com/flatpak/flatpak/issues/1139

Update installiert falsche Nvidiatreiber

Schock in der Abendstunde:  der Rechner bootet nicht mehr.

Ok, das Fehlerbild entspricht genau diesen How To: Wie man nvidia akmods nachbaut hier , nur leider funktioniert der FIX nicht 🙁  Und dann sitzt man da in der Konsole und weiß nicht weiter.

Was war passiert ?

Um das zu klären, lohnt sich immer ein Blick ins DNF Logfile : /var/log/dnf.rpm.log  und wie man sieht, findet sich dort das Update auf Nvidia Treiberversion 384.90 vor ein paar Tagen:

Oct 25 20:01:13 INFO Upgraded: xorg-x11-drv-nvidia-kmodsrc-2:384.90-1.fc25.x86_64
Oct 25 20:01:15 INFO Cleanup: xorg-x11-drv-nvidia-kmodsrc-2:375.66-7.fc25.x86_64

Das anschließende Update am 26.10. führte dann ins Chaos, weil …

Oct 26 06:02:31 INFO Erased: kmod-nvidia-4.12.13-200.fc25.x86_64-2:375.66-3.fc25.x86_64
Oct 28 20:41:29 INFO Upgraded: xorg-x11-drv-nvidia-cuda-libs-2:384.90-1.fc25.x86_64
Oct 28 20:41:31 INFO Upgraded: xorg-x11-drv-nvidia-libs-2:384.90-1.fc25.i686
Oct 28 20:41:33 INFO Upgraded: xorg-x11-drv-nvidia-libs-2:384.90-1.fc25.x86_64
Oct 28 20:41:34 INFO Erased: kmod-nvidia-4.13.5-100.fc25.x86_64-2:375.66-3.fc25.x86_64
Oct 28 20:41:38 INFO Erased: kmod-nvidia-4.12.14-200.fc25.x86_64-2:375.66-3.fc25.x86_64
Oct 28 20:41:43 INFO Cleanup: xorg-x11-drv-nvidia-libs-2:375.66-7.fc25.x86_64
Oct 28 20:41:43 INFO Erased: xorg-x11-drv-nvidia-cuda-2:375.66-7.fc25.x86_64
Oct 28 20:41:44 INFO Erased: xorg-x11-drv-nvidia-2:375.66-7.fc25.x86_64
Oct 28 20:41:45 INFO Erased: akmod-nvidia-2:375.66-3.fc25.x86_64
Oct 28 20:41:45 INFO Cleanup: xorg-x11-drv-nvidia-libs-2:375.66-7.fc25.x86_64
Oct 28 20:41:45 INFO Cleanup: xorg-x11-drv-nvidia-cuda-libs-2:375.66-7.fc25.x86_64
Oct 28 20:45:32 INFO Installed: xorg-x11-drv-nvidia-304xx-libs-304.137-1.fc25.x86_64
Oct 28 20:45:38 INFO Installed: xorg-x11-drv-nvidia-304xx-304.137-1.fc25.x86_64
Oct 28 20:45:38 INFO Installed: akmod-nvidia-304xx-304.137-2.fc25.x86_64
Oct 28 20:46:12 INFO Installed: kmod-nvidia-304xx-4.13.8-100.fc25.x86_64-304.137-2.fc25.x86_64
Oct 28 20:48:41 INFO Installed: kmod-nvidia-304xx-4.12.14-200.fc25.x86_64-304.137-2.fc25.x86_64
Oct 28 20:49:15 INFO Installed: kmod-nvidia-304xx-4.13.5-100.fc25.x86_64-304.137-2.fc25.x86_64

die falsche Version 304 installiert wurde. Ich kann nur spekulieren, warum es diesen alten Treiber noch gibt, aber dieses Nvidia Modul kann eine GTX 1050 nicht erkennen und failed damit beim modprobe mit „no such device“. Damit startet der XServer nicht und das ganze System kommt nicht ins Laufen.

Zu allem Überfuß hat es dann beim Fix auch noch die /etc/default/grub zerlegt, so daß der Rechner im Textmodus gestartet ist. Wie man das fixt steht hier: Fedora grafischen Bootvorgang aktivieren

Lösung

mit „rpm -qa | grep nvidia“ alle RPMs identifizieren, die als Version 304xx drin stehen haben. Die dann mit „dnf erase rpmname“ entfernen.

Danach mit „dnf install akmod-nvidia“ die aktuellen Treiber installieren.  Dann „akmods“ und „nvidia-config“ ausführen und den Rechner rebooten.

Ich empfehle den grafischen Bootvorgang vor dem Reboot noch zu fixen, das spart Ärger.

Achtung: der Plymouth Theme „solar“ scheint buggy zu sein, nehmt „charge“.

How To: Wie man nvidia akmods nachbaut

Wer Fedora benutzt und eine Nvidia Grafikkarte, wird i.d.R. auch die RPMFusion Treiber für Nvidia benutzen, da diese einfacher zu installieren sind als Nvidia selbst zu kompilieren.

Mußte man früher auf die neuen Kerneltreibermodule warten, weil sie passend vorkompiliert waren, werden diese heute über akmods gebaut, wenn ein neuer Kernel installiert wurde.

Was aber, wenn das aus irgendeinem Grund nicht ging ?

Dann bootet Eurer Rechner sich in eine Endlosschleife beim Start. Aus dieser gibt es nur ein Entkommen: Rebooten und dann einen anderen Kernel auswählen.

Damit hat man erstmal ein funktionierendes System zurück, aber nutzt einem das was ? Nein!

Die Module werden in Abhängigkeit vom aktuell laufenden Kernel getestet und notfalls beim Booten gebaut. Da ein alter Kernel läuft und gebootet hat, braucht man jetzt kein neues Modul mehr, weil es ist schon da.

Anstatt also auf alle installierten Kernel zu testen und zu bauen, wird nur auf den laufenden Kernel getestet. Also kann man die Module nur bauen, wenn der Rechner den neuen Kernel bootet: Ein Teufelskreis 😀

Wie man die Kernelmodule selbst baut

Wir brauchen die üblichen Balls-of-Steel, das Rootpasswort und jemanden, der Euch clevererweise diese Anleitung ausgedruckt hat, denn Ihr werdet Sie sonst nicht lesen können, wenn Ihr das macht 😉

1. Rebooten in das Grubmenü

2. Im Grubmenü den aktuellen Kernel auswählen und „e“ drücken

3. Ihr seht den Grubbooteintrag für diesen Kernel vor Euch:

Die ganzen XXXX sind Platzhalter für Eure UUIDS von den Festplatten, einfach ignorieren!

load_video
set gfxpayload=keep
insmod gzio
insmod part_msdos
insmod ext2
set root='hd2,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
    search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hintbaremetal=ahci2,msdos1  XXXX
else
    search --no-floppy --fs-uuid --set=root XXXXX
fi
linux /vmlinuz-4.6.4-201.fc23.x86_64 root=/dev/mapper/luks-XXX ro vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-caXXXX 
rd.luks.uuid=luks-XXX rhgb quiet splash LANG=de_DE.UTF-8 1
initrd /initramfs-4.6.4-201.fc23.x86_64.img

Die grüne Zeile ist die wichtige Zeile für Euch. Hängt am Ende eine „1“ dran, so wie oben zu sehen. Damit bootet der Rechner nicht in die Grafische Oberfläche ( Runlevel 5), sondern geht in die Rootkonsole ( Runlevel 1 ) . Im Runlevel 1  werden die ganzen nicht existenten Treiber noch nicht geladen, weswegen das funktioniert.

4. Gebt das Rootpasswort ein, wenn Ihr gefragt werdet

5. gebt „akmods“ ein .. und wartet bis es fertig ist. Es dauert ein bisschen.

6. gebt „init 5“ ein, wenn keine Fehler gemeldet wurden und Eurer Rechner bootet in die normale Oberfläche weiter – mit dem neuen Kernel

 

Plymouth Bootloader, Nvidia und die 64Bit

In einem Beitrag von 2014 zum Thema Bootanimation richtig einstellen, hatte ich schon einmal gezeigt, wie man sich verschiedene Bootthemes konfiguriert. Mit der Anleitung kann man sich auch den grafischen Bootvorgang zurück konfigurieren, wenn dieser durch ein Update verloren geht, denkt man sich so.

Grub hat da seine eigene Vorstellung von und erstellt eine spezielle Bootconfig, wenn ein 64Bit System gefunden wird. Das wiederum verhindert, daß der Bootloader als Grafische Animation erscheint, weil dieser Modus zusammen mit NVIDIA Grafikkartentreibern nicht ganz funktioniert. Genu genommen, gar nicht 🙂

Lösung:

# vi /etc/grub.d/10_linux
# grub2-mkconfig -o /boot/grub2/grub.cf

Folgende Zeile suchen und ersetzen :

sixteenbit="16"

mit

sixteenbit=""

Man findet das in diesem Block :

linux_entry ()
{
os="$1"
version="$2"
type="$3"
args="$4"

sixteenbit=""
linuxefi="linux"
initrdefi="initrd"
case "$machine" in
i?86|x86_64)
sixteenbit=""
linuxefi="linuxefi"
initrdefi="initrdefi"
;;
aarch64)
linuxefi="linux"
initrdefi="initrd"
;;
esac

Nun kann das System wieder grafisch booten.

Mit Yum Paketupdates rückgängig machen

Ab und zu kann es vorkommen, daß neue Pakete von Treiber oder Programmen zu Fehlern führen. Jüngstes Beispiel ist der Nvidia Treiber für Fedora 20. Da die Auswirkungen erst nach dem Neustart des Computers wirksam werden, benötigt man zum Beheben des Problems Rootrechte.

Pakete identifizieren

Zunächst einmal muß man die Pakete finden, die aktualisiert wurden. Dazu schaut man sich die letzten Zeilen des Yum Logfiles an :

# tail /var/log/yum.log
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-3.17.8-200.fc20.x86_64-340.65-4.fc20.x86_64
Jan 29 00:42:04 Updated: 1:kmod-nvidia-340xx-340.65-4.fc20.x86_64
Jan 29 00:45:22 Installed: 1:kmod-nvidia-3.17.8-200.fc20.x86_64-331.113-1.fc20.1.x86_64

Pakete die mit der Sache nichts zu tun haben, könnten natürlich auch installiert worden sein, im obigen Beispiel ist das nicht der Fall.

Pakete downgraden

Die Pakete wieder los zu werden ist ganz einfach, wenn man den korrekten Namen ermittelt hat:

# yum downgrade kmod-nvidia-340xx-3.17.8-200.fc20.x86_64
# yum downgrade kmod-nvidia-340xx-340

Updates verhindern

Damit die Pakete beim nächsten Update nicht wieder mit eingespielt werden, trägt man diese in die Liste der ausgeklammerten Pakete in der YUM Konfiguration ein:

# vi /etc/yum.conf

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=kmod-nvidia-340xx*

Damit wäre man vorerst vor Updates sicher.  Das nächste Kernelupdate kommt aber todsicher und dann braucht man die neue Version der Pakete für diesen neuen Kernel. Man muß sich also jetzt sofort darum kümmern, daß dieser Fehler bekannt und natürlich behoben wird.

Bugzilla

RPMFusion und Fedora haben jeweils eine eigen Fehlertrackersoftware namens Bugzilla im Einsatz. Da die Nvidiatreiber über RPMFusion bekommen sind, muß man das Paket dort als Fehlerhaft melden.

Details zur Anmeldung kann man auf rpmfusion.org finden.

Es geht aber auch direkter, was in diesem Fall wohl dringend nötig ist. Dazu lädt man sich die defekten RPMS aus dem Repository direkt auf die Platte. Wie das geht habe ich hier beschrieben: Aus Yum ableiten wo ein RPM findet

Dann schaut man sich die Infos zu diesem RPM an : less xorg-x11-drv-nvidia-340xx-*

Neben allerlei Informationen zu dem Paket selbst, kann man hier auch direkt das Changelog sehen:

* Di Jan 27 2015 Leigh Scott <leigh123linux@googlemail.com> – 1:340.65-5
– revert last commit

Nun können Sie das direkt an den Entwickler melden, der das „verbockt“ hat 🙂

wenn das Paket bereits installiert ist …

geht das Aufrufen des Changelogs wesentlich einfacher :

# rpm -q –changelog xorg-x11-drv-nvidia-340xx
* Do Jan 15 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-4
– Replace main nvidia driver in F20 with this legacy version

* So Jan 11 2015 Przemysław Palacz <pprzemal@gmail.com> – 1:340.65-3
– Switch libnvidia-ml and nvidia-debugdump to the cuda subpackage again

… die Logs gehen bis zur ersten Release des Pakets zurück …

* So Jun 22 2003 Andreas Bierfert (awjb) <andreas.bierfert[at]awbsworld.de> – 0:1.0.4363-0.fdr.1
– Initial RPM release, still some ugly stuff in there but should work…

Kein Wunder, daß die Pakete immer länger brauchen bis sie geladen worden sind.