Nvidia: Fehlercodes

Seit einigen Wochen nervt meine GTX 1050, eine schöne Gelegenheit Euch mal das Nvidia Fehlersystem näher zu bringen.

Nvidia: Fehlercodes

Zuerst müssen wir natürlich erstmal wissen, welcher Fehler überhaupt aufgetreten ist. Dazu braucht es nur dmesg:

$ dmesg |grep Xid
[ 5552.987812] NVRM: Xid (PCI:0000:01:00): 32, pid=1550, Channel ID 00000033 intr 00040000
[ 5731.173383] NVRM: Xid (PCI:0000:01:00): 32, pid=11658, Channel ID 00000033 intr 00040000
[ 5731.173633] NVRM: Xid (PCI:0000:01:00): 32, pid=11658, Channel ID 00000033 intr 00040000
[ 6326.298292] NVRM: Xid (PCI:0000:01:00): 32, pid=11982, Channel ID 00000033 intr 00040000
[ 6326.298525] NVRM: Xid (PCI:0000:01:00): 32, pid=11982, Channel ID 00000033 intr 00040000

Wie bei allen Kernelmeldungen steht am Anfang die Kernelzeit in Sekunden seit dem Boot. Danach kommt als erstes die PCI ID des Gerätes, aber da selten jemand zwei oder mehr Grafikkarten im PC hat, ist das für die meisten uninteressant. Der Fehlercode selbst ist die unscheinbare Zahl nach der PCI ID, hier „32“.

Auf der Webseite von Nvidia: xid errors findet sich dann die Beschreibung für den Fehler und erste Hinweise zur Ursache:

XIDFailureCauses
HW ErrorDriver ErrorUser App ErrorSystem Memory CorruptionBus ErrorThermal IssueFB Corruption

31

GPU memory page fault

X

X

32

Invalid or corrupted push buffer stream

X

X

X

X

X

Xid 32 meint also, daß der Datenstrom zu Grafikkarte unterbrochen wurde. Mögliche Ursachen: Der Graka-Speicher ist defekt, der PCI Bus hat ne Macke oder irgendwas ist überhitzt. (FB Corruption meint FRAMEBUFFER kaputt, das sind die Strukturen im OS/Programm welche die Grafik handhaben. )

Wie man vorn sehen kann, handelt sich nicht um einen HW Fehler, sondern am wahrscheinlichsten um einen Grafikkartentreiberbug.

Ab jetzt kann man nur noch spekulieren, weil das ja alles mögliche meinen kann. Es geht sogar soweit, daß Xid 32 Probleme bei der Stromzuführung in die Grafikkarte meinen kann, also wenn das Netzteil schwächelt. Da aber der Bildschirm nicht ausgeht, hat die Graka noch genug Saft, das kann es also eigentlich nicht sein.

Jetzt können wir noch etwas ausschließen: Thermalprobleme

55 Grad sind völlig normal. Im Bild oben sind zwar die Lüfter aus, aber die funktionieren nachweislich, denn man hört sie bei der Arbeit 😉

Das Nvidia Settingstool (oben im Bild) kann man beim Gamen auf dem zweiten Monitor mitlaufen lassen und so die Anzeige im Auge behalten.

Vielleicht doch nur ein Treiberproblem?

Jetzt bringt uns das nicht weiter. Wir haben zwar 2 Sachen ausschließen können, aber es blieben immer noch FB Problem, Memoryproblem. Keins davon kann man prüfen.

Was man jetzt noch prüfen könnte, steht im /var/log/messages sofern man das noch hat. ( Habt Ihr nicht mehr, nur noch Systemd? Ihr tut mir so leid .. ehrlich 🙁 )

$ grep NVRM /var/log/messages

Jul 23 00:43:18 eve kernel: NVRM: Xid (PCI:0000:01:00): 31, pid=1923, Ch 00000020, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_PE_0 faulted @ 0x1_0ca39000. Fault is of type FAULT_PTE ACCESS_TYPE_READ

Andere Fehlernummer.. interessant. Ist ein reiner Anwendungsbug. In diesem Fall in WINE. Wine hat in den letzten Wochen unheimlich viele Updates rausgehauen. Es wäre also wirklich im Bereich des Möglichen, daß Wine bzw. der 3D Treiber in Wine ( DXVK ) hier die eigentliche Ursache sind.

