Nach release upgrade auf 13.1 startet sshd nicht mehr

morromett

Well-Known Member
Nach einem release upgrade von 13.0 auf 13.1, startet sshd nicht mehr:
Code:
:~ # service sshd start
Performing sanity check on sshd configuration.
ld-elf.so.1: Undefined symbol "datafellows" referenced from COPY relocation in /usr/sbin/sshd
/etc/rc.d/sshd: WARNING: failed precmd routine for sshd
Code:
:~ # sshd -t
ld-elf.so.1: Undefined symbol "datafellows" referenced from COPY relocation in /usr/sbin/sshd
Die Datei "/etc/rc.d/sshd" ist nicht verändert worden.
Im Internet habe ich keine Hinweise zu dieser Fehlermeldung bzgl. sshd gefunden.
 
Moin,

während einem Testupdate auf einen RC hatte ich auf einem Notebook reproduzierbar genau diesen Fehler. Glücklicherweise hatte ich mit bectl gearbeitet. Unabhängig davon konnte ich bereits bei den RC das Problem beheben, indem ich freebsd-update upgrade noch einmal habe drüber gejagt. Allerdings habe ich mit --currently-running 13.0-RELEASE gearbeitet.

HTH!
 
Hi @Columbo0815 - was genau hast Du auch statt mit bectl zu arbeiten gemacht?? Das ist deswegen interessant, da ich vorhabe PC's und Server evtl. auch auf 13.1 "anzuheben" - da ist z.B. so ein sshd Dienst elementar wichtig... VG Norbert
 
das scheint kein allgemeines Problem zu sein. Der Dienst startet bei mir automatisch und läuft auch.
Code:
pit@Celsius ~:- > sha256 /usr/sbin/sshd
SHA256 (/usr/sbin/sshd) = e94839070eba777bbce5f07e48c2b46336dd80ee28e89875b5c36076c41b98eb
pit@Celsius ~:- > freebsd-version -ukr
13.1-RELEASE
13.1-RELEASE
13.1-RELEASE
 
das scheint kein allgemeines Problem zu sein. Der Dienst startet bei mir automatisch und läuft auch.
[/CODE]
Hast Du auch ein release-upgrade gemacht oder ist es eine neue Installation von 13.1?

Bei einer Neuinstallation von 13.1 habe ich auch kein Problem mit dem sshd, dafür aber mit wireguard:
Code:
:~ # service wireguard start
elf_load_section: truncated ELF file
Abort trap
elf_load_section: truncated ELF file
Abort trap

EDIT:


:~ % pkg info wireguard-kmod
wireguard-kmod-0.0.20211105
Name : wireguard-kmod
Version : 0.0.20211105
Installed on : Mon May 23 22:17:01 2022 CEST
Origin : net/wireguard-kmod
Architecture : FreeBSD:13:aarch64
Prefix : /usr/local
Categories : net-vpn net kld
Licenses : MIT
Maintainer : decke@FreeBSD.org
WWW : https://git.zx2c4.com/wireguard-freebsd/
Comment : WireGuard implementation for the FreeBSD kernel
Annotations :
FreeBSD_version: 1300139
repo_type : binary
repository : FreeBSD
Flat size : 108KiB
Description :
Kernel module for FreeBSD to support Wireguard.

At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues. We gladly
welcome your testing and bug reports, but do keep in mind that this code
is new, so some caution should be exercised at the moment for using it
in mission critical environments.

WWW: https://git.zx2c4.com/wireguard-freebsd/
EDIT 2:

This is a kernel module for FreeBSD to support WireGuard. It is being developed here before its eventual submission to FreeBSD 13.1 or 14.
Quelle: https://git.zx2c4.com/wireguard-freebsd/about/
 
