Jeder Portupgrade führt zu Fehlermeldung!
- Ersteller testit
- Erstellt am
Ja das Ziehen der Dateien kann je nach Update schon eine ganze Weile dauern..... 
Zu den Konflikten: Er versucht so gut es funktioniert die neuen Konfigurationsdateien mit den Alten zu mergen. Das funktioniert auch in großen Teilen, aber leider nicht immer. In dem Abschnitt:
Er weiss nun nicht welle Version er nehmen soll. Die Datei nun so zu belassen führt zu Fehlern da die Zeilen mit den < > und = natürlich nicht so in die Datei gehören.
Wenn du nun her gehst und löschst die Zeilen
Da es sich hierbei eh nur um Kommentarzeilen handelt ist das ziemlich egal welche der beiden Optionen die er dir bietet du umsetzt, wichtig ist nur, dass du zum Ende eine gültige Datei erzeugst.
In allen Dateien mit Konflikten die er die anbietet suchst du nach diesen "<<<< ==== >>>>" Kombinationen und machst dir das alles passend. Dann bist du auch schon fertig
Zu den Konflikten: Er versucht so gut es funktioniert die neuen Konfigurationsdateien mit den Alten zu mergen. Das funktioniert auch in großen Teilen, aber leider nicht immer. In dem Abschnitt:
will er dir sagen, dass alles zwischen "<<<<<<< current version" und "=======" entspricht dem Inhalt deiner alten Konfigurationsdatei und alles zwischen "=======" und ">>>>>>> 8.4-RELEASE" entspricht der neuen Konfigurationsdatei (wie sie mit 8.4 geliefert wird).
Er weiss nun nicht welle Version er nehmen soll. Die Datei nun so zu belassen führt zu Fehlern da die Zeilen mit den < > und = natürlich nicht so in die Datei gehören.
Wenn du nun her gehst und löschst die Zeilen
und die Zeile
heraus denn hast du eine gültige Datei auf dem aktuellen Stand.
Da es sich hierbei eh nur um Kommentarzeilen handelt ist das ziemlich egal welche der beiden Optionen die er dir bietet du umsetzt, wichtig ist nur, dass du zum Ende eine gültige Datei erzeugst.
In allen Dateien mit Konflikten die er die anbietet suchst du nach diesen "<<<< ==== >>>>" Kombinationen und machst dir das alles passend. Dann bist du auch schon fertig
Hallo Rako,
vielen Dank für Deine Erklärungen!
Mir schmerzen inzwischen die Finger, da offenbar ZIG Dateien im /etc Verzeichnis u.a. durchgegangen werden, nur damit ich die alten Hinweise auf die Version 8.2 entfernen kann.
Mir ist das egal, ob 8.2 oder 8.4 drin steht.
Kann ich den Vorgang irgendwie beschleunigen?
Viele Grüße
testit
vielen Dank für Deine Erklärungen!
Mir schmerzen inzwischen die Finger, da offenbar ZIG Dateien im /etc Verzeichnis u.a. durchgegangen werden, nur damit ich die alten Hinweise auf die Version 8.2 entfernen kann.
Mir ist das egal, ob 8.2 oder 8.4 drin steht.
Kann ich den Vorgang irgendwie beschleunigen?
Viele Grüße
testit
Tja,
nun ist es passier:
NACH" freebsd-update install" und anschließendem Reboot mit "shutdown -r now" ist mein Server via Internet nicht mehr erreichbar!
Eine Erklärung habe ich hierfür nicht.
Angenommen, ich hätte einen Fehler gemacht beim MERGE-Vorgang, wie von Rakor oben beschrieben, also bspw. versehentlich ein "<<<<<<<" in einer .conf belassen o.ä., würde dies doch sicher nicht den ganzen Boot-Prozess außer Gefecht setzen, oder etwa doch?
Viele Grüße
testit
nun ist es passier:
NACH" freebsd-update install" und anschließendem Reboot mit "shutdown -r now" ist mein Server via Internet nicht mehr erreichbar!
Eine Erklärung habe ich hierfür nicht.
Angenommen, ich hätte einen Fehler gemacht beim MERGE-Vorgang, wie von Rakor oben beschrieben, also bspw. versehentlich ein "<<<<<<<" in einer .conf belassen o.ä., würde dies doch sicher nicht den ganzen Boot-Prozess außer Gefecht setzen, oder etwa doch?
Viele Grüße
testit
Das hängt stark von ab in welcher Datei der Fehler ist. Eine fehlerhafte fstab reicht ja schon um ein System nicht mehr von alleine starten zu lassen.
Ist keiner seiner Dienste erreichbar oder ist nur z.B. sshd nicht mehr aktiv?
Ich hoffe du hast ein FreeBSD-Rettungssystem das du booten kannst. Dann das booten, deine Festplatte mounten und mal dmesg und deine Logs durchsuchen wo der Fehler liegen könnte.
Ist keiner seiner Dienste erreichbar oder ist nur z.B. sshd nicht mehr aktiv?
Ich hoffe du hast ein FreeBSD-Rettungssystem das du booten kannst. Dann das booten, deine Festplatte mounten und mal dmesg und deine Logs durchsuchen wo der Fehler liegen könnte.
pit234a
Well-Known Member
Ohje!
Hattest du erwähnt, dass du deinen Server nicht lokal verfügbar hast? Wenn ich das überlesen habe, bleibt mir nur, mich total mies zu fühlen und zu entschuldigen, dass ich dich zu einem freebsd-update motivieren wollte.
Zum Beispiel gab es mal einen Wechsel, wie Festplatten genannt werden. Einmal hießen die dax und dann adx oder umgekehrt. Einträge in der fstab sind dann normalerweise total unbrauchbar, also nach einem freebsd-update startet das System nicht mehr! Kann man in dieser Situation nicht im Single-User-Mode einloggen, um die fstab zu korrigieren, dann hat man wohl ziemlich verschissen. Ein Live-System, das gebootet werden kann und von dem aus die einzelnen Partitionen rw gemountet werden können, ist vermutlich die einzige Alternative.
Dies kann womöglich für alle Fehler gelten, die in entscheidenden System-Konfigurations-Dateien drin sein mögen.
Das mergen der alten mit den neuen Dateien ist tatsächlich ein Knackpunkt bei freebsd-update, aber, so wie ich es erlebt habe, nicht aus dem Automatismus heraus, sondern deshalb, weil man dazu neigt, Fehler dabei zu machen und die Meldungen einfach falsch zu verstehen. Jedenfalls ist es sehr sinnvoll, sich einige der Dateien zu merken und explizit nochmal zu kontrollieren, bevor ein Neustart durchgeführt wird.
Das ist aber nun alles zu spät.
Wäre es mir bewusst gewesen, dass du nicht an den Server herankommst, hätte ich niemals ein freebsd-update so leichtfertig empfohlen.
Wenn dein System tatsächlich nun nicht mehr so weit startet, dass einer der Remote-Dienste brauchbar ist, dann hilft wohl nur ein neues System zu ordern oder einen entsprechenden Install zu beginnen.
Rechne jedenfalls mit einem Ausfall des Servers für einen deutlich spürbaren Zeitraum. Das wird keine Kleinigkeit.
Hi pit234a,
dank eines hilfreichen Geistes, der sich sehr gut mit FreeBSD auskennt, ist der Server inzwischen wieder online.
Es lag tatsächlich in erster Linie daran, dass bei einigen Dateien die MERGE-Meldungen mit "<<<<<<<" u.ä. nicht komplett gelöscht waren.
Hatte ja bereits oben geschrieben, dass das zig Dateien waren, die durchgenudelt werden mussten.
Leider habe ich zwei Probleme noch nicht lösen können:
1) Komme nach dem Updaten von 8.2 auf 8.4 nur noch via SSH, aber nicht mehr mit SFTP rein.
2) QPopper startet einfach nicht mehr. In meiner inetd.conf steht nach wie vor
pop3 stream tcp nowait root /usr/local/libexec/qpopper qpopper -s
Vielleicht hat jemand noch eine Idee, was die Ursachen für o.a. Probleme sein könnten?
Vielen Dank und freundliche Grüße
testit
dank eines hilfreichen Geistes, der sich sehr gut mit FreeBSD auskennt, ist der Server inzwischen wieder online.
Es lag tatsächlich in erster Linie daran, dass bei einigen Dateien die MERGE-Meldungen mit "<<<<<<<" u.ä. nicht komplett gelöscht waren.
Hatte ja bereits oben geschrieben, dass das zig Dateien waren, die durchgenudelt werden mussten.
Leider habe ich zwei Probleme noch nicht lösen können:
1) Komme nach dem Updaten von 8.2 auf 8.4 nur noch via SSH, aber nicht mehr mit SFTP rein.
2) QPopper startet einfach nicht mehr. In meiner inetd.conf steht nach wie vor
pop3 stream tcp nowait root /usr/local/libexec/qpopper qpopper -s
Vielleicht hat jemand noch eine Idee, was die Ursachen für o.a. Probleme sein könnten?
Vielen Dank und freundliche Grüße
testit
Der Benutzer der SFTP verwenden will kann sich normal per ssh auf dem Server einloggen? Das funktioniert?
Werf nochmal einen Blick in die /etc/ssh/sshd_config ob da alles passt. Dann natürlich die üblichen Verdächtigen in der /var/log mal durchgehen (messages/security/auth.log).
Da ich weder mit QPopper bisweilen gearbeitet habe, noch inetd verwende (bzw das schon Jahrzehnte her ist) kann ich dir da leider nicht weiter helfen. Aber lässt sich der nicht per rc-script als stand-alone starten? Ich persönlich finde das attraktiver zu überwachen, aber kenne ihn wie gesagt nicht.
Werf nochmal einen Blick in die /etc/ssh/sshd_config ob da alles passt. Dann natürlich die üblichen Verdächtigen in der /var/log mal durchgehen (messages/security/auth.log).
Da ich weder mit QPopper bisweilen gearbeitet habe, noch inetd verwende (bzw das schon Jahrzehnte her ist) kann ich dir da leider nicht weiter helfen. Aber lässt sich der nicht per rc-script als stand-alone starten? Ich persönlich finde das attraktiver zu überwachen, aber kenne ihn wie gesagt nicht.
Hallo Rakor,
ich habe das Qpopper-Problem mal unter "Anwendungen" beschrieben.
Messages hatte ich mir bereits angeschaut.
Dort steht
qpopper[35668]: Unable to obtain socket and address of client: Socket operation on non-socket (38)
Ein manuelles Starten
/usr/local/libexec/qpopper qpopper -s
führt auch nicht zum Ziel.
Soeben ist mir aber aufgefallen, dass offenbar mit inetd etwas nicht stimmt:
/etc/rc.d/inetd restart
inetd not running? (check /var/run/inetd.pid).
Starting inetd.
# /etc/rc.d/inetd status
inetd is not running.
Möglicherweise ist DAS die Ursache ...
Viele Grüße
testit
ich habe das Qpopper-Problem mal unter "Anwendungen" beschrieben.
Messages hatte ich mir bereits angeschaut.
Dort steht
qpopper[35668]: Unable to obtain socket and address of client: Socket operation on non-socket (38)
Ein manuelles Starten
/usr/local/libexec/qpopper qpopper -s
führt auch nicht zum Ziel.
Soeben ist mir aber aufgefallen, dass offenbar mit inetd etwas nicht stimmt:
/etc/rc.d/inetd restart
inetd not running? (check /var/run/inetd.pid).
Starting inetd.
# /etc/rc.d/inetd status
inetd is not running.
Möglicherweise ist DAS die Ursache ...
Viele Grüße
testit
lme
FreeBSD Committer
Noch etwas Allgemeines: Wenn man mal nen "hängenden" Prozess hat und nicht weiß, was er gerade tut, kann man immer ^T (Control+T) drücken, dann bekommt man so etwas angezeigt:
Bei Shellskripten wie freebsd-update sieht man dann, welches Programm gerade ausgeführt wird und in welchem Zustand es sich befindet.
Code:
~ % sleep 60
load: 0.09 cmd: sleep 53602 [nanslp] 3.40r 0.00u 0.00s 0% 1816k
sleep: about 56 second(s) left out of the original 60Bei Shellskripten wie freebsd-update sieht man dann, welches Programm gerade ausgeführt wird und in welchem Zustand es sich befindet.
Geschafft!
Wenngleich ich es nicht verstehe, aber folgendes hat letztlich inetd wieder zum Laufen gebracht:
In folgende Dateien LEERZEILEN gelöscht:
/etc/services
/etc/rpc
/etc/netconfig
Danach konnte ich inetd wieder starten und es läuft auch wieder QPopper.
Ich bin mir sehr sicher, dass die bei dem MERGE-Vorgang (vgl. Postings weiter oben) hineingelangt sind.
Dass aber Leerzeilen deratige Auswirkungen haben, war mir neu.
Ich habe so etwas ähnliches einmal vor Jahren erlebt, als die Zeilenendemarkierungen nicht im UNIX-Format, sondern DOS-Format abgespeichert wurden. Aber das macht vi ja wohl eher nicht!!
Herzlichen Dank nochmals für Eure Hilfe!
Viele Grüße
testit
Wenngleich ich es nicht verstehe, aber folgendes hat letztlich inetd wieder zum Laufen gebracht:
In folgende Dateien LEERZEILEN gelöscht:
/etc/services
/etc/rpc
/etc/netconfig
Danach konnte ich inetd wieder starten und es läuft auch wieder QPopper.
Ich bin mir sehr sicher, dass die bei dem MERGE-Vorgang (vgl. Postings weiter oben) hineingelangt sind.
Dass aber Leerzeilen deratige Auswirkungen haben, war mir neu.
Ich habe so etwas ähnliches einmal vor Jahren erlebt, als die Zeilenendemarkierungen nicht im UNIX-Format, sondern DOS-Format abgespeichert wurden. Aber das macht vi ja wohl eher nicht!!
Herzlichen Dank nochmals für Eure Hilfe!
Viele Grüße
testit
Guten Morgen,
weil es ja auch einmal einen anderen Anwender treffen könnte:
Dass SFTP nach dem Update von 8.2 auf 8.4 nicht mehr funktionierte, ssh-logins dagegen schon, lag schlicht daran, dass beim Update in der sshd_config auf einmal
Subsystem sftp /usr/local/libexec/sftp-server
statt
Subsystem sftp /usr/libexec/sftp-server
drin stand.
Was leider ebenfalls nicht mehr funktioniert, ist der angehängte umask-Parameter
Subsystem sftp /usr/libexec/sftp-server -u 018
Der wirft nun nach dem Update von 8.2 -> 8.4 ein
sftp-server[72920]: fatal: Invalid umask "018"
in auth.log und ein Einloggen via SFTP funktioniert nicht.
Viele Grüße
testit
weil es ja auch einmal einen anderen Anwender treffen könnte:
Dass SFTP nach dem Update von 8.2 auf 8.4 nicht mehr funktionierte, ssh-logins dagegen schon, lag schlicht daran, dass beim Update in der sshd_config auf einmal
Subsystem sftp /usr/local/libexec/sftp-server
statt
Subsystem sftp /usr/libexec/sftp-server
drin stand.
Was leider ebenfalls nicht mehr funktioniert, ist der angehängte umask-Parameter
Subsystem sftp /usr/libexec/sftp-server -u 018
Der wirft nun nach dem Update von 8.2 -> 8.4 ein
sftp-server[72920]: fatal: Invalid umask "018"
in auth.log und ein Einloggen via SFTP funktioniert nicht.
Viele Grüße
testit
KobRheTilla
used register
Eine umask ist oktal, kann also niemals eine 8 enthalten ;-)
Versuch es mal mit der 027, oder eher noch 0027.
Rob
Versuch es mal mit der 027, oder eher noch 0027.
Rob