FreeBSD upgrade auf 14.3

jmt

jmt

Well-Known Member
Hallo,

bei mit bricht
Code: 
freebsd-rustdate upgrade --release 14.3-RELEASE
immer ab, weil er die benötigten Dateien nicht aus dem Internet laden kann. Habt Ihr das Problem auch?

Gruß Markus
 
berni51 schrieb:
Das i915kms-Modul wurde nicht mehr grladen. Mist!
Zum Vergrößern anklicken....
Hast Du alle Pakete aktualisiert?
Hast Du auch das Paket-Repository für die Kernel-Module eingebunden?
Code: 
FreeBSD-kmods: {
#       url: "pkg+https://pkg.FreeBSD.org/${ABI}/KMODSFLAVOR",
       url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest_3", # FreeBSD 14.3 RELEASE
        mirror_type: "srv",
        signature_type: "fingerprints",
        fingerprints: "/usr/share/keys/pkg",
        enabled: true
}
(siehe https://forums.freebsd.org/threads/...talling-freebsd-13-1.86633/page-5#post-690633 ff.)

bzw. alternativ aus den Ports kompiliert?
 
BTW: In 14.3 sind auch Packages aus 14.2, die unter 14.3 nicht funktionieren. Z. B.:
Code: 
:~ # uname -a
FreeBSD generic 14.3-RELEASE FreeBSD 14.3-RELEASE releng/14.3-n271432-8c9ce319fef7 GENERIC arm64
Code: 
pid 1361 (umurmurd), jid 0, uid 1002: exited on signal 4 (no core dump - other error)
Code: 
:~ # file /usr/local/bin/umurmurd
/usr/local/bin/umurmurd: ELF 64-bit LSB executable, ARM aarch64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 14.2, FreeBSD-style, stripped
Code: 
:~ # pkg info umurmur
umurmur-0.3.0
Name           : umurmur
Version        : 0.3.0
Installed on   : Wed Jun 11 13:06:54 2025 CEST
Origin         : audio/umurmur
Architecture   : FreeBSD:14:aarch64
Prefix         : /usr/local
Categories     : net audio
Licenses       : BSD3CLAUSE
Maintainer     : bofh@FreeBSD.org
WWW            : https://umurmur.net/
Comment        : Minimalistic Murmur (Mumble server)
Shared Libs required:
    libc.so.7
    libconfig.so.11
    libmbedcrypto.so.16
    libmbedtls.so.21
    libmbedx509.so.7
    libprotobuf-c.so.1
Annotations    :
    FreeBSD_version: 1402000
    build_timestamp: 2025-05-16T01:39:24+0000
    built_by       : poudriere-git-3.4.2-12-g74a54a88
    port_checkout_unclean: no
    port_git_hash  : 359bbf7fc
    ports_top_checkout_unclean: no
    ports_top_git_hash: a764c0678
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 127KiB
 
Nachdem ich schon ziemlich entnervt war hat sich mein Grafikproblem mit den folgenden zwei Befehlen rudimentär beheben lassen:

# pkg install drm-kmod
# pkg upgrade -r FreeBSD-kmods

Wenigstens habe ich jetzt wieder (irgend)eine Grafik, aber noch keine schnelle Grafik. Jetzt mache ich mich auf die Suche nach der Ursache.

VLG
Stephan
 
das drm-Problem habe ich natürlich auch gefangen, erst mal ignoriert, dann aus den Ports neu gebaut.

Ich habe aber noch gar kein X wirklich gestartet, nur der XDM kommt halt inzwischen wieder hoch. Aber auf einem einzigen Monitor. Ich glaube, dass es keinen Sinn macht, in X weiter zu machen, wenn der Monitor ja schon gar nicht während des Bootens kommt.

Es ist übrigens kein HW-Fehler, was man ja leicht denken könnte.
Ein Live-Linux bootet mit zwei Monitoren und auch mein "Backup"-Stick, der ja ein Clon des Systems vor nicht allzu langer Zeit darstellt und also noch 14.1 oder 14.2 bootet, bringt beide Monitore.
Womöglich hätte ich sogar sofort einen rollback gemacht, was aber unmöglich war, weil mit diesem "Backup"-System auch der System-Root-Pool eingebunden wurde (sehr unangenehm). Das muss ich nun erst verhindern oder einen neuen Boot-Stick erstellen.

Nebenbei: die automatisch erstellten Snaps haben mir mal wieder nicht geholfen, auch den alten Kernel zu booten nicht.
Mal sehen, ob ich noch ne Idee habe (wahrscheinlich eher nicht), oder gleich den rollback angehe.
 
Noch ein Nachtrag: jetzt läuft bei mir die Grafik auch wieder flott wie gewohnt. Mein Fahler war, dass ich beim (zugegeben etwas unkoordinierten) Herumprobieren mir einen Legacy-Driver dazu installiert hatte. Das war keine gute Idee ;) . Deinstallieren dieses Anachronismus hat es natürlich behoben.

