Tag Archives: fedora

Fedora: Kernel 6.1.5 & 6.2.0.alpha ohne Nvidia Grafikkartensupport

Posted on by

Wer eine Nvidia Grafikkarte im PC hat und von Fedora die aktuellen Kernel 6.1.5 bis 6.2.0.alpha booten will, erlebt nur einen schwarzen Bildschirm. Die Ursache ist menschlich, aber uncool.

Fedora: Kernel 6.1.5 & 6.2.0.alpha ohne Nvidia Grafikkartensupport

Egal ob Fedora 36 , 37 oder Rawhide, die derzeitigen Kernel booten einen PC mit Nvidiagrafikkarte zwar, aber man hat leider kein Bild mehr. Wie Leight Scott recht schnell rausgefunden hat, haben die Kernelmaintainer entweder vergessen den EFIFB Support nicht mit einkompiliert, was das VT Switching unmöglich macht, oder es absichtlich abgeschaltet.

Dominik ‚Rathann‘ Mierzejewski fand dann heute morgen die Ursache in der zugrundeliegenden Kernelconfig bestätigt:

2023-01-16 07:35:53 UTC :

On F37, I can see this:
$ grep FB_EFI /boot/config-6.0.15-300.fc37.x86_64
CONFIG_FB_EFI=y
$ grep FB_EFI /boot/config-6.1.5-200.fc37.x86_64
# CONFIG_FB_EFI is not set

So, Scott is right.

Leight Scott’s eigentliche Aussage ist aber weniger schön, denn das passierte offensichtlich nicht zum ersten mal:

leigh scott 2023-01-15 22:40:53 UTC

VT switching is broken.

It looks like the kernel devs have forgotten to compile efifb support for 6.1.x stable release again! 🙁

Wie sich (sprichwörtlich) gerade eben herausgestellt hat, ist auch der VESA Support im Kernel 6.1.5 von Fedora abgeschaltet worden:

6.1.5:

# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
# CONFIG_FB_EFI is not set

6.0.18:

# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set

Die einzig entscheidende Frage ist, ob es die Maintainer im Fedoraprojekt übersehen haben, oder ob das als ‚Vorgabe‘ von kernel.org kam.Bis das behoben ist, müßt ihr lediglich einen alten Kernel in Grub auswählen, wenn Ihr das noch könnt.

What is efifb?

This is a generic EFI platform driver for systems with UEFI firmware. The system must be booted via the EFI stub for this to be usable. efifb supports both firmware with Graphics Output Protocol (GOP) displays as well as older systems with only Universal Graphics Adapter (UGA) displays.

Quelle: https://www.kernel.org/doc/html/latest/fb/efifb.html

 

Leider schafft es grubby nicht mehr, den Defaultkernel so zu setzen, daß der durch BLS auch wirklich geladen wird. Im BLS versucht man zu erkennen, welcher Kernel erfolgreich geladen wird und sollte das scheitern, wird automatisch ein anderer genommen. Funktioniert hat das bei mir jedenfalls noch nie und jetzt auch nicht, weil der Kernel per se bootet, man kann sogar in Runlevel 3 kommen, nur sieht man nichts, aber das zählt halt nicht als Boot-Fail 😉

Update 14:44 Uhr

Im entsprechenden Bugreport ist eine hitzige Diskussion im Gange über das warum, und es war doch Absicht. Eigentlich sollte das schon zum Start von Fedora 36 passieren, weil glatt jemand dachte, er könnte Nvidia dazu zwingen seine Prop Treiber apimäßig zu aktualisieren. Das das voll nach Hinten losgehen würde, so wie es das jetzt tut, war ja eigentlich klar.

Was wird passieren, wenn Fedora Kernel den Support für Nvidia Karten einstellt? Na was wohl?  „Format c:\“ natürlich,  um mit einer Windowsmetapher zu arbeiten 😉 Da sucht man sich eine Distro, die das unterstützt und Fedora verliert 1/3 seiner User, wenn nicht mehr. Es gibt ja schliesslich nur 3 Hersteller.

Fedora und das Packagekit Offline Update

Posted on by

Vor einigen Releases hat Fedora ein neues Updateverhalten via Packagekit eingeführt, das verdächtig nach „Windows macht das auch so“ stank. Wie grottig das wirklich laufen kann, kommt unten in Bild & Schrift.

Fedora und das Packagekit Offline Update

Um es gleich mal vorweg zu schicken: Ich bin pro Fedora und achte das, was die da auf die Beine stellen.

Aber nur weil man es mag, muß man nicht mit allem einverstanden sein und die Änderung des Updateverhaltens durch Packagekit’s „Offline Update“ ist eine der Sachen die ich nicht unterstützen kann. Damit Ihr Euch ein Bild von der Sache machen könnt, habe ich da mal was abgelichtet.

Ich bitte die schlechte Bildqualität zu entschuldigen, aber Screenshots sind an der Stelle im Bootvorgang nicht vorgesehen 😉

Gestern