Zuletzt bearbeitet:
Hi @Columbo0815 - was genau hast Du auch statt mit bectl zu arbeiten gemacht?? Das ist deswegen interessant, da ich vorhabe PC's und Server evtl. auch auf 13.1 "anzuheben" - da ist z.B. so ein sshd Dienst elementar wichtig... VG Norbert
Moin, ich habe bectl genutzt:
Code:
bectl create foobar
bectl mount foobar
chroot /tmp/be_foobar
mount -t devfs devfs /dev
freebsd-update upgrade -r 13.1-RELEASE
freebsd-update install
freebsd-update install
pkg upgrade
freebsd-update install
exit
umount /tmp/be_foobar/dev
bectl umount foobar
bectl activate foobar
shutdown -r now
Da ich mit bectl gearbeitet hatte, konnte ich einfach wieder auf 13.0 zurück und den Fehler auch so reproduzieren. Wie gesagt.. mit einem --currently-running 13.0-RELEASE konnte ich es fixen. Das Problem hatte ich auch nur auf einem Notebook, alle anderen Geräte konnte ich ohne Problem aktualisieren.
 
Ich habe von 13.0 letzte Patchversion ein Upgrade auf 13.1-RELEASE gemacht. Lief alles problemlos und auch der sshd laeuft wie vorher.

Ich bin so vorgegangen: https://www.freebsd.org/releases/13.1R/installation/#upgrade
dito.

nur hatte ich zusätzlich aus purem Übermut auch noch ein pkg upgrade -f laufen lassen, was aber mit der Thematik hier nichts zu tun hat.

wireguard-modul:
FreeBSD_version: 1300139
Das sieht für mich genau nach meinem Problem von hier aus: https://www.bsdforen.de/threads/freebsd-13-1-erschienen.36521/post-329576
Die Lösung war dann auch der Bau des Moduls aus den Ports.
Wenn der Hinweis in dem Link stimmt, werden die Pakete erst ca drei Monate später, nach dem endgültigen Ende von 13.0, für 13.1 gebaut werden. So lange muss man das dann selbst machen, oder warten.
 
Jedes Release das gleiche Spiel: "freebsd-update hat mein System zerschossen!" Als IRC noch eine Sache war, haben wir teilweise Strichlisten geführt. Einfach, da so viele genervte Nutzer kamen. :mad: FreeBSD würde gut daran tun, freebsd-update zu verschrotten, auf PkgBase umzusteigen und gut ist.

Das Problem mit dem sshd ist, dass das System anscheinend unvollständig aktualisiert wurde. Wieso auch immer.
 
Jedes Release das gleiche Spiel: "freebsd-update hat mein System zerschossen!" Als IRC noch eine Sache war, haben wir teilweise Strichlisten geführt. Einfach, da so viele genervte Nutzer kamen. :mad: FreeBSD würde gut daran tun, freebsd-update zu verschrotten, auf PkgBase umzusteigen und gut ist.

Das Problem mit dem sshd ist, dass das System anscheinend unvollständig aktualisiert wurde. Wieso auch immer.

das kann ich nicht sagen - ich hatte bisher kaum oder keine Probleme mit freebsd-update gehabt...
 
Okay. Vielleicht sehe ich es auch zu negativ. Klassischer Selektionsfehler: In Foren und Chats kommen vor allem die fehlgeschlagenen Fälle an :)
 
Letztendlich ist freebsd-update einfach nur ein 3500 Zeilen langes Shell-Skript was keinerlei nennenswerte Fehlerbehandlung hat. Aus eigener Erfahrung weiß ich, dass das Skript bei Fehlern schlicht und ergreifend aufhört und es vom aufgerufenen Befehl abhängt, ob eine sinnvolle Fehlermeldung kommt. Helfen tut's aber auch nicht viel, weil das System an der Stelle dann eh schon zerschossen ist.

Ein volles Backup / Snapshot ist immer ratsam an der Stelle.
 
seit es noch gar nicht offiziell war, nutze ich nun bereits freebsd-update. Das also wohl ab so FreeBSD 6 oder sogar schon mit 5. Das bedeutet, dass ich schon viele updates/upgrades damit erlebt habe und tatsächlich ist es nicht immer gut gegangen. Hauptsächlich übersehe ich gerne Fehler beim Mergen der Konfigurationen, aber es hat auch schon hängende Prozesse gegeben und damit natürlich zunächst mal zerstörte Systeme.
Trotzdem gefällt mir das besser, als alles immer manuell zu machen. Da ich beinahe eben so lange nur noch mit GENERIC fahre, macht der Eigenbau an und für sich ja wenig Sinn.
Ich weiß gar nicht, ob ihr euch noch der Zeiten vor pkgng entsinnen könnt und dass damals @Kamikaze auch ein eigenes Script oder eine Sammlung von Scripten geschrieben hatte, um Pakete gescheiter einsetzen und verwalten zu können.
So ähnlich sehe ich das mit freebsd-update auch. Es existiert nur, weil es von FreeBSD noch keine andere Lösung gibt. Das heißt, sie ist ja schon geplant und in Aussicht. Aber irgendwie wollen die nicht so wirklich ran?
 