VLG
Stephan
 
Andy_m4 schrieb:
Welchen Port hast Du denn da konkret gebaut?
Zum Vergrößern anklicken....
zunächst versuchte ich den neuen nvidia-drm-66-kmod, oder so ähnlich und scheiterte beim Bau aus den Paketen.
Dann nahm ich den nvidia-drm-61-kmod und und bekam mal wieder X auf einem Monitor.

Nun antworte ich nur in Kürze, weil mittels rollback zurück und keine Übersicht darüber, was geht und was nicht.

Aber das ist schon übel, wenn man einen rollback überhaupt braucht wobei das Übel natürlich in mir liegt, weil ich gewöhnlicherweise erst lese, wenn das Kind in den Brunnen gefallen ist.

Das gilt insbesondere genau deshalb, weil ich mal den Boot-Prozess genauer beobachtet habe und auch nach dem Rollback bleibt ein Monitor beim Booten vollkommen dunkel!
Ich war sicher, dass das anders ist!
Wenn ich mich aber täusche...

Also: mit 14.2 werden alle Monitore erkannt und eingebunden, wenn X startet.
Was zuvor passiert, bin ich etwas verunsichert.
Mit 14.3 werden nicht alle Module geladen und es gibt entsprechende Fehlermeldungen.

Ähm, hatte ich das noch nicht geantwortet? Offenbar? Also nun oder eben nochmal.
 
pit234a schrieb:
und scheiterte beim Bau aus den Paketen.
Zum Vergrößern anklicken....
Was war denn die Fehlermeldung?
Wenn ich richtig im Kopf habe, geht der ganze drm-66-kmod-Kram erst ab FreeBSD 15 (vorher steht die benötigte Treiberinfrastruktur gar nicht zur Verfügung).

pit234a schrieb:
Mit 14.3 werden nicht alle Module geladen und es gibt entsprechende Fehlermeldungen.
Zum Vergrößern anklicken....
Solche Äußerungen gewinnen immer enorm an Wert, wenn man die konkreten Fehlermeldungen auch nennt. :-)
 
Andy_m4 schrieb:
Solche Äußerungen gewinnen immer enorm an Wert, wenn man die konkreten Fehlermeldungen auch nennt. :-)
Zum Vergrößern anklicken....
natürlich.

Nur, dass ich im Netz ein wenig gesucht und so gar keinen Hinweis auf entsprechende Probleme mit 14.3 gefunden habe. Daraus schließe ich mal, dass ich das Problem bin!
Deshalb frage ich jetzt (JETZT) zunächst mal noch nicht nach Hilfe, sondern nutze vorerst mal 14.2 weiter (wie ich es eigentlich auch vorgehabt hatte) und beim nächsten Versuch sehe ich genauer hin und lese womöglich auch mal vorher!

Ein Fehler, den ich absolut gemacht habe: ich hatte nicht /usr/src aktualisiert, also auf 14.3 gebracht, bevor ich aus den Ports gebaut hatte!
Allerdings will ich auch nicht wirklich aus den Ports bauen und deshalb zum nächsten Thema und einer echten Frage:


waldbaer59 schrieb:
# pkg upgrade -r FreeBSD-kmods
Zum Vergrößern anklicken....
woher kommt denn das geflogen?
Ich versuche ja nun zuvor zu lesen, aber darauf bin ich nicht gestoßen.
Ist das eine Möglichkeit, alle zusätzlichen Module auf einen Rutsch passend zur freebsd-version zu aktualisieren?
 
