Nach FreeBSD 15.1 Upgrade - ein Eintrag 15.0-RELEASE-p10 bleibt.

Was uname und openssl betrifft:
  1. pkg-which durchsucht nur bereits installierte Pakete.
  2. Wenn Du pkgbase benutzen willst, reicht es nicht aus, nur das Repository einzutragen. Wurde aber auch schon gesagt.
woran kann das liegen?
Das Konfigurationsdateien wie /etc/master.passwd jetzt nicht dem default entsprechen, dürfte ja logisch sein. Du vergibst ja eigene Usernamen und Passwörter. Wäre ja seltsam, wenn das nicht so wäre. Ähnliches gilt auch für die anderen beanstandeten Dateien wie /etc/login.conf oder /etc/shells.
 
Zuletzt bearbeitet:
pkg-which durchsucht nur bereits installierte Pakete.
eben und ich hatte das auch schon mal versucht, irgendwie zu erklären und will es nochmal probieren.

FreeBSD installiert (mal grob und einfach gesagt) die zusätzlich installierte SW (third party) unter /usr/local und entsprechend die ausführbaren Dateien in /usr/local/bin. Seit längerem schon nutzen wir dafür hauptsächlich pkgng, diese SW wird also aus Paketen genommen und mit einem pkg-Befehl installiert.
Wenn du zu irgendeinem der hier liegenden Binaries mittels pkg which fragst, woher das kommt, erhältst du die passende Antwort:
Code:
pit@Mifcom ~:- > pkg which /usr/local/bin/picom
/usr/local/bin/picom was installed by package picom-13
FreeBSD selbst, also das System, das eigentliche Unix, liegt in /bin bzw in /usr/bin. Wenn du klassisch installiert oder einen Update gemacht hast, ist das nicht mittels Paketen installiert worden, denn das ist erst neuerdings möglich, eben seit pkgbase. Demzufolge bekommst du keine passende Antwort, wenn du mittels pkg which wissen willst, welches Paket die Binarie installiert hatte.
Code:
pit@Mifcom ~:- > pkg which /usr/bin/vmstat
/usr/bin/vmstat was not found in the database

Erst dann, wenn du pkgbase benutzt hast und deshalb die Binaries in /usr/local/bin eben aus Paketen installiert wurden, würdest hier eine positive Antwort bekommen können.

Deshalb ist das ein Unterscheidungsmerkmal, mit dem man einem System ansehen kann, ob es klassisch oder mit pkgbase upgedatet wurde.
In diesem Fall klassisch, was heutzutage dann laut zitierter Anleitung bedeutet, dass freebsd-update benutzt wurde. Es könnte aber auch manuell aus den System-Sourcen gebaut werden, das wäre im vorliegenden Sinn ebenfalls klassisch, weil eben vor pkgbase.

Eigentlich sollte man denken, dass man doch weiß, wie man sein System aufgesetzt bzw geupdatet hat und man darf sich fragen, weshalb die Ersteller der Anleitung überhaupt Zeit darauf verwenden, die Unterscheidungsmöglichkeiten erst noch zu erwähnen. Falsch wird es dadurch aber jedenfalls nicht und es verleiht dem Nutzer womöglich mehr Sicherheit, den passenden Weg zu wählen. Also, einen, genau einen der Wege.
Das gilt ja in der erwähnten Anleitung analog für den Boot-Loader, wo auch zunächst erklärt wird, wie man denn herausfindet, ob UEFI oder Legacy: eigentlich sollte man das doch wissen und den passenden Weg für sein eigenes System zielsicher wählen. Im Zweifel (oder bei einem fremden System), hilft einem die Anleitung.
 
Klar könnte ich FreeBSD 15.1 aarch64 herunterladen und neu installieren, mir geht es aber eher darum herauszufinden was eventuell falsch ist.
wie ich das sehe, ist da nichts falsch.
freebsd-update IDS vergleicht ja die Dateien aus dem Netz mit den lokal vorhandenen und wenn du etwas eigenes konfiguriert hast, sind deine eigenen Dateien ja verändert und das wird halt gefunden und ausgegeben.
 
IDS woran kann das liegen?
Code:
# freebsd-update IDS
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 15.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.

Inspecting system... done.
Was hier evtl. fehlt, ist:
Code:
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
 
Auch das hilft nicht weiter:
Code:
# freebsd-update fetch install
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 15.1-RELEASE from update1.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 15.1-RELEASE-p0.
No updates are available to install.

Ich glaube, wenn du hier das fetch weggelassen hättest, wäre alles gut gewesen und das Userland wäre installiert worden.
 
Falls es nur um die Fehlersuche geht: ich würde das getrennt betrachten. Die IDS-Treffer in /etc sind bei passwd/group/login.conf/shells erst mal nicht verdächtig, sobald Benutzer, Shells oder login.conf angepasst wurden. Interessanter wäre eher, ob nach freebsd-update install (ohne neues fetch) noch Dateien unter /bin oder /usr/bin auf 15.0 zeigen. Wenn freebsd-version -kru jetzt 15.1/15.1/15.1 meldet und es eine VM-Spielwiese ist, würde ich mir vor weiteren pkgbase-Experimenten einen Snapshot/Klon weglegen und dann nur noch einen Upgrade-Pfad testen.
 
Interessanter wäre eher, ob nach freebsd-update install (ohne neues fetch) noch Dateien unter /bin oder /usr/bin auf 15.0 zeigen.
Da der TE quarterly benutzt, werden so zeitnah (Release 15.1 (Juni 16, 2026), noch einige binaries mit z. B. "Build 1500068" vorhanden sein.

EDIT:

"build_timestamp" kann man anzeigen lassen, mit z. B.:
Code:
pkg query "%n-%v %At %Av" | awk '$2 == "build_timestamp" {print $1, $3}' | sort -r
 
Zuletzt bearbeitet:
Zurück
Oben