Wine hat allerdings noch ganz andere Probleme, die die Entwickler aber leider nicht wahr haben wollen, weil Bugreports ignoriert werden. Ab Wine-Staging 5.5+ kommt es zu einem wahrlich irren Bug:

Es kommt in Verbindung mit dem Grakafehler zu einem IO-Fehler mit dem DVD-ROM, welches aber gar nicht benutzt wird noch eine DVD drin hat. Das sieht dann so aus:

[22163.062313] sr 1:0:0:0: [sr0] tag#26 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[22163.062316] sr 1:0:0:0: [sr0] tag#26 Sense Key : Not Ready [current]
[22163.062319] sr 1:0:0:0: [sr0] tag#26 Add. Sense: Medium not present – tray closed
[22163.062321] sr 1:0:0:0: [sr0] tag#26 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00
[22163.062323] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 2 prio class 0
[22163.062366] sr 1:0:0:0: [sr0] tag#3 unaligned transfer
[22163.062368] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062370] Buffer I/O error on dev sr0, logical block 0, async page read
[22163.062382] sr 1:0:0:0: [sr0] tag#4 unaligned transfer
[22163.062383] blk_update_request: I/O error, dev sr0, sector 1 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062384] Buffer I/O error on dev sr0, logical block 1, async page read
[22163.062393] sr 1:0:0:0: [sr0] tag#5 unaligned transfer
[22163.062394] blk_update_request: I/O error, dev sr0, sector 2 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062395] Buffer I/O error on dev sr0, logical block 2, async page read
[22163.062404] sr 1:0:0:0: [sr0] tag#6 unaligned transfer
[22163.062405] blk_update_request: I/O error, dev sr0, sector 3 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062406] Buffer I/O error on dev sr0, logical block 3, async page read
[22163.062415] sr 1:0:0:0: [sr0] tag#7 unaligned transfer
[22163.062416] blk_update_request: I/O error, dev sr0, sector 4 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062417] Buffer I/O error on dev sr0, logical block 4, async page read
[22163.062425] sr 1:0:0:0: [sr0] tag#8 unaligned transfer
[22163.062427] blk_update_request: I/O error, dev sr0, sector 5 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062427] Buffer I/O error on dev sr0, logical block 5, async page read
[22163.062436] sr 1:0:0:0: [sr0] tag#9 unaligned transfer
[22163.062437] blk_update_request: I/O error, dev sr0, sector 6 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062438] Buffer I/O error on dev sr0, logical block 6, async page read
[22163.062446] sr 1:0:0:0: [sr0] tag#10 unaligned transfer
[22163.062448] blk_update_request: I/O error, dev sr0, sector 7 op 0x0:(READ) flags 0x0 phys_seg 2 prio class 0
[22163.062448] Buffer I/O error on dev sr0, logical block 7, async page read

und das ist nur beim Starten von Wine, da ist noch nicht mal eine GFX Operation gelaufen. Mit WIne 5.13 geht nicht mal ein Fenster auf, das ist derzeit komplett im *****.

Das bestärkt mich in der Annahme, daß es sich um reine Driverbugs handelt, die von WINE getriggert werden. Rein zur Vorsicht, habe ich das .nv/GLCache geleert, vielleicht lag da ja noch was defektes drin.

Mehr ist zu dem Zeitpunkt leider nicht feststellbar. Jetzt hilft nur Testen, updaten, Testen und weiter Testen.

 

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Zwei Sicherheitslücken sind im NVIDIA GFX-Kartentreiber für Linux enthalten, wenn Ihr noch nicht die brandaktuellste Version haben solltet, was schwierig sein dürfte.

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Laut der Bugbeschreibung bei Nvidia, handelt sich dabei bei einer Lücke um einen Bug in der IPC Communication API, was man braucht um Daten zwischen einzelnen Prozessen hin und her zu schicken. Dieser Fehler kann dazu genutzt werden um mit erweiterten Rechten eingeschleusten Code auszuführen.