pit234a schrieb:
Daraus schließe ich mal, dass ich das Problem bin!
Zum Vergrößern anklicken....
Das kann man halt nicht wissen.
Es ist immer gut die Fehlermeldung zu posten. Und wenns nur ist, das jemand anders das sieht und dann bemerkt: "Ach guck. Die Fehlermeldung hatte ich auch. Ich bin offenbar nicht der einzige mit dem Problem und dann liegt es ja vielleicht nicht an mir." oder was auch immer.
Information zu haben ist immer besser, als sie nicht zu haben.

pit234a schrieb:
woher kommt denn das geflogen?
Zum Vergrößern anklicken....
Das ist hier ganz gut erklärt:

Auf FreeBSD 14.3 übertragen heißt das, das man
unter /usr/local/etc/pkg/repos/ eine Datei mit dem Namen kmods.conf (im Prinzip kann die aber auch anders heißen) und die mit
Code: 
FreeBSD-kmods: {
    url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest_3",
    mirror_type: "srv",
    signature_type: "fingerprints",
    fingerprints: "/usr/share/keys/pkg",
    enabled: yes
}
befüllt.
Die Release-Notes erwähnen das auch.
 
Andy_m4 schrieb:
Das ist hier ganz gut erklärt:
Zum Vergrößern anklicken....
das hatte ich so auch irgendwo irgendwann gelesen, aber durchaus nicht abgeleitet, dass man dieses Repo durch pkg upgrade nutzen könnte und staune auch darüber, dass der Ausdruck "FreeBSD-kmods" offenbar ein fester Teil dieses Befehls ist.
Vermutlich muss man da erst die neue man-page lesen, nachdem man upgedatet hat?
 
Andy_m4 schrieb:
Es ist immer gut die Fehlermeldung zu posten.
Zum Vergrößern anklicken....
Angeber-Modus ein:
Code: 
pit@Mifcom ~:- > freebsd-version -ukr
14.3-RELEASE
14.3-RELEASE
14.3-RELEASE
und wieder aus.

Nochmal gemacht und diesmal mehr Zeit gelassen und genauer hingesehen, das kmods-Repo eingebaut, /usr/src zuvor schon mal auf 14.3 gelegt (man weiß ja nie), die Ports aktualisiert und dann also nochmal
jmt schrieb:
freebsd-rustdate upgrade --release 14.3-RELEASE
Zum Vergrößern anklicken....
wie zuvor durchgelaufen und wie zuvor wird hernach kein zweiter Monitor erkannt.
Die /var/log/Xorg.0.log ist da etwas unverständlich und zeigt eine zusätzliche GraKa an, die ich am PC noch nicht entdeckt habe und im BIOS auch nicht ausschalten kann. Es wird aber verlangt, die Bus-ID meiner Karte zu setzen und dann wird aber kein /dev/dri/card0 erkannt.

Die Bus-ID setze ich noch immer in der /etc/X11/xorg.conf und hier ist die auch gesetzt.
Aber ich musste nun erst noch angeben, dass ich den nvidia-Treiber haben will.
Code: 
Section "Device"
    Identifier  "Card0"
        Driver      "nvidia"
    BusID       "PCI:65:0:0"
EndSection

Section "Device"
        Identifier  "Card1"
        Driver      "nvidia"
        BusID       "PCI:65:0:0"
EndSection
Der Satz "Driver "nvidia"" ist also neu (oder besser, wieder mal) in der xorg.conf und damit startet X mit beiden Monitoren und nutzt diese dann auch wie gehabt und ich bin damit nun bei 14.3 angekommen.

Zuvor hatte ich eigentlich in einer Art Verzweiflung ein pkg upgrade -f gemacht, was ja nicht schaden konnte.
Viel probiert habe ich bislang aber nicht. Erst mal froh damit.
 
Andy_m4 schrieb:
Also wenn man das kmods-Repository in oben genannter Weise einbindet, kann man sich den Inhalt des Repositorys auf folgende Weise anzeigen lassen:
pkg search -r FreeBSD-kmods .\*
bzw. Pakete daraus installieren mit (Beispiel):
pkg install -r FreeBSD-kmods drm-61-kmod
Zum Vergrößern anklicken....
Frage: Wenn man unter 14.2 die kmods.conf mit o.g. Inhalt erstellt und dann ein freebsd-update upgrade -r 14.3-RELEASE macht, wird dann alles richtig und automatisch aktualisiert?
 
