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.