CVE-IDs
Addressed
Software ProductOperating SystemDriver BranchAffected VersionsUpdated Versions
CVE‑2020‑5963
CVE‑2020‑5967
GeForceLinuxR450All versions prior to 450.51450.51
Quadro, NVSLinuxR450All versions prior to 450.51450.51
R440All versions prior to 440.100440.100
R390All versions prior to 390.138390.138
TeslaLinuxR450All R450 versionsAvailable the week of June 29, 2020
R440All versions prior to 440.95.01440.95.01
R418All versions prior to 418.152.00418.152.00

Die zweite Schwachstelle ist dann schon schwieriger auszunutzen, da eine RACE Condition ist, es kämpfen also zwei Prozesse um eine Ressource. Der Gewinn des RACE würde einen DOS erlauben. Was ein Angreifer auf einem DesktopPC davon haben würde die Grafikkarte zu crashen, naja. Ist trotzdem gut, daß es gefixt wurde.

Für Fedora lautet die Treiberversion für meine GFX-Karte 440.82 und muß daher aktualisiert werden. Da diese aus dem Repo von RPMFusion stammt, dürfte der Verbreitungsgrad und damit der Updatezwang unter Fedora/Centos/RHEL Benutzern entsprechend hoch sein. Wie das zu Problemen führen kann und was man das machen muß, lest Ihr hier: Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Bei RPMFusion habe ich heute schon angeklopft, daß Updates benötigt werden.

Quelle: https://nvidia.custhelp.com/app/answers/detail/a_id/5031

Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Diese Geschichte fängt an mit: „Es war einmal eine Grafikkarte“.

„Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll“

Wie Ihr wisst, gibt es von Nvidiatreibern verschiedene Versionsnummern, z.b. 340,390,440. 440 ist der aktuelle Treiber für GTX1050 Karten.

Jetzt wirft dieser Treiber beim Systemboot eine Fehlermeldung wie folgt:

[ 222.363327] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 222.363328] [drm] No driver support for vblank timestamp query.
[ 222.397236] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:05:00.0 on minor 0
[ 222.406533] ————[ cut here ]————
[ 222.406534] refcount_t: underflow; use-after-free.
[ 222.406550] WARNING: CPU: 1 PID: 513 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
[ 222.406551] Modules linked in: nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(OE) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel nvidia(POE) snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep joydev snd_seq snd_seq_device edac_mce_amd drm_kms_helper snd_pcm kvm_amd snd_timer drm snd kvm ipmi_devintf sp5100_tco irqbypass wmi_bmof ipmi_msghandler k10temp i2c_piix4 soundcore pcspkr gpio_amdpt gpio_generic acpi_cpufreq nfsd binfmt_misc auth_rpcgss nfs_acl lockd grace sunrpc ip_tables dm_crypt hid_logitech_hidpp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ccp r8169 aacraid hid_logitech_dj wmi pinctrl_amd fuse
[ 222.406576] CPU: 1 PID: 513 Comm: plymouthd Tainted: P OE 5.5.10-200.fc31.x86_64 #1
[ 222.406577] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P3.90 12/09/2019
[ 222.406579] RIP: 0010:refcount_warn_saturate+0xa6/0xf0
[ 222.406581] Code: 05 2e 03 2e 01 01 e8 7b 8e bc ff 0f 0b c3 80 3d 1c 03 2e 01 00 75 95 48 c7 c7 18 99 3c 9d c6 05 0c 03 2e 01 01 e8 5c 8e bc ff <0f> 0b c3 80 3d fb 02 2e 01 00 0f 85 72 ff ff ff 48 c7 c7 70 99 3c
[ 222.406582] RSP: 0018:ffffb573c103fcb8 EFLAGS: 00010286
[ 222.406583] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000007
[ 222.406584] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff9416ce859cc0
[ 222.406585] RBP: ffff9416bacbfce8 R08: 0000000000000413 R09: 0000000000000003
[ 222.406585] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9416c70502e8
[ 222.406586] R13: ffff9416c7050000 R14: 0000000000000008 R15: 0000000000000000
[ 222.406588] FS: 00007f07558f3f00(0000) GS:ffff9416ce840000(0000) knlGS:0000000000000000
[ 222.406588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 222.406589] CR2: 00007f0755072052 CR3: 00000004035c6000 CR4: 0000000000340ee0
[ 222.406590] Call Trace:
[ 222.406597] nv_drm_atomic_helper_disable_all+0xec/0x290 [nvidia_drm]
[ 222.406603] nv_drm_master_drop+0x22/0x60 [nvidia_drm]
[ 222.406616] drm_drop_master+0x1e/0x30 [drm]
[ 222.406628] drm_dropmaster_ioctl+0x4c/0x90 [drm]
[ 222.406639] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406651] drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 222.406663] drm_ioctl+0x208/0x390 [drm]
[ 222.406675] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406678] ? do_filp_open+0xa5/0x100
[ 222.406681] ? selinux_file_ioctl+0x174/0x220
[ 222.406683] do_vfs_ioctl+0x461/0x6d0
[ 222.406685] ksys_ioctl+0x5e/0x90
[ 222.406686] __x64_sys_ioctl+0x16/0x20
[ 222.406690] do_syscall_64+0x5b/0x1c0
[ 222.406693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 222.406695] RIP: 0033:0x7f0755bb138b
[ 222.406697] Code: 0f 1e fa 48 8b 05 fd 9a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cd 9a 0c 00 f7 d8 64 89 01 48
[ 222.406697] RSP: 002b:00007ffced5fe798 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 222.406699] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0755bb138b
[ 222.406699] RDX: 0000000000000000 RSI: 000000000000641f RDI: 0000000000000009
[ 222.406700] RBP: 000000000000641f R08: 000055b6a6ff1df0 R09: 000055b6a6fa5010
[ 222.406701] R10: 0000000000000000 R11: 0000000000000246 R12: 000055b6a6ff2970
[ 222.406701] R13: 0000000000000009 R14: 0000000000000000 R15: 0000000000000000
[ 222.406703] —[ end trace fa45bb73ed0780f4 ]—
[ 222.411358] kauditd_printk_skb: 45 callbacks suppressed