cabriofahrer schrieb:
o.g. Inhalt erstellt
Zum Vergrößern anklicken....
Was denn "oben genannt"?
Da wurde viel geschrieben. Verlinke oder zitiere es doch einfach, dann gibts auch keine Missverständnisse.

cabriofahrer schrieb:
wird dann alles richtig und automatisch aktualisiert?
Zum Vergrößern anklicken....
Ähm nein. freebsd-update aktualisiert gar nichts automatisch aus den Packages/Ports.

Du musst dann auch brav ein pkg upgrade bzw. evtl. sogar pkg upgrade -f machen.

Für die Repository-Definition kannst Du auch eine Idee aus dem Nachbarthread aufgreifen, damit Du bei Upgrades nicht händisch die Minor-Version in der Repository-Definition anpassen musst.

Damit ergibt sich für die Datei /usr/local/etc/pkg/repos/kmods.conf
Code: 
FreeBSD-kmods: {
    url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest_${VERSION_MINOR}",
    mirror_type: "srv",
    signature_type: "fingerprints",
    fingerprints: "/usr/share/keys/pkg",
    enabled: yes
}

Aber die Treiber müssen auch von dort mittels:
pkg install -r FreeBSD-kmods drm-kmod
installiert worden sein.
 
Andy_m4 schrieb:
Was denn "oben genannt"?
Da wurde viel geschrieben. Verlinke oder zitiere es doch einfach, dann gibts auch keine Missverständnisse.


Ähm nein. freebsd-update aktualisiert gar nichts automatisch aus den Packages/Ports.

Du musst dann auch brav ein pkg upgrade bzw. evtl. sogar pkg upgrade -f machen.

Für die Repository-Definition kannst Du auch eine Idee aus dem Nachbarthread aufgreifen, damit Du bei Upgrades nicht händisch die Minor-Version in der Repository-Definition anpassen musst.

Damit ergibt sich für die Datei /usr/local/etc/pkg/repos/kmods.conf
Code: 
FreeBSD-kmods: {
    url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_latest_${VERSION_MINOR}",
    mirror_type: "srv",
    signature_type: "fingerprints",
    fingerprints: "/usr/share/keys/pkg",
    enabled: yes
}

Aber die Treiber müssen auch von dort mittels:
pkg install -r FreeBSD-kmods drm-kmod
installiert worden sein.
Zum Vergrößern anklicken....
Ist dise Sache unter FreeBSD-14.4 noch aktuell? Braucht man die Datei
Code: 
/usr/local/etc/pkg/repos/kmods.conf
noch? Oder ist das Problem, dass die Module für jedes Minor-Release speziell kompiliert sein müssen, mittlerweile behoben?
 
Code: 
pit@leno ~:- > ll /usr/local/etc/pkg/repos/
ls: /usr/local/etc/pkg/repos/: No such file or directory
Die Aussage kommt von einem inzwischen erfolgreich gehobenen System::
Code: 
~:- > freebsd-version -ukr
15.0-RELEASE-p5
15.0-RELEASE-p5
15.0-RELEASE-p5
Ich hatte also ganz offenbar hier keine Datei gebraucht, wie von dir beschrieben.

Die Sache liegt auch ein wenig anders, als es sich bei dir liest.
Seit geraumer Zeit hat FreeBSD eine "verschärfte Kontrolle", dass auch nur solche Kernel-Module geladen werden, die eine passende Version haben. Damit werden Probleme verhindert, die auftreten können, wenn etwa ein Modul aus 12 in 13 benutzt werden soll.
Nun bringt FreeBSD an sich nicht alle möglichen Kernel-Module mit. Je nach Umfang der Installation, kommen zusätzliche Module zum Einsatz, die gar nicht wirklich zu FreeBSD gehören, sondern etwa zum Beispiel zum Grafik-Treiber. Es gilt aber die genau gleiche Sicherheits-Richtlinie: sie müssen zu der benutzten FreeBSD-Version passen.
Um es den Nutzern einfacher zu machen und nicht immer eine passende Version selbst bauen zu müssen, hat man irgendwann in 14 ein neues Repo eingeführt, in welchem solche Module fertig kompiliert liegen. Diese können dann also "in einem Rutsch" beim üblichen pkg upgrade mit installiert werden und nichts muss mehr von Hand kompiliert werden.
Das schlägt sich in der Datei /etc/pkg/FreeBSD.conf
Code: 
~:- > cat /etc/pkg/FreeBSD.conf nieder, die ich aus meinem laufenden System zitiere:
#
# To disable a repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file, e.g.:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD-ports: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#   echo "FreeBSD-ports-kmods: { enabled: no }" >> /usr/local/etc/pkg/repos/FreeBSD.conf
#
# Note that the FreeBSD-base repository is disabled by default.
#

