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.

Wenn sich Grub und Grubby uneins sind

Ihr erinnert Euch noch an den Artikel Fedora 30&31 Bootumstellung führt zu Startproblem? Davon habe ich eine neue Version für Euch 🙂

Wenn sich Grub und Grubby uneins sind

Allen Anfängern rate ich jetzt mal zunächst ein bisschen zu Lesen: Grubby: wie man wieder einen Default Kernel setzen kann damit dürfte klar sein, was Grubby macht. Grub ist der verbreiteste Bootloader für Linux und der liest normalerweise das ein, was Grubby so von sich geschrieben hat. Wenn ich das schon so flapsig schreibe, dann kann das ja eigentlich schon nicht stimmen, tut es auch nicht immer 🙂

Fangen wir mit der Geschichte von vorn an …ää ähm .. ä ..hm… es war mal im Jahr 2019 ein Fedora Releasewechsel von Fedora 29 auf 30, und ein Linux Tablet. Ok,ok, mein Tablet war zwar an der Geschichte beteiligt, aber das hätte jedem PC passieren können, ehrlich 😉 Mit Fedora 30 wurde ja BLS eingeführt und dabei muß jemand an Grub geschraubt und was falsch gemacht haben, denn bis zu dem Upgrade lief das mit dem Setzen des Default Kernels über Grubby noch.

„Ihr wagt es mir zu trotzen, wer seid Ihr Ritter Rosthülle!“

Seit dem Update konnte ich machen was ich wollte, es wurde immer der erste Kernel in Menü als Bootkernel ausgewählt, egal was ich mit Grubby angestellt habe. Zu beachten ist hier, daß immer alle aktuell installierten Kernels im Menü aufgetaucht sind. Nun habe ich ja für den Beitrag zum neuen Surfacekernel Repo einen, wer würde es erraten, neuen Kernel installiert \o/ und prompt bootete der nicht automatisch. Da ich aber sicher gehen wollte, daß der immer startet, habe ich da nochmal alles überprüft.

Die Dateien in /boot/grub2/ waren alle OK. Wenn Grubby gehustet hat, änderten sich die grubenv und die grub.cfg untertänigst und trotzdem blieb es beim ersten Kernel im Menü. Unglaublich. Jetzt kann man glücklicherweise im Grubmenü auf „c“ drücken und kommt in die GrubShell. Wenn man da „set“ aufruft, zeigt er einem die Grubvariablen an, das sind die, die man mit dem Eintrag in der grubenv überschreiben kann. Wenn man sich die grub.cfg ansieht:

if [ -f ${config_directory}/grubenv ]; then
    load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
    load_env
fi

erkennt man auch als Uneingeweihter, daß hier die grubenv geladen werden soll. d.b. Schritt Eins vom Bootloader, bevor das Menü überhaupt zusammenbaut wird, ist also die grubenv laden und die passenden Variablen setzen oder überschreiben.

Die GrubShell

Wie bereits erwähnt kann man sich das Ergebnis in der GrubShell ansehen, wenn man „set“ eingibt. Solltet Ihr beim nächsten Boot einfach mal machen und reinsehen. „boot“ oder „reboot“ bringen Euch da wieder raus. Als ich heute (für Euch vor 2 Wochen) in die Variablenliste von „set“ sah, wäre ich fast vom Stuhl gefallen. Da stand allen ernstes ein Kernel 5.2.7 (Fedora 29) als Defaultkernel drin! Den gab es unter /boot/ aber gar nicht mehr und das System hat nur eine Bootplatte. Ich habe ja erwähnt, daß alle Kernel, die hätten im Menü sein sollen, auch im Menü drin waren. Ein Kernel 5.2.7 wäre da aufgefallen.

Jetzt sucht mal auf der Platte nach einem Kernel, den es seit 5 Monaten nicht mehr gibt, viel Spaß dabei! Das muß ja irgendwo drin stehen, also /etc/ durchsucht, /boot/grub2 durchsucht, /usr/ durchsucht, nichts! Kein Kernel, kein Eintrag.. wo zum Geier kommt das her? Grubby schreibt doch jede Änderung des Kernels direkt in die Files, da KANN DOCH GAR KEIN ALTER KERNEL DRINSTEHEN!

Wenn A und B nicht das Gleiche sind!

Stands auch nicht. Die Lösung für das Problem war dann weniger spannend als die Suche danach 🙂 Grubby änderte die Dateien in /boot/grub2, aber Grub lud nicht /boot/grub2 sondern /boot/EFI/efi/fedora/ und da standen uralte Fedora 29 Sachen in den Dateien. Das ist so eine „Links weiß nicht was Rechts tun“ Geschichte. Die Lösung für das Problem ist dann ganz einfach, man nimmt einfach zwei Symbolische Links und verknüpft die beiden Orte, so daß es nur noch eine Datei mit dem Inhalt gibt, und nicht mehr zwei verschiedene.

Da Grubby alle aktuellen Anpassungen nach /boot/grub2/ schreibt, aber Grub aus /boot/EFI/efi/fedora/ liest und zu allem Überfluß /boot/ zu „/“ wird, wenn man der Bootloader ist, muß man ein klein bisschen kreativ werden, um den korrekt Pfad für den Link abzuleiten. Folgende Anweisungen können das für Euch direkt lösen:

mv /boot/grub2/grubenv /boot/EFI/efi/fedora/grubenv
mv /boot/grub2/grub.cfg /boot/EFI/efi/fedora/grub.cfg
cd /boot/grub2
ln -s ../EFI/efi/fedora/grubenv
ln -s ../EFI/efi/fedora/grub.cfg

Kurz erklärt

„mv“ steht für „move“ und verschiebt Dateien von A nach B. Wenn B vorhanden, wird es überschrieben, man muß B also nicht vorher löschen.
„ln -s {Pfad/Dateiname}“  legt den symbolischen (-s) Link von {Pfad/Dateiname} als „Dateiname“ im Filesystem an. Sollen Ziel und Quelle des Links gleich heißen muß man da nichts weiter angeben. Üblich wäre aber z.B. „ln -s pfad1/datei1 pfad2/datei2“ . In den Anweisungen oben haben wir einen relativen Pfad ../EFI/efi/fedora benutzt, weil /boot/EFI/efi/fedora nicht geht, da es /boot/ in der Bootparition nicht gibt, denn die wird während des Bootens erst später unter /boot/ eingehängt. Der Bootloader hantiert also direkt im /boot/ rum, weswegen in seinem Kontext „/boot/“ = „/“ ist. Das Root = / ist hätte man riskieren können, aber da Grub nicht von /boot/grub2 lädt, könnte da ja noch viel mehr anders sein, als mir jetzt bekannt ist. Daher war der relative Link hier sicherer als „ln -s /EFI/efi/fedora/grubenv“ zu benutzen.

Für Anfänger: Ein symbolischer Link ist eigentlich nur eine kleine Textdatei, wo das Ziel ( hier ../EFI/efi/fedora/grubenv ) drinsteht. Das Filesystem merkt das, und folgt dann dem Pfad zum eigentlichen Ziel. Symbolische Links kann man quer über alle eingehängten Partitionen benutzen. „Hardlinks“, die sich hier auch angeboten hätten, kann man nur innerhalb einer Partition benutzen, dafür haben die andere Vorteile.

Bugreport ist raus, mal sehen wann die Beule am Kopf der GrubDevs vom gegen die Wand schlagen wieder abgeschwollen ist 🙂

Linux: Surface Tablets und Laptops mit eigenem Kernel-Repo

„Du saga mal, Du hascht doch des Suuhrfaze, gibtsch da scho wos njeues pführ?“ hallte es aus dem mitfünfziger Herrn am Tisch gegenüber. Freundlich, aber bestimmt, machte Ihm mein Sitznachbar darauf aufmerksam, daß er kurz hinter Kiel wäre und folglich kaum zu verstehen sei. Dies schien den Herrn genauso wenig zu stören, wie der Umstand, daß mein Sitznachbar eher andigital veranlagt ist und es sich bei dem Gerät vielmehr um eine kurz Präsentationsleihgabe meinerseits handelte.

Nachdem die beiden Fischköpfe ( wir… vermutlich ) kurz getuschelt hatten, übersetzte eine junge Dame (Bezeichnung Anna-Luisa o7) für uns (daher auch die grobe Entschlüsselung oben) und es entstand eine schöne , wenn auch sehr kurze, Unterhaltung zum Thema: Linux auf einem Surface Pro 4.

Surface Tablets und Laptops mit eigenem Kernel-Repo