Von Euch sieht natürlich jeder sofort, daß hier NVIDIA und PLYMOUTH im Spiel sind und das der Nvidiatreiber einen Fehler bei der DRM Initialisierung verursacht. Der Server bootet danach weiter, also erstmal nicht so wichtig. Es folgen die üblichen Dinge: Bugreport bei Fedora ( wegen Plymouth ) und bei RPMFusion ( wegen Nvidia ) erstellen, und komplett entäuscht werden… !

„Da ist kein Bug, gehen Sie weiter!“

Nun kann Fedora da nicht viel machen, wenn der Nvidiatreiber da Mist baut, außer natürlich, es übergibt dem Treiber schon was falsches, da könnte der Treiber dann nicht mehr soviel für den Bug. Das werden wir aber nie erfahren, denn der Bug wurde sofort beerdigt. Nagut, wir haben ja noch den RPMFusionreport.

Sagte ich, wir haben noch einen anderen offenen Bugreport? So kann man sich irren: „Your Bugreport has been closed with „WONT FIX“.Und dann stehen wir mit einem Fehler da, von dem alle Parteien sagen „Nicht mein Problem“. Doch, Eurer Problem! Wessen denn sonst?

Der Bug wurde in der Devliste von Nvidia zwar besprochen, aber es gibt leider keinen finalen Fix dafür:

Devliste: https://forums.developer.nvidia.com/t/bug-nvidia-440-64-kernel-5-5-6-stable-boot-trace-was-nvidia-440-59-kernel-5-5-1-stable-boot-trace/111643

Der derzeitige Stand ist: Geht halt nicht; und DRM geht dann halt auch nicht. Wobei letzteres sollte man eh abschaffen, falls damit das DigitalRightsManagement gemeint ist.

Was mich aber am meisten stört: „ist nicht unser Problem“. Von RPMFusion hätte ich erwartet, daß das offen bleibt, bis das von den Nvidiadevs gefixt wurde, schon um das Problem zu tracken, aber von Scott kann man halt oft nichts anderes erwarten.

Fedora: Kernel 5.4.7 verfügbar

Mit dem Push vom Linux Kernel 5.4.7 ins stabile Repository von Fedora, hat die Nvidia HDMI Audiokrise ein Ende.

Kernel 5.4.7 verfügbar

Wie in dem Beitrag vom Dezember 2019 „Kernel 5.3.16 mit HDMI-Audio Problemen“ beschrieben, gab es ein ein kleines Problem beim korrekten Markieren von NVIDIA Audiogeräten, z.b. Monitoren mit Lautsprechern. Das wurde nicht mehr für die 5.3er Serie des Kernels behoben, obwohl es nur EIN einziger Zeichenwechsel gewesen wäre.