FreeBSD-ports: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-ports-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-base: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkgbase-${VERSION_MAJOR}",
  enabled: no
}
Diese Datei habe ich nicht selbst entworfen. Sie enthält drei mögliche Repos, abgekürzt die normalen ports, dann die kmods und schließlich die base, die aber bei mir (und per default) nicht enabled ist, weil ich das zunächst noch nicht nutzen möchte.

Als "Offset" zu dieser Datei, die man möglicherweise besser nicht editieren sollte, bietet FreeBSD die Möglichkeit, eigene Konfigurationen, quasi Betriebssystem-üblich, in
/usr/local/etc/pkg/repos/FreeBSD.conf
ab zu legen, anstatt die Master-Datei zu editieren.


So weit so gut.
Trotzdem gelingt bei mir ein Upgrade oder Update auf dem gezeigten Rechner wunderbar und ohne Zutun, während ich ständig und immer wieder mit einem Rechner auffalle, der eine NVIDIA hat. Obwohl hier die automatisch geladenen Module aus den kmods genau die richtige Version haben, funktionieren sie regelmäßig nicht und ich muss dann selbst Hand anlegen und aus den Ports neu bauen. Diesmal hat auch das versagt und ich bin in einem fürchterlichen Upgrade-Szenario gelandet, aus dem mir möglicherweise nur eine Neu-Installation des kompletten Systems helfen wird.


Deshalb finde ich also aus meiner Sicht die Frage merkwürdig, ob da "etwas behoben" wurde.
Es ist immer noch FreeBSD und bekommt im Laufe der Zeit neue Eigenschaften, an die man sich dann gewöhnen muss.
Das relativ neue Repo mit den kmods kann man nutzen, muss aber nicht und das noch neuere base wird wohl demnächst zu einem Standard, der dann genutzt sein will.
 
Vielen Dank für die Antwort. Bei mir sehen die Ausgaben folgendermaßen aus:
Code: 
$ ll /usr/local/etc/pkg/repos/
total 16
drwxr-xr-x  2 root wheel - 512 Jun 17  2025 ./
drwxr-xr-x  3 root wheel - 512 Aug 20  2014 ../
-rw-r--r--  1 root wheel - 286 Dec 21  2014 FreeBSD.conf.bak
-rw-r--r--  1 root wheel - 187 Jun 17  2025 kmods.conf
$ freebsd-version -ukr
14.3-RELEASE-p8
14.3-RELEASE-p8
14.3-RELEASE-p8
$ more /etc/pkg/FreeBSD.conf
#
# To disable this repository, instead of modifying or removing this file,
# create a /usr/local/etc/pkg/repos/FreeBSD.conf file:
#
#   mkdir -p /usr/local/etc/pkg/repos
#   echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
#

FreeBSD: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/quarterly",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
FreeBSD-kmods: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}
$

Wie man sieht, habe ich noch eine /usr/local/etc/pkg/repos/kmods.conf , die wohl nur für den damaligen Stand von maximal 14.3 gedacht war, als das Problem mit dem Kernelmodulen noch bestand. Jetzt ist mir nicht ganz klar, wie sich mein System bei einem Upgrade auf 14.4 verhalten würde.
Gehe ich richtig in der Annahme, dass der Eintrag

Code: 
FreeBSD-kmods: {

  url: "pkg+https://pkg.FreeBSD.org/${ABI}/kmods_quarterly_${VERSION_MINOR}",

  mirror_type: "srv",

  signature_type: "fingerprints",

  fingerprints: "/usr/share/keys/pkg",

  enabled: yes

}

in der Datei /etc/pkg/FreeBSD.conf irgendwann automatisch neu erstellt wurde und dass meine /usr/local/etc/pkg/repos/kmods.conf , nicht mehr benötigt wird, ich die also löschen kann oder gar sollte?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben