Probleme mit i915kms.ko nach pkg update

karl_bsd

Active Member
Hallo,
ich habe ein Thinkpad T460s mit Skylake CPU und Intel HD Graphics 520. Bei uname wird '13.0-RELEASE-p7' als Version angezeigt.
Gestern wollte ich nach längerer Zeit mal wieder alle installierten Packages aktualisieren, mit 'pkg update'. Das hat auf den ersten Blick auch funktioniert, allerdings startete nach einem Neustart nicht mehr das grafische Login. Statt dessen wurde die folgende Meldung angezeigt:
KLD i915kms.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/i915kms.ko - unsupported file type

Nach etwas Recherche bin ich zu dem Schluss gekommen, dass i915kms.ko eventuell neu gebaut werden muss. Also habe ich 'portsnap fetch' und 'portsnap extract' ausgeführt, um den ports-Tree zu aktualisieren. Den Port graphics/drm-fbsd13-kmod wollte ich erstellen. Ich bin also in dieses Verzeichnis gewechselt und habe 'make install' aufgerufen. Dann erhielt ich die folgende Meldung:
Ports Collection support for your FreeBSD version has ended, and no port are guaranteed to build on this system. Please update to a supported release.

Jetzt bin ich doch etwas verwundert und da ich ja gerade zuvor den ports-Tree aktualisiert habe, weiss ich auch nicht, was ich tun soll.

Gruß
 
mmoin moin,

unter FreeBSD 13.1 gibt es:

drm-kmod-20220907_1 Metaport of DRM modules for the linuxkpi-based KMS components

das soll auch i915 unterstützen. Ist unter 13.0 das paket drm-kmod vorhanden?

VG Norbert
 
Ich würde zunächst mal auf 13.1-RELEASE hochziehen, danach graphics/drm-kmod und es sollte wieder gehen.
 
Jetzt bin ich doch etwas verwundert und da ich ja gerade zuvor den ports-Tree aktualisiert habe, weiss ich auch nicht, was ich tun soll.
Das liegt an verschiedenen Kernel-Versionen. Vergleiche die Ausgaben von:
Code:
uname -K
pkg info drm-fbsd13-kmod | grep -i version
Du hättest vor dem update (beim 13.0-R), für
Code:
drm-fbsd13-kmod-5.4.92.g20210419 is locked and may not be modified
sorgen sollen.

EDIT:

BTW: Hast Du beim update, nicht den Hinweis:
Code:
Newer FreeBSD version for package <package>:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1301000
- running kernel: 1300139
Ignore the mismatch and continue? [y/N]:
bekommen?
 
Ich habe jetzt auf 13.1-RELEASE aktualisiert - und schon geht die grafische Benutzeroberfläche wieder! :D

Was vorher noch feststellen konnte: Das Paket drm-kmod-20220907_1 war schon installiert (wahrscheinlich durch 'pkg update') aber es scheint nur für 13.1 zu sein und unter 13.0 kam die obige Fehlermeldung.
Danke für alle Anregungen!
 
nach längerer Zeit mal wieder alle installierten Packages aktualisieren
Keine Kritik, nur ein Tip: Kürzere Intervalle (2-3 Wochen werf ich mal in den Ring) für Updates verwenden, dann stolpert man über weniger auf einmal, wenn es währenddessen von version$alt zu version$neu was zum Stolpern gab. ;)

Wenn das Ignore the mismatch and continue? nochmal erscheint, dann ist was nicht in sync. Muss man dann im Detail mal schauen.
 
drm-fbsd13-kmod gibt es nicht als Package. Das gibt es nur als Ports.
Ich war zuerst der Meinung (bevor ich auf 13.1 updaten wollte), dass ich das Modul neu bauen müsste, damit es zu meinem Kernel passt. Aber durch das Update habe ich dann den passenden Kernel zum Modul bekommen.
 
Wenn das Ignore the mismatch and continue? nochmal erscheint, dann ist was nicht in sync. Muss man dann im Detail mal schauen.
Naja, in diesem konkreten Fall ist für 13.0 (mit der Kermelversion 1300139) EOL. Warum werden dann packages/Kernel-Module, die mit der bzw. für die Kernelversion 1301000 kompiliert sind, für das updaten der 13.0 überhaupt noch zur Verfügung gestellt?
Was genau meinst Du mit:
ist was nicht in sync
?
 
drm-fbsd13-kmod gibt es nicht als Package.
Bist Du dir da sicher? Warum bekomme ich dann diese Ausgaben:
Code:
:~ % pkg search drm-fbsd13-kmod
drm-fbsd13-kmod-5.4.191.g20220604_1 DRM modules for the linuxkpi-based KMS components
Code:
:~ # pkg install drm-fbsd13-kmod
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    drm-fbsd13-kmod: 5.4.191.g20220604_1

Number of packages to be installed: 1

The process will require 5 MiB more space.
1 MiB to be downloaded.

Proceed with this action? [y/N]:
 