Wie sich damals ja schnell herausgestellt hat, wollte man mit einem Fix eigentlich ein anderes Problem bei Audiogeräten beheben, hat aber mehr kaputt gemacht, also der Fix behoben hatte. Da so ein Kernelbuild auch auf einem schnellen i7 auf SSDs mal locker 1h plus Tests dauern kann,  kann ich schon verstehen, daß man keine eigene Kernelrelease für den an sich trivialen Fix gebaut hat, zumal man einfach auf einen alten Kernel ausweichen konnte.

Es bleibt zu hoffen, daß es nicht nochmal passiert, denn es hat echt in den Ohren geklingelt.

Kernel 5.3.16 mit HDMI-Audio Problemen

Na klingeln Euch auch noch die Ohren? Mir tun die jetzt noch weh! Wer eine NVIDIA Grafikkarte und einen aktuellen 5.3.16 Kernel einsetzt, der sollte jetzt kein HDMI benutzen.

Kernel Regression durch Patch für eine andere Regression

Es ist immer blöd, wenn der Fehlerfix mehr Probleme macht, als er behebt. So geschehen im neuen 5.3.16 Kernel, wenn man eine NVIDIA Karte hat. Wie Takashi Iwai von Suse dazu schreibt:

The commit e38e486d66e2 („ALSA: hda: Modify stream stripe mask only when needed“) tried to address the regression by the unconditional application of the stripe mask, but this caused yet another
regression for the previously working devices. Namely, the patch clears the azx_dev->stripe flag at snd_hdac_stream_clear(), but this may be called multiple times before restarting the stream, so this
ended up with clearance of the flag for the whole time.

Hat da wohl jemand eine Kleinigkeit nicht bedacht aka die falsche Stelle gepatched 😉 Als Resultat fallen einem fast die Ohren ab, weil die Lautstärke des HDMI Streams so derbe übersteuert klingt, daß selbst 2% Lautstärke nur als Lärm bezeichnet werden können. Ich vermute das hier die Audiodaten im falschen Format angeliefert werden, wo alles was leise wäre, extrem laut ist z.b. LE statt BE Sortierung der Bits.

Die Lösung

Natürlich gibt es eine einfach Lösung für das Problem: 5.3.15 booten oder bis zum nächsten Kernelupdate kein HDMI benutzen 😉

Update:

Laut Laura Abbot von Red Hat wird der Fehler nicht mehr in der 5.3er Serie behoben, was ich bislang bestätigen kann, denn der 5.3.18 hat die gleiche Macke. Es soll stattdessen gleich der 5.4.0 Kernel gebaut werden. Frau Abbot bemüht sich darum, daß der Patch bereits in 5.4.0 einfliesst.

Der Soundbug ist auch unabhängig von den Treibern, aber das habe ich nicht anders erwartet.

Update: wurde in 5.4.5 gefixt.

Nvidia und das Tearing

Screen Tearing, das Phänomen, daß ein Teil des Monitorbildes schon einen Frame weiter ist, also der andere.

Beispiel:

Es passiert bei Spielen, beim Videos ansehen und auch mal beim Bewegen von Fenstern. Nvidia Grafikkarten sind leider prädestiniert für dieses Problem, weil, und das ist der fiese Teil, Nvidia die Funktion zum Unterdrücken des Tearings standardmäßig abgeschaltet hat.

Aber, Abhilfe ist nah 🙂

 

Erstmal brauchen wir das Nvidia Configtool und wählen dort die Display Configuration aus.

Wir brauchen den Advanced Button.

Jetzt aktivieren wir die Force Composition Pipeline und das Tearing ist Geschichte.

Sollte die Force Composition Pipeline nicht reichen, braucht es die Force Full Composition Pipeline.

Ihr seht die Optionen nicht?

Das hat natürlich Gründe. Zunächst mal braucht es eine minimale Treiberversion 375.26, zum Anderen eine Grafikkarte, die den Modus überhaupt unterstützt. Eine GT840M z.B. hat das nicht, egal welche Treiberversion Ihr habt.

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.