„Ja, da gibts was njeues.. ehm.. neues“ und für Euch schalte ich das Gespräch mal auf Allwissenden Erzähler um, sonst darf ich mich in Bayern gar nimmer sehen lassen. Also, Ja Leute, es gibt eine nicht mehr ganz taufrische Entwicklung, die teils sehr erfreulich, weil unheimlich praktisch ist, andererseits leider nicht so ganz funktioniert. Letzterer Teil wird derzeit noch untersucht.

Seit einige Monaten gibt es im Github einen eigenen Prebuild-Kernel für Arch, Debian und Fedora. Den richtet Ihr Euch so für Fedora ein:

  1. Das Repo hinzufügen:

sudo dnf config-manager --add-repo=https://pkg.surfacelinux.com/fedora/linux-surface.repo

2. Den Kernel  installieren:

sudo dnf install kernel-surface surface-firmware surface-secureboot
sudo dnf install --allowerasing libwacom-surface

3. Letztere Anweisung ist eher optional, falls man mit Wacom Probleme hat., was auch die Stifteingabe betrifft.

Surface rebooten, den neuen Kernel auswählen und jetzt kommt es drauf an, ob Ihr ein SP4/SB1 habt oder ein anderes Surfacegerät Euer eigen nennt, denn bei mir (SP4) bootet der Kernel zwar sauber, aber IPTS ist nicht da, was man allerdings für Touchbedienung braucht.  So bin ich kaum einen Schritt weiter als mit dem Kernel von Fedora selbst. Ein Problem an dem derzeit gearbeitet wird.

Und da ist auch schon die Lösung … ( sowas von genial den Artikel schon Tage im Voraus zu schreiben 😀 ) … dem mangelnden Touchsupport kann man so begegnen:

[root@surface]# rmmod ipts
[root@surface]# insmod /lib/modules/5.5.8-1.surface.fc30.x86_64/kernel/drivers/input/touchscreen/ipts/ipts.ko.xz singletouch=y

Was man dann so verewigt:

echo „options ipts singletouch=y“ > /etc/modprobe.d/ipts.conf

Man muß aber wissen, das dann der Stiftsupport abgeschaltet ist. Außerdem ist im 5.5er Kernel die Multitouch-Support komischerweise abgeschaltet, wer das braucht, muß den LTS Kernel 4.19 installieren. Ob das bei einem aktuellen Fedora 30/31/32 eine gute Idee ist, mag ich nicht entscheiden wollen. Allerdings hatte der 5.3er noch Multitouch dabei. Da frage ich mich jetzt, wieso das abgeschaltet wurde.

Weniger Energieverbrauch .. vielleicht

Eine andere Sache, die noch untersucht werden muß, ist der anscheinend geringere Stromverbrauch des 5.5.8 Kernels auf dem Surface Pro 4. zunächst sah es eher nach einem Batteryauslesebug aus, weil das Gerät lange auf 100% blieb, aber mittlerweile könnnte auch ein leichter Einspareffekt vorhanden sein. Ich hab das SP4 noch nicht lange genug im Referenzkernel laufen lassen, um da einen Vergleich zu haben. Ich schau nachher mal.

Kameras gehen immer noch nicht

Tja, schlechte Nachrichten für die NSA, die Kameras der Surface Pro 4+ funktionieren immer noch nicht unter Linux, was an sich jetzt schade für reguläre Kameranutzer ist. Dafür soll das Wifi jetzt im 5G Betrieb stabiler sein, was ja auch nicht ganz unpraktisch ist.

Die Sache mit dem Secure Boot

Nachdem ersten Boot, kommt im Bootprozess eine mördermäßig wichtige Einblendung, die einem bei der Installation auch mitgeteilt wird, allerdings steht im Installationshinweis, daß man, WENN MAN danach gefragt wird, ein Password eingeben soll um den signierten Kernel, bzw. dessen Signatur, ins Bios zu bekommen um dann Secure Boot nutzen können. Tja, was soll ich sagen, die Abfrage kam so nicht, denn dazu muß man während ein Timer runterzählt auf eine Taste drücken, sonst wird man auch nicht nach dem Passwort gefragt 🙂

Da ich da noch unsignierte Kernels zum Testen liegen habe, kann ich SecureBoot eh nicht einschalten, insofern ist mir das auch egal 😉 Wenn der neue Kernel natürlich dauerhaft funktioniert, dann kann man das später immer noch mit Hilfe des mokutil erledigen.

Der TypeCover Bug

Zwar prellt das TypeCover nicht mehr, aber dafür funktioniert es auch nicht mehr, wenn man es abzieht und wieder dran steckt. Was ein Problem darstellt, da man das Surface Pro 4 neu booten muß.

Ihr seht, da werden noch einige Fixe nötig werden, bis das stabil läuft.

Kernel <= 5.5.9 mit USB Bug

Besonders für alle Fans von  Surface Pro Linux-Tablets habe ich eine schlechte Nachricht im Bezug auf den Kernel 5.5.8: einige USB Geräte werden nur beim Booten erkannt, später aber nicht mehr.

Kernel <= 5.5.9 mit USB Bug

Die Liste der betroffenen Geräte dürfte bislang eher übersichtlich sein, da z.B. meine USB Maus oder mein USB Gigabit LAN Adapter  von dem Problem nicht betroffen sind. Über die Ursache ist bislang auch noch nichts bekannt, was aber nicht verwundert, da wir das erst heute Vormittag verifiziert bekommen haben.

Was ist denn überhaupt los?

Wenn man das Gerät mit Kernel 5.5.x bootet, wird das Microsoft eigene TypeCover, das ist die Tastatur und das Mauspad, welches auch als Deckel dient, korrekt als USB Device erkannt und funktioniert entsprechend. Allerdings nur so lange, bis jemand das TypeCover abzieht und wieder dransteckt. Dann funktioniert es nicht mehr.  Dabei ist es egal aus welcher Quelle man den Kernel hat, ob er direkt von Fedora oder selbst gebaut ist.

Wie wirkt sich das aus?

Die Ursache dafür, daß das TypeCover nach dem Einstecken an das Gerät nicht mehr funktioniert ist, daß es überhaupt nie vom USB BUS abgemeldet wurde. Das manifestiert sich darin, daß man mit „lsusb“ das Gerät noch sieht, auch wenn es bereits am anderen Ende der Wohnung liegt. Folglich wir es beim Einstecken nicht initialisiert und kann so seinen Job nicht tun.

Gegenmaßnahmen

Wie schnell so einn Satz wie „Derzeit hilft nur ein Reboot.“ obsolete wird. Der Einsatz von Kernel 5.5.9-200 (Upstreambuild) oder 5.4.19 bzw. jedes anderen 5.4er Kernel ohne Sicherheitslücke löst das Problem auch, weil es da nicht auftritt. Somit wurde auch indirekt bestätigt, daß es nur am Kernelcode liegt und nicht an der Installation oder irgendwelchen UDEV Tricks, die sind bei allen Kernels gleich, weswegen man die aus der Gleichung streichen kann.

Der Nachteil beim 5.4.x Kernel ist allerdings, daß er zu viel Strom verbraucht. Es wurden im Leerlauf 12 W gemessen, wo mit einem für Surface gebaute Kernel nur ~5 W verbraucht werden. Das sich das echt fies auf die Laufzeit auswirkt, dürfte jedem klar sein.

Die derzeit im Test befindliche 5.5.9-100 von Fedora löst das Problem noch NICHT.

Update ( 11:55 Uhr )

Wie das so mit Eilmeldungen ist, der Patch in 5.5.9-2 ist nicht stabil. Ein einem Boot funktioniert USB wieder, im anderen nicht. Ich halte Euch auf dem Laufenden, wenn ich was neues erfahre.

 

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.

Grubby: wie man wieder einen Default Kernel setzen kann

Ihr habt ein Kernel Update eingespielt bekommen, aber der Default-Kernel ist immer noch der „alte“ Kernel? Willkommen in der digitalen Steinzeit der Grubby Bugs.

Wie man einen Default Kernel setzen kann

Per Mail erreichte mich eine Anfrage zu Grubby, das ist das kleine Tool, das sich um die Grub Booteinträge kümmert. In der Anfrage ging ein Kernel-Update schief und der Default Kernel lies sich nicht setzen. Die Ursache liegt in einem „Steinzeit“-Fehler: Der Grubenv Block ist wie in Stein gemeiselt genau 1024 Bytes lang, egal was sinnvolles drin steht 🙂