Warum werden dann packages/Kernel-Module, die mit der bzw. für die Kernelversion 1301000 kompiliert sind, für das updaten der 13.0 überhaupt noch zur Verfügung gestellt?
Halbwissen bei mir, bin nicht brandaktuell bei der Verfolgung dabei. Bei drm-kmod ist viel Automagie/Ausnahme/Sonderfall und es wurde viel geändert. Wegen den Sonderfällen (ich kann keine benennen) ist der port wohl noch verfügbar.
Ich weiß lediglich, dass wenn man mit einem aktuellen System auf drm-kmod (metaport) geht, dass der sich im Ideafall nobrainer-style alles passend zurechtzieht.

Was genau meinst Du mit:
ist was nicht in sync
Wenn der kernel nicht die gleiche Version wie das userland hat. Passiert am häufigsten, wenn man nach freebsd-update nur einmal rebootet und dann denkt "Ok, das ist jetzt erledigt".

Edit:
Code:
mr44er@ws01:~ $ freebsd-version -kru
13.1-RELEASE-p2
13.1-RELEASE-p2
13.1-RELEASE-p2

1. Installierter Kernel 2. Laufender Kernel 3. userland
 
Wenn der kernel nicht die gleiche Version wie das userland hat. Passiert am häufigsten, wenn man nach freebsd-update nur einmal rebootet und dann denkt "Ok, das ist jetzt erledigt".
Kann sein, aber hier ist nichts mit freebsd-update (release-upgrade) gemacht worden. Mit 13.0 kam (beim pkg update/upgrade) richtigerweise bzw. rechtzeitig und oft genug der Hinweis, dass Ende August?, das EOL für 13.0 ist. Und jetzt nach dem EOL, bekommt man für 13.0 packages/Kernel-Module updatet, die für 13.1 kompiliert sind und manche (nicht alle) davon deshalb verständlicherweise mit 13.0 nicht mehr funktionieren. Sicher sollte man nach dem EOL, das 13.0 nicht mehr benutzen und schon längst auf 13.1 upgradet haben. Aber für mich wäre es "besser", wenn man jetzt für 13.0 keine updates für packages/kernel-Module bekommen würde/könnte, die für 13.1 kompiliert worden sind.
BTW: Die die u. a. auch/zusätzlich NomadBSD benutzen, sind noch auf 13.0 angewiesen, weil es ein neues image mit 13.1, warum auch immer, noch nicht gibt. Die NomadBSD-user sollten jetzt aber kein pkg update/upgrade mehr machen, aber daran halten sich nicht alle bzw. wissen es nicht besser.
 
Welchen hast du denn damals initial installiert? drm-kmod war schon auf 13.0 funktional, drm-fbsd13-kmod war vielleicht für die Anfangszeit oder -CURRENT gedacht. Da muss wer anders mit Detailwissen was dazu sagen.

Aber für mich wäre es "besser", wenn man jetzt für 13.0 keine updates für packages/kernel-Module bekommen würde/könnte, die für 13.1 kompiliert worden sind.
Da weiß ich gar nicht, ob das technisch so umsetzbar ist, trotz metaport.

karl_bsd hat ja auch explizit(?) gebaut und nicht via pkg eingespielt.
 
Welchen hast du denn damals initial installiert? drm-kmod war schon auf 13.0 funktional, drm-fbsd13-kmod war vielleicht für die Anfangszeit oder -CURRENT gedacht.
Nein, das war nicht für CURRENT gedacht.
Jeder kann nachschauen, dass z. B. NomadBSD 130R-20210508 auf FreeBSD-13.0-R basiert und ab 11.05.2021 zur Verfügung stand. In der Liste der installierten software packages, findet man auch das package drm-fbsd13-kmod-5.4.92.g20210419
karl_bsd hat ja auch explizit(?) gebaut und nicht via pkg eingespielt.
karl_bsd hat erst dann aus dem Port gebaut, als er auf 13.0-R mit dem "neuen" /boot/modules/i915kms.ko, nach einem pkg update/upgrade Probleme bekommen hat.
 
Bist Du dir da sicher? Warum bekomme ich dann diese Ausgaben:
Code:
:~ % pkg search drm-fbsd13-kmod
drm-fbsd13-kmod-5.4.191.g20220604_1 DRM modules for the linuxkpi-based KMS components
Code:
:~ # pkg install drm-fbsd13-kmod
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
    drm-fbsd13-kmod: 5.4.191.g20220604_1

Number of packages to be installed: 1

The process will require 5 MiB more space.
1 MiB to be downloaded.

Proceed with this action? [y/N]:
Kann es sein, dass du ein lokales Repository hast und das Paket von dir selbst gebaut wurde? Die Ausgabe von "pkg search drm" ist hier:

pkg search drm
drm-510-kmod-5.10.113_5 DRM drivers modules
drm-kmod-20220907_1 Metaport of DRM modules for the linuxkpi-based KMS components
drm_info-2.3.0 Small utility to dump info about DRM devices
libdrm-2.4.113,1 Userspace interface to kernel Direct Rendering Module services
linux-c7-libdrm-2.4.97 Interface to kernel Direct Rendering Module (Linux CentOS 7.9.2009)
py39-drmaa-0.4b3_1 Interact with DRMAA-compliant distributed resource management systems
vdr-plugin-vdrmanager-0.6_7 Video Disk Recorder - VDR-Manager server plugin
 