Gestern war ich mit meinem Surface bei einem Kunden. Während ich da gearbeitet habe, hat sich Packagekit mit Updates versorgt, diese aber nicht eingespielt. ich hab es nur gemerkt, weil ich das Bandbreitenwidget im Gnome habe, das plötzlich hektisch aktiv wurde.

Heute morgen

schalte ich mein Tablet ein, weil ich für den nächsten Artikel was testen wollte. Es kommt die Kernel Auswahl, es kommt die Passwortabfrage für LUKS und dann passiert es:

Bitte fahren Sie den Computer nicht runter!

Größtenteils weiß man nicht mal, was da aktualisiert wird.

Es lief ein Offline-Update von Packagekit 🙁 Nicht 10 Sekunden, nicht 30 Sekunden, nicht eine Minute, nicht fünf Minuten, nein, für knappe acht Minuten war das Geräte vollständig blockiert. Weil ein neuer Kernel installiert worden war, mußten auch alle AKMOD Module für alle Kernels neu gebaut werden. Und dann … gingen die Lichter aus und blieben aus.

Achtet mal auf die Zeiten vom packagekit-offline-update.service

Anstatt das Update einzuspielen und durchzubooten, wurde das Tablet danach einfach abgeschaltet. Kommentarlos übrigens 🙁

Wie Ihr oben in den Bildern und hier sehen könnt:

wird einem nicht mal erzählt, was da aktualisiert wurde. Ab und zu blitzt mal ein Name durchs Display, aber das wars dann auch schon.

Per DNF aktualisiert, gibt es ein Logfile, in dem ganz genau drin steht, wann was von welcher Version auf welche neue Version aktualisiert wurde. Da DNF das Update nicht gemacht hat, ratet mal …

Natürlich gibt es von PackageKit auch einen Logeintrag. Den kann man sich aber so nicht ansehen, weil man dazu den GPK Logger aufrufen muß: gpk-log

Das ist ultimativ toll, wenn man von dem Tool noch nie etwas gehört hat, oder? Ein grep über /var/log bringt einem nämlich nur die Einträge von DNF, die zum Packagekit Paket gehören, wenn DNF das updated 😀

Die Krönung des Ganzen

war dann der Umstand, daß ich sowieso noch ein Update vorhatte, um den neuen Surfacekernel einzuspielen. Dazu mußten einige alte LUA Paket entfernt werden, damit das Update überhaupt stattfinden konnte. Als dann das Update endlich ging, war schon wieder ein neuer normaler Kernel verfügbar, der dann natürlich auch alle Kernel-Module neu bauen mußte.

Fazit

Das offline-update ist in diesem Fall lästig und überflüssig gewesen, weil beim nächsten Start schon neue Pakete zur Verfügung standen. Der Sinn und Zweck davon, es beim BOOTEN durchzuziehen, erschließt sich ohnehin nicht, weil für ein Kernelupdate die Kernelmods neugebaut werden müssen und damit die dann auch benutzt werden, muß man ohnehin rebooten, was „Packagekit Offline-Update“ dann ja auch, mit wenig Erfolg, gemacht hat.

Da kann man es doch auch gleich beim Runterfahren installieren, oder??? Dann kann man am nächsten Tag wenigstens sofort arbeiten.

Lösung

Wie bekommen wir das weg?

systemctl disable packagekit packagekit-offline-update
systemctl mask packagekit

„Wir sehen uns wieder, wenn Du wieder vernünftiger geworden bist.“ Denn natürlich gibt es einen Grund, wieso man nicht einfach so GB!weise Daten zieht, nur weil man eine Internetanbindung hat.

 

Surface Pro 4 – ENDLICH – Der Durchbruch

Posted on by

Ich habe mich seit Monaten mal wieder an einen Test des Linux Surface Kernels gemacht und wurde erst einmal richtig enttäuscht. Eiserner Durchhaltewille, der Züge von Besessenheit annahm, brachte dann doch noch den erhofften Erfolg 🙂

Surface Pro 4 – ENDLICH – Der Durchbruch

Ich hatte ja die Hoffnung, einen aktuellen Kernel mit Touchsupport zu nutzen, schon aufgegeben, aber die Issue-Kommentare ließen die Hoffnung aufkeimen, daß mein Sturm aus GeisterTouchs irgendwie unter Kontrolle zu bekommen sein müßte. Denn sobald ein Desktop geladen wurde, poppten wie wilde Anwendungen auf, Fenster verschoben sich auf magische Weise und ein Arbeiten war so nicht möglich.

Das Setup

Das Tablet wurde frisch auf Fedora 36 gezogen, so daß alles vorhanden ist. Der Kernel kam direkt aus dem Linux Surface Kernel Repo.

Microsoft Surface Pro 4
Linux Surface Kernel 6.0.6-1
Fedora 36
iptsd 0.51.x

Die Geister sind los

Fährt man das Setup mit dem Defaults so direkt aus, geht die Geisterparty sofort los, wenn der iptsd läuft. Der übernimmt seit Kernel 5.4 die Sache mit der Toucherkennung. Dies änderte sich auch nicht, also ich diverse Optionen in der ipts.conf aktivierte, die dies eigentlich verhindern sollten. Nach einige Stunden rumtestens, hatte ich das Gefühl, daß die Config gar nicht gelesen wurde und habe sogar mit strace nachgesehen, was der Daemon alles nachlädt.

Manchmal ist es dieser eine Schritt weiter …

und der bestand darin, das TouchThreshold sehr viel weiter hochzusetzen, als das mit dem Default von „10“ vorgesehen war. Die Sache mti dem Threshold ist, daß Klicks verloren gehen, weil die als „zu schnell“ maskiert werden. Je größer also das Threshold ist, desto kleiner ist die FTR ( FingerTipRate ), das Touchäquivalent zur FPS 😉 Das könnte zu Problemen bei Spielen führen. Aber da ich damit nicht spielen wollte, zumindest nicht via Touchbedienung, stellt das für mich jetzt nicht das Problem dar.

ipts.conf

Hier meine ipts.conf für das Pro 4, damit Ihr eine Anfangkonfiguration habt.

[Config]
TouchThreshold = 50
StabilityThreshold = 0.55

[Touch]
CheckStability = true
DisableOnPalm = false
DisableOnStylus = false

[Contacts]
Detection = advanced
TemporalWindow = 5
SizeMin = 0.3

[Cone]

[DFT]

Einmal den iptsd via systemctl restart iptsd neustarten und wir sind gut \o/

OK, neuer Kernel, aber wieso leuchtet da jetzt eine weiße LED???

Eine kleine weiße LED, die noch nie auf dem Gerät zusehen gewesen ist, leuchtete fröhlich vor sich hin. Warum leuchtet die? Wieso leuchtet da eine weiße LED, EINFACH SO??? Wo kommt die her, WAS TUT DIE DA? WARUM !?!?!?! …. Na, weil die Kamera an ist \o/

Wer jetzt dachte, das würde einfach so gehen, der kennt Microsoft nicht gut genug 😉 Wir brauchen:

libcamera + Gstreamer + v4l2loopback

Glücklicherweise ist alles im Fedora Repo enthalten:

$ dnf install libcamera libcamera-tools libcamera-qcam libcamera-gstreamer libcamera-ipa v4l2loopback kernel-surface-devel
$ akmods-shutdown
$ reboot

Hinweis: Es braucht die richtige Version der Libcamera, sonst wird es nicht funktionieren. Notfalls müßt Ihr Euch die neueste Version selbst kompilieren.

Die Kameratools brauchen wir, damit wir uns mit cam -l die Liste der Kameras ansehen können und die kann von 0-3 gehen: 0 ( geht gar nicht) , 1 Front/RearCam , 2 Front & RearCam, 3 F+R+IR Cam . Auf dem Pro 4 werden es maximal 2 , weil IR nicht unterstützt wird. Hier gibt es zu dem Thema mehr Infos.

Beispiel:

# cam -l
[0:39:24.393645034] [26937] INFO Camera camera_manager.cpp:293 libcamera v0.0.0
[0:39:24.426650022] [26942] ERROR V4L2 v4l2_device.cpp:91 ‚dw9719 3-000c‘: Failed to open V4L2 device: No such file or directory
[0:39:24.426699037] [26942] ERROR CameraSensor camera_sensor.cpp:469 ‚ov8865 3-0010‘: CameraLens initialisation failed
[0:39:24.430011690] [26942] ERROR IPAProxy ipa_proxy.cpp:149 Configuration file ‚ov5693.yaml‘ not found for IPA module ‚ipu3‘
[0:39:24.455867840] [26942] INFO IPU3 ipu3.cpp:1204 Registered Camera[0] „\_SB_.PCI0.I2C2.CAMF“ connected to CSI-2 receiver 1
Available cameras:
1: Internal front camera (\_SB_.PCI0.I2C2.CAMF)

Wozu Loopback Device?

Mit der WebCam Anwendung Cheese und Qcam kann man die Kamera über das IPA Subsystem direkt ansprechen, aber Firefox und der Rest der Apps können das nicht. Das V4L2 Loopbackdevice kann über den GStreamersupport den anderen Anwendungen die Kamera zur Verfügung stellen. Leider ist das in der Praxis alles andere als stabil.

Ich empfehle das Bild von Cheese zu streamen, das dies stabil funktioniert 😉

Damit akmods das Kernelmodul bauen kann, brauchen wir die Linux-Surface-Kernel Sourcen, mit den „normalen“ geht es leider nicht. Ich empfehle noch einen Eintrag in die /etc/modprobe.d/v4l2-loopback.conf :

options v4l2loopback video_nr=42 card_label=“virtualcam“ exclusive_caps=1

Damit wird das Modul gleich beim Booten geladen.

Wenn ich jetzt noch im Plymouth Bildschirm zum Entsperren der Festplatte ein OSK bekomme, dann erkläre ich das Surface offiziell für Feature-Complete 😉