Jetzt ist der Bug an sich nichts neues, da reden der Redhat Support, die Fedora Maintainer und die Grubby Devs gefühlt schon eine Ewigkeit drüber. In etlichen Bugreports gibt es einen gemeinsamen Nenner: Grubby und nicht 1024 Bytes große grubenv Dateien 🙂

Wenn man jetzt versucht einen Default-Kernel zu setzen, kann man Opfer dieses Bugs werden und keiner sagt es einem, außer der schon gehässigen Regelmäßigkeit, mit der der alte Kernel gebootet wird. Beispiel:

[root@eve]# grubby --default-kernel
/boot/vmlinuz-5.2.7-100.fc29.x86_64
[root@eve]# grubby --set-default=/boot/vmlinuz-5.2.11-100.fc29.x86_64
[root@eve]# grubby --default-kernel
/boot/vmlinuz-5.2.7-100.fc29.x86_64
[root@eve]# cat /boot/grub2/grubenv
# GRUB Environment Block
saved_entry=Fedora (5.2.7-100.fc29.x86_64) 29 (Twenty Nine)
"

[root@eve#

Die Methode mit der man den Kernel als Default setzen will, spielt dabei keine Rolle:

[root@eve]# grubby --set-default-index=0
grub2-editenv: Fehler: Environment-Block ist zu klein.

Aber immerhin gibt es hier den Hinweis, der Block ist zu klein? Wie kann das sein, da steht doch min. der ALTE Kernel auch drin, wie kann der sich nur durch eine Nummer unterscheidene neue Kernel da nicht auch reinpassen?

Weil da wer von Hand rumgefummelt hatte …

Ja, ich gebs zu, ich habe mal irgendwann den Kernel von Hand da eingetragen, aber das war noch zu 4.20er Zeiten und seit dem gings doch auch, sonst wärs ja nicht 5.2.7 geworden. Die mögliche Antwort ist wenig schmeichelhaft: Grubby ist nicht ganz deterministisch veranlagt in letzter Zeit. Ich erwähnte ja, daß sich die Devs und Maintainer schon länger damit rumquälen, mal gehts, mal gehts nicht mehr. Die Bugreporter sind entsprechend genervt. Die Codebasis von Grubby will ich wohl besser nicht sehen.

Egal, eine Lösung muß her

Also, Ursache ist, daß Grubby nur dann das File erzeugt, wenn es GENAU 1024 Bytes lang ist. Keine Ahnung wieso und ich will es auch nicht wissen…. doch will ich, aber werde ich wohl trotzdem nie erfahren.

Sofern nichts außer dem Kernel in dem grubenv File steht, ist der Fix besonders einfach:

wahlweise mit EFI oder ohne :

rm -f /boot/grub2/grubenv
rm -f /boot/efi/EFI/fedora/grubenv

und dann den Block neu erzeugen lassen:

grubby –set-default-index=0

Fixed. Kniffliger wird es, wenn da noch andere Variablen drinstehen, denn dann dürft Ihr ungelogen mit einem Texteditor die Datei auf genau die 1024 Bytes trimmen/padden und dann abspeichern. Danach sollte grubby auch wieder den Default-Kernel da rein schreiben können.

Achtung:

ggf. sind /boot/grub2/grubenv und /boot/efi/EFI/fedora/grubenv  durch einen Symlink verbunden, schaut Euch das bitte vorher von Hand an, bevor Ihr Euch in Sicherheit wiegt. Es ist Eure Bootconfiguration, also lasst Vorsicht walten 😉 Bei Fragen, welche Datei zuständig ist, wendet Euch an die örtliche LUG, die freuen sich über Zulauf 🙂

Fedora 31: keine i686 Kernels mehr?

Die Schlacht um i686 geht in die nächste Runde, kaum das Ubuntu zurück gerudert hat bzw. sich da noch windet, schlagen die ersten bei Fedora in die gleiche Kerbe: Keine i686 Kernels mehr.

Keine i686er Kernels mehr für Fedora 31+

Ben Cotton hat dazu geschrieben:

On Fri, 21 Jun 2019 at 14:15, Ben Cotton <bcotton@redhat.com> wrote:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

== Summary ==
Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.

Anders als bei Ubuntu sollen alle Supportpakete weiterhin gebaut werden, so daß Wine keine Probleme machen würde, man könnte halt nur keine 32Bit Systeme mehr mit einem neuen Kernel booten und dann in Folge irgendwann gar nicht mehr, weil der Kernel zu dem ganzen Boot/Init des Systems ja in nicht unerheblichen Teilen beiträgt.

Früher oder später war der Schritt ja zu erwarten. Das wenigsten die 32Bit RPMs weiterhin gebaut werden, damit 32 Bit Anwendungen auch unter 64 Bit  funktionieren, ist ein Lichtblick, außer für Besitzer von 32 Bit Systemen.
Ein Wine ohne 32 Bit wäre für viele User ein absolutes No-Go, weil zig alte Windowsgames auf 32 Bit laufen!

Zu viel Drama um die TCP SACK Problematik

Um dem Drama mal den Schwung aus den Segeln zu nehmen:

sudo echo „0“ > /proc/sys/net/ipv4/tcp_sack

auf den gefixten Linux Kernel warten, rebooten, fertig. Wer keinen neueren Kernel bekommt, trotzdem rebooten muß, der fügt :

net.ipv4.tcp_sack = 0

ans Ende der Datei /etc/sysctl.conf an und schon wird SACK beim Start deaktiviert.

Ich könnte natürlich jetzt auch son Quatsch von mir geben wie :

„Ooohhh! Große Lücke im Kernel! Linux Server werden durch DDOS vom Netz genommen! Panik! Ich sagte PANIK! P.A.N.I.K!!!

blöderweise passierte … rein gar nichts davon 😀

Das jeder seinen Krempel mittlerweile nur noch über den Panikbutton vermarktet, macht es echten Lücken, wie der Exim Root-Exploit Geschichte neulich nicht einfacher. Oder dem Firefox Exploit über Javascript! Was fürn Geheul, und ooooooohhh … zwei Tage später der nächste Security Patch… auch wieder alle im Panikmodus. NOSCRIPT installieren und schon ist Ruhe!

Redhat hat 2 Tage gebraucht den FireFox 67.0.3 zu kompilieren, bevor es endlich mal durchlief und ? Juckt das NOSCRIPT User? Nein 🙂

PS: Wer es für Fedora eilig hat mit dem FF Update : https://koji.fedoraproject.org/koji/buildinfo?buildID=1291078

 

Runes of Magic, Linux und der Performance Bug

Ihr könnte Euch gaaaaaaaaaaaaaaanz sicher an die Intel CPU Bugs erinnern und wie die im Linux Kernel abgewehrt wurden, so in etwa. Der Nebeneffekt war, u.a., daß bspw. Runes of Magic als WineApp mit DX9 Teil auf meinem  Achtkerner von im Durchschnitt 150% CPU Last pro Instanz auf 250% hochgeschnellt war. Die Kernels 4.19.9+ > 4.20.latest waren allesamt davon betroffen.

66% mehr CPU Last

Das Phänomen war besonders nervig, weil zwar im Regelbetrieb nur eine leichte Erhöhung von 150% auf 180% vorhanden war, aber sporadisch brach die Lasthölle los, mit den erwähnten Peeks auf 250%, die dann für einige Minuten blieben um dann wieder zu verschwinden. Ein Spielen war so natürlich nicht mehr mit mehreren Instanzen möglich.

Seit Kernel 5.0.6 und vermutlich auch eher, ist die Last wieder zurück auf den Normalwert von 150% im normalen Spielbetrieb. Die Reaktion vom Kernel bzw. Wine Maintainer auf diesen Bugreport war übrigens „Damit können wir nichts anfangen“ mit anderen Worten, sie konnten nicht mal glauben, daß es den Effekt überhaupt gab.

top – 13:11:29 up 1 day, 3:52, 1 user, load average: 4,09, 4,31, 4,87
PID   USER   PR NI VIRT   RES    SHR   S %CPU %MEM TIME+ COMMAND
3542  marius 20 0 2240024 1,238g 76976 S 155,8 7,9 1159:15 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion20398 marius 20 0 2378776 1,291g 78152 R 142,2 8,3 1369:03 H:\Programme\GameforgeLive\Games\DEU_deu\Runes Of Magic\Client.exe NoCheckVersion

Da die Last seit einiger Zeit wieder konstant im grünen Bereich ist, kann man das Problem wohl als gelöst betrachten. Falls jemand von Euch mit einem Programm unter Linux ähnliche Erfahrungen gemacht hat oder derzeit macht, wisst Ihr was die Lösung ist => Kernel Updaten.

Bevor Klagen von Lesern reinkommen: klar hatte ich überprüft, ob sich Wine oder die Grafikkartentreiber geändert hatten, hatten sie nicht.

XenServer zu alt um Kernel 5.0 zu laden

Wer XenServer und Kernel 5.0.x einsetzen will, sollte jetzt gut aufpassen, sonst => VM Streik

Kernelimage zu neu für XenServer 6.2.x

Da es sich um etwas handelt, daß international wichtig sein könnte, gibts das auf Deutsch und English,
so don’t wonder if you just understand halve of it 😉

Ihr wollt Eure VM booten, bekommt aber diesen Fehler?
You wanne boot your VM and get this message ?

xenopsd internal error: XenguestHelper.Xenctrl_dom_linux_build_failure(2, “ panic: xc_dom_core.c:616: xc_dom_find_loader: no loader\\\““)

Das passiert, weil das Kernelimage mit einer neuen Compressionmethode gepackt wurde, die das alte XEN nicht kann.  The reason is, that your kernel image file is compressed with a new algorithm, your old XEN can’t handle.

Als erstes brauchen wir die UUID der VM:
First, get the UUID of your VM:

xe vm-list | grep -A5 -B5 <vmname>

Um das zu beheben, braucht man den Befehl: xe-edit-bootloader.sh -u uuid
To fix your vm, you need to execute : xe-edit-bootloader.sh -u uuid

/root/xe-edit-bootloader.patched.sh -u 317fb132-283a-56c6-1627-8b39cf944148 -p 1

Nun kann man die Reihenfolge der Bootmenüeinträge so ändern, daß der bisherige Kernel vorn steht. Dann speichern und Editor beenden und jetzt sollte die VM auch wieder starten.
Now you can change the order of your grub menuentries to the last working kernel being first. When you have saved and exited the editor, the parition will be unmounted and you can start your VM again.

Tipps – Additional hints for you

Der Befehl mountet die Systemplatte der VM und lädt die gebräuchliste grub.conf. Das wird aber vermutlich nicht auf anhieb klappen. Man muß etwas über das Festplattenlayout der VM wissen:
This will mount your VM’s main disk and access the most likely location of your grub.conf, but that will not work without your knowlage of the VMs structure:

-p: Partition number to mount (default: none)
-f: Location of bootloader config file to edit

Wenn man eine traditionelle SDA1 SDA2 Partitionierung in der VM hat, dann gibt man -p die Partitionsnummer der Platte an, wo man /boot/ finden kann. Wer LVM in der VM benutzt, dürfte jetzt so ziemlich am Arsch sein. Kleiner Tip, exportiert die VM auf einen neuern XenServer.

If you have a sda1 and sda2, where sda2 is swap, that -p 1 will mount partition 1 and your good to go.
If you have i.e. a seperate boot partition, you need to know it’s number.
IN CASE you have LVM inside your VM, i guess your screwed now. In this case, export it to a newer XenServer Version.

Weil sich Grub1+2 ein bisschen uneinig wegen der Verzeichnispfade sind, kann man Position der grub.cfg mit -f angeben. Wer eine eigene /boot Partition hat, braucht dann nicht /boot/ hinschreiben, -f grub2/grub.cfg reicht.

Grub1+2 differ a bit, where to find the grub.conf file. Thats where -f will be handy. You can just tell it, if you knew it: -f /boot/grub2/grub.cfg   should usally work, except, you are already on /boot (seperate partition) then it’s just -f grub2/grub.cfg .  As theres only a texteditor loaded, you could try to change other files too 😉

Ich habe einen gepatchten xe-edit-bootloader, der mir erlaubt, gleich die ganze Platte in Dom0 zu mounten. d.h. ich kann alles in der VM anpassen, nicht nur Textdateien, was extrem praktisch ist.
Why is my xe-edit-bootloader.sh  patched? because i adapted it to just mount the disk and wait for me to explore the disk. That’s so helpfull, you won’t believe it.

Bei einigen Systemen kann durch setzen der $EDITOR Variablen auf „/bin/bash“ eine Shell bekommen, aber ich rate davon ab, daß auf Produktivsystemen auszuprobieren, das könnte böse Nebenwirkungen haben.
In rare cases it’s possible to trick the script with the $EDITOR variable set to „/bin/bash“ to open a bash shell for you, but i really suggest not to mess with your dom0 on a production system.