so, habe gerade freebsd-update auf einem Laptop mit 13.0 fahren lassen. Kann auch service "sshd restart" ohne Probleme ausführen - es scheint alles okay zu sein...
 
Moin, ich habe bectl genutzt:
Code:
bectl create foobar
bectl mount foobar
chroot /tmp/be_foobar
mount -t devfs devfs /dev
freebsd-update upgrade -r 13.1-RELEASE
freebsd-update install
freebsd-update install
pkg upgrade
freebsd-update install
exit
umount /tmp/be_foobar/dev
bectl umount foobar
bectl activate foobar
shutdown -r now
Da ich mit bectl gearbeitet hatte, konnte ich einfach wieder auf 13.0 zurück und den Fehler auch so reproduzieren. Wie gesagt.. mit einem --currently-running 13.0-RELEASE konnte ich es fixen. Das Problem hatte ich auch nur auf einem Notebook, alle anderen Geräte konnte ich ohne Problem aktualisieren.
Moin @Columbo0815 , kann es sein das das Problem vielleicht deshalb aufgetreten ist, das nach dem ersten "freebsd-update install" (Kernel Installation) kein Neustart gemacht wurde mit der neuen BE?
 
Nein, ich würde das als Grund ausschließen. Es ist auch nur auf einer Maschine passiert, alle anderen wurden mit dem gleichen Verfahren aktualisiert und funktionieren wunderbar. Ich vermute die Ursache, wie Yamagi sagt, in einem unvollständigen Upgrade. Der betroffene Rechner wurde von 13.0 auf verschiedenste -RC aktualisiert. Das Problem trat bei/ab -RC4 oder so auf.

Als Ergänzung: In der Auflistung der Befehle fehlt vor dem freebsd-update upgrade noch ein "rm -rf /var/db/freebsd-update/*". :)
 
Mein Vermutung war eben, das eine Komponente eine Funktion im neuen Kernel gebraucht hätte (der noch nicht lief) und deshalb das Upgrade fehl schlug...
 
Mit bectl ist nur ein Reboot erforderlich (und dieser nachdem bectl activate ausgeführt wurde). Hintergründe werden auch hier erläutert (zwar mit beadm, aber bectl ist ein Ersatz für beadm): https://vermaden.wordpress.com/2021/02/23/upgrade-freebsd-with-zfs-boot-environments/

Unabhängig von bectl wäre für ssh auch kein Reboot erforderlich, wie die Upgradeanleitung zu 13.1 sagt:
After upgrading, sshd (from OpenSSH 8.8p1) will not accept new connections until it is restarted. After installing the new userland, either reboot (as specified in the source update procedure), or execute service sshd restart.
 
Da das Thema nicht "mein Upgrade hat super funktioniert" ist, sollten wir wieder zu diesem zurück kommen.
 
Dieser wunderschöne Bug hat meine Matrix Home Node abgeschossen: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264282

Falls noch jemand das Pech hat, ein BIOS-System mit GPT von einem GELI-verschlüsselten / starten zu wollen, kann man drum herum werkeln, indem man /boot/loader aus 13.0 nimmt. Allerdings verliert man dann einen Teil der höheren Bootgeschwindigkeit.

Nachtrag: Erschreckend ist auch jedes Mal wieder, dass man im Netz durchaus mehrere Berichte zu dem Fehler findet. Aber nicht mal den Ansatz eines Bugreports. Muss ja keine vollständige Analyse sein.
 
Wurde mit:

# freebsd-update IDS

die FreeBSD-Installation kontrolliert? Siehe dazu:

- Kapitel "23.2.4. Vergleich des Systemzustands" im FreeBSD-Handbuch:

- # man freebsd-update

und diese Beiträge:
 
Zurück
Oben