Kann es sein, dass du ein lokales Repository hast und das Paket von dir selbst gebaut wurde? Die Ausgabe von "pkg search drm" ist hier:
Nein, kein lokales Repo und das Paket habe ich auch nicht selber gebaut. Es ist mit "pkg search drm" nicht mehr drin, weil sie es gestern aus den packages und aus den Ports rausgeholt haben:
Code:
graphics/drm-kmod: Default to drm-510-kmod for >= 13.1
Now that 13.0 is EoL we can default everyone to drm-510-kmod
graphics/drm-kmod: Chase supported kernel version range of drm-fbsd13-kmod
Hook drm-fbsd13-kmod to the maser drm-kmod port and bump its PORTREVISION.
Add new drm-fbsd13-kmod to the conflict lists of the other ports.
Quelle: https://cgit.freebsd.org/ports/log/graphics/drm-kmod?showmsg=1
BTW: Für 12.x gibt es den Port noch: https://cgit.freebsd.org/ports/tree/graphics/drm-fbsd12.0-kmod
 
Interessant, im "originalen" Thread gab es fast das gleiche Problem, da aber als "Beschwerde" formuliert... und jetzt lese ich hier auch den Wunsch, dass pkg nichts auf 13.0 installieren soll, was damit nicht funktioniert. Nunja, das betrifft < 1% aller Packages (denn das ABI bleibt ja stabil). Um das umzusetzen müsste man nicht nur die technische Voraussetzung schaffen, man müsste auch (vermutlich manuell) die wenigen Pakete "markieren", die mit 13.0 nicht funktionieren werden. Das wäre am Ende auch nichts weiter als Support für ein EoL System, also mehr oder weniger ein Oxymoron.

Wenn irgendwelche Forks/Derivate/Distributionen es innerhalb der 3 Monate Übergangsfrist nicht schaffen, auf die neue Version zu kommen, aber trotzdem die FreeBSD Packages unverändert nutzen, sollte man sich meiner Meinung nach doch eher dort beschweren ... :cool:
 
Wenn irgendwelche Forks/Derivate/Distributionen es innerhalb der 3 Monate Übergangsfrist nicht schaffen, auf die neue Version zu kommen, aber trotzdem die FreeBSD Packages unverändert nutzen, sollte man sich meiner Meinung nach doch eher dort beschweren ... :cool:
Beschweren nutzt nichts, denn die Forks/Derivate/Distros können/sollen schon mal Vorarbeit leisten um auf die neue Version zu kommen, aber als User sollte man (mit einem generischen Kernel und packages) innerhalb der 3 Monate Übergangsfrist, keinesfalls das neue/letzte Release benutzen, weil noch packages angeboten/genutzt werden die von der vorletzten Release (d. h. z. B. von 13.0 und sollen mit 13.1 benutzt werden, was nicht immer funktioniert; z. B. wireguard-kmod von 13.0 in 13.1) stammen. Die devs von NomadBSD machen es richtig, weil es z. Zt. (Stand: 20.09.2022) noch kein NomadBSD basierend auf FreeBSD 13.1-R gibt.
Die Lösung ist, ab dem Zeitpunkt an dem das letzte/neueste Release erschienen ist, kein update/upgrade mit dem Vorgänger-Release zu machen und das neueste Release erst ca. 2-3 Wochen nach dem EoL des Vorgänger-Release zu benutzen (mit einem sofortigen "pkg upgrade -f" nach dem 1. Booten).
 
Äh was? Das ist streckenweise etwas wirr, was für ein "vorletztes Release"?

Dass ein Package auf einer neueren Version der gleichen Major (also, gleiches ABI) nicht funktioniert ist extrem selten, und überhaupt nur bei Kernelmodulen möglich. Ja, es kommt vor und es ist unschön, aber das sind allesamt "leaf ports", dazu mit kaum Abhängigkeiten -- die kann man absolut problemlos in der Übergangszeit einfach selbst aus dem entsprechenden Port bauen.

Die devs von NomadBSD machen es richtig
Nein.
Die Lösung ist, ab dem Zeitpunkt an dem das letzte/neueste Release erschienen ist, kein update/upgrade mit dem Vorgänger-Release zu machen und das neueste Release erst ca. 2-3 Wochen nach dem EoL des Vorgänger-Release zu benutzen
Definitiv nein.
 
Naja, selbst wenn man a) irgendn -kmod, das von sowas betroffen ist, unbedingt braucht und b) trotzdem auf gar keinen Fall selbst bauen will ... (obwohl das, wie gesagt, Kleinkram ist)

Mehrere Wochen warten muss man trotzdem nicht. Allenfalls ein paar Tage ;)
 
Zurück
Oben