OpenBSD 7.7 erfolgreich installiert

Das kann ich nur bestaetigen. Meine Server und Router auf der Arbeit habe ich auch alle erfolgreich auf 7.7 aktualisiert. Wie immer lief alles sehr reibungslos. sysupgrade um das System zu aktualisieren, nach dem Reboot sysmerge um evtl. Aenderungen in den Configs zu aktualisieren, Upgrade Guide schauen, ob was von Hand angepasst oder entfernt werden muss und pkg_add -u um die Packages zu aktualisieren. Mein privates Notebook laeuft unter -current und ist daher immer auf dem aktuallen Stand und musste nicht aktualisiert werden.
 
Moin,

es kommt noch - wie immer - eine Ankündigung unter News die ich gerade vorbereite

Wir suchen noch immer jemanden der lust hätte das mit mir zu machen ;) - da scheint ihr beide ja prädestiniert :D
 
CommanderZed schrieb:
Moin,

es kommt noch - wie immer - eine Ankündigung unter News die ich gerade vorbereite

Wir suchen noch immer jemanden der lust hätte das mit mir zu machen ;) - da scheint ihr beide ja prädestiniert :D
Zum Vergrößern anklicken....
Klar, falls ich was uebersetzen soll, schreib mir am besten eine IGM hier im Forum. Dann koennen wir das irgendwie aufteilen. Ist ja schon immer so einiges an Text. Vor heute Mittag komme ich allerdings nicht dazu, da gleich ein Teams-Meeting in der Firma ansteht. :-)
 
Und ich habs auf einem Laptop gründlich verkackt, weil ich sysmerge falsch ausgeführt habe. Jetzt kommt beim booten bei allen zu ladenden daemons (failed) xyzsu: daemon: unknown class beim login kommt:
Code: 
Login: Failure to retrieve default class
init: default: unknown class
Ist da noch was zu retten?
 
Schau mal in /var/backups. Dort sollten (hoffentlich) Backups von den Configs angelegt worden sein. # ls -ltr /var/backups | tail -32

Es ist selten, dass sysmerge Aenderungen vorschlaegt. Man sollte immer erst d (diff) anzeigen lassen und wenn die Config eigene Aenderungen beinhalten, dann merge und dann blockweise l (left) oder r (right) festlegen, ob die Aenderungen auf der linken oder rechten Seite in die neue Config uebernommen werden sollen.
 
Zuletzt bearbeitet:
ich kann auf /var/backups nicht zugreifen, weil kein login möglich ist. Starte ich das system mit boot -s kann ich auch nicht auf das Verzeichnis zugreifen :(.
 
Tatzahn schrieb:
ich kann auf /var/backups nicht zugreifen, weil kein login möglich ist. Starte ich das system mit boot -s kann ich auch nicht auf das Verzeichnis zugreifen :(.
Zum Vergrößern anklicken....
Du musst die Filesysteme noch mounten. Versuche mal sowas wie # mount -a. Das mounted alle in /etc/fstab aufgefuehrten Filesysteme.
 
Zuletzt bearbeitet:
Du kannst Dir die Aenderungen mit diff anschauen. An deinem Beispiel:

Code: 
# diff etc_group.current etc_group.backup
89d88
< _dhcp6leased:*:116:
Der "Pfeil nach links" bedeutet, dass in etc_group_current folgender Eintrag hinzugekommen ist: _dhcp6leased:*:116:, welcher vorher nicht vorhanden war. current ist die neue und installierte Config und backup ist die vorherige Config, welche durch current ersetzt wurde.

Code: 
diff etc_group.backup etc_group.current
88a89
> _dhcp6leased:*:116:

Hier nochmal am gleichen Beispiel, nur die beiden Dateien wurden beim diff in der Reihenfolge vertauscht. Hier der "Pfeil nach rechts".

Anderes Beispiel:

Code: 
# diff etc_rc.current etc_rc.backup
1c1
< #     $OpenBSD: rc,v 1.580 2025/04/07 14:49:26 deraadt Exp $
---
> #     $OpenBSD: rc,v 1.576 2024/06/03 10:06:35 florian Exp $
52,54c52,66
<       [[ -s /etc/sysctl.conf ]] && sysctl -f /etc/sysctl.conf
<       update_limit -p maxproc   $(sysctl -n kern.maxproc)
<       update_limit -n openfiles $(sysctl -n kern.maxfiles)
---
>       # do not use a pipe as limits would only be applied to the subshell
>       set -- $(stripcom /etc/sysctl.conf)
>       while [[ $# > 0 ]] ; do
>               sysctl "$1"
>
>               case "$1" in
>               kern.maxproc=*)
>                       update_limit -p maxproc
>                       ;;
>               kern.maxfiles=*)
>                       update_limit -n openfiles
>                       ;;
>               esac
>               shift
>       done
233c245
<           $_relink/usr/libexec/sshd-auth $_relink/usr/bin/ssh-agent; do
---
>           $_relink/usr/bin/ssh-agent ; do

"Pfeil nach links" ist was in current hinzugekommen ist und "Pfeil nach rechts", was entfernt oder ersetzt wurde.

EDIT: Achja, falls Du dann etwas entdeckst, was das Booten verhindert, dann muessen die entsprechenden Configs in /etc geaendert werden und nicht in /var/backups. ;-)
 
Zuletzt bearbeitet:
Tatzahn schrieb:
Und ich habs auf einem Laptop gründlich verkackt, weil ich sysmerge falsch ausgeführt habe. Jetzt kommt beim booten bei allen zu ladenden daemons (failed) xyzsu: daemon: unknown class beim login kommt:
Code: 
Login: Failure to retrieve default class
init: default: unknown class
Ist da noch was zu retten?
Zum Vergrößern anklicken....
Hoert sich so an, als wenn Du deine /etc/login.conf beim manuellen sysmerge geschreddert hast. Evtl. fuehrst Du mal ein # diff /etc/login.conf /var/backups/etc_login.conf.backup durch. Notfalls kopierst du einfach die etc_login.conf.backup nach /etc/login.conf und probierst dann ein erneutes booten.

Das Einzige, was in der /etc/login.conf hinzugekommen ist, ist dieses hier:

Code: 
# diff /etc/login.conf /var/backups/etc_login.conf.backup
1c1
< # $OpenBSD: login.conf,v 1.26 2025/02/28 20:21:07 sthen Exp $
---
> # $OpenBSD: login.conf,v 1.24 2023/11/12 14:41:41 robert Exp $
87,94d86
<       :tc=default:
<
< #
< # Building LLVM in base requires higher limits
< #
< build:\
<       :datasize-max=1843M:\
<       :datasize-cur=1843M:\

Das kannst Du fuer den Fall, dass es daran lag und mit der alten config bootet, auch nachtraeglich von Hand eintragen.

EDIT: Du kannst auch unter /var/sysmerge/backups/etc schauen, was Du durch sysmerge geaendert hast.
 
Danke für die Hilfe. Ich hab den Weg mit dem Holzhammer gewählt, alle relevanten Dateien mir usb-stick gesichert und installiere gerade neu. Wenn das System steht und ich die Daten wieder übertragen habe, ist der nächste Rechner dran.
 
Ich habe jetzt noch zweimal OpenBSD erfolgreich auf die aktuelle Version gehoben und mich NICHT nocmal bei sysmerge verrannt :). Ich bekomme jetzt bei der Neuinstallation immer folgende Fehlermeldung bei pkg_add ausgegeben:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LC_ALL = (unset),
LC_CTYPE = (unset),
LC_NUMERIC = (unset),
LC_COLLATE = (unset),
LC_TIME = (unset),
LC_MESSAGES = (unset),
LC_MONETARY = (unset),
LANG = "de_DE.UTF8"
Zum Vergrößern anklicken....
wo kann ich das bereinigen? Handbook und man sind da iwi nicht sehr aufschlussreich. :(
 
Hast Du irgendwo im System was an der locale geaendert? Mit welchem User fuehrst Du pkg_add -u denn aus? Gib mal im Terminal locale ein und poste den Output bitte hier?

Code: 
$ locale
LANG=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

Ich habe beispielsweise in meiner ~/.profile folgendes gesetzt: export LANG=en_US.UTF-8
 
midnight schrieb:
Hast Du irgendwo im System was an der locale geaendert? Mit welchem User fuehrst Du pkg_add -u denn aus? Gib mal im Terminal locale ein und poste den Output bitte hier?

Code: 
$ locale
LANG=en_US.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

Ich habe beispielsweise in meiner ~/.profile folgendes gesetzt: export LANG=en_US.UTF-8
Zum Vergrößern anklicken....
pkg_add führe ich im terminal als root aus. Ansonsten ist das ja eine Neuinstallation, wo ich bisher lediglich zu Anfang die Tastaturbelegung festgelegt habe. In .xsession habe ich noch LANG=de_DE.UTF8 angegeben.

locale ergibt:
Code: 
locale
LANG=de_DE.UTF8
LC_COLLATE="C"
LC_CTYPE="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=
 
Hm schwer zu sagen. Evtl. musst Du noch das noch exportieren mit export LANG=de_DE.UTF8. Du startest deinen wm aber nicht als root, oder? Ich habe export LANG... nur beim User gesetzt und nicht bei root und starte den wm auch immer nur als User.
 
midnight schrieb:
Hm schwer zu sagen. Evtl. musst Du noch das noch exportieren mit export LANG=de_DE.UTF8. Du startest deinen wm aber nicht als root, oder? Ich habe export LANG... nur beim User gesetzt und nicht bei root und starte den wm auch immer nur als User.
Zum Vergrößern anklicken....
Nein ich logge mich nur als User ein. Danach für pkg_add und co im terminal als su.Kein doas oder sudo.
 
Sorry Leute. Das ist heute mein Katastrophentag. Ich hab auf dem anderen Laptop jetzt ein größeres Problem mit pkg_add -u nach dem sysupgrade. Ich mach mal einen neuen Thread auf :(.
 
midnight schrieb:
Hm schwer zu sagen. Evtl. musst Du noch das noch exportieren mit export LANG=de_DE.UTF8. Du startest deinen wm aber nicht als root, oder? Ich habe export LANG... nur beim User gesetzt und nicht bei root und starte den wm auch immer nur als User.
Zum Vergrößern anklicken....
Achtung!

Code: 
export LANG=de_DE.UTF8

ist falsch geschrieben. Es muß

Code: 
export LANG=de_DE.UTF-8

heissen. Sorry, ich wollte nicht klugscheissen, aber das ist wichtig!
 
Gut aufgepasst, Sherlock. Da hast Du voellig recht. Das kann schon das Problem mit der locale warning gewesen sein. :-)
 
midnight schrieb:
Hm schwer zu sagen. Evtl. musst Du noch das noch exportieren mit export LANG=de_DE.UTF8. Du startest deinen wm aber nicht als root, oder? Ich habe export LANG... nur beim User gesetzt und nicht bei root und starte den wm auch immer nur als User.
Zum Vergrößern anklicken....
.profile Einträge haben wohl Einfluss auf den Terminal, auch wenn er mit root-Rechten genutzt wird. Die Entwickler haben wohl da eine Warnung eingebaut, falls da Schlumpse wie ich nicht für Ordnung bei sich sorgen. :D
bsdfreak schrieb:
Achtung!

Code: 
export LANG=de_DE.UTF8

ist falsch geschrieben. Es muß

Code: 
export LANG=de_DE.UTF-8

heissen. Sorry, ich wollte nicht klugscheissen, aber das ist wichtig!
Zum Vergrößern anklicken....
Das ist keine Klugscheißerei sondern Fehlerbereinigung - Danke.

#locale sieht jetzt so aus:
Code: 
locale
LANG=de_DE.UTF-8
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_ALL=de_DE.UTF-8
Und alles ist gut. :)
 
Tatzahn schrieb:
.profile Einträge haben wohl Einfluss auf den Terminal, auch wenn er mit root-Rechten genutzt wird.
Zum Vergrößern anklicken....
So ganz allgemein würde ich jedem empfehlen sich für eine der Unmengen Shells da draußen entscheiden und sich nach und nach eine eigene Config zu bauen. Ich nutze zum Beispiel seit gut 8 Jahren auf praktisch allen Systemen die zsh, nachdem ich viele Jahre lang ntcsh-Nutzer war und die Außenseiter-Rolle endlich los werden wollte. Die (gerade frisch überarbeitete) Config ist hier, sie unterscheidet zwischen root und unprivilegiertem Nutzer:


Nun ist eine Shell, die nicht im Basisystem ist, auf den BSDs gerade für root so eine Sache. Worst Case zerschießt man sich die aus den Ports bzw. Paketen kommende Shell und kommt dann nicht mehr ohne unschönes Gebastel über den Single User Mode in den root-Account. Eine Möglichkeit sich dagegen zu schützen ist, sich einen zweiten User mit UID 0 anzulegen. Traditionell heißt der toor: https://en.wikipedia.org/wiki/Toor_(Unix)

Dafür habe ich eine extra Konfiguration. Die ist für FreeBSDs ash-Shell und nicht mit OpenBSDs ksh-Abkömmling kompatibel. Trotzdem:


Vielleicht noch als Anmerkung: Ich schreibe ash, aber die verschiedenen ash-Derive sind inzwischen soweit auseinandergelaufen, dass sie kaum mehr miteinander vergleichbar sind. Debians dash ist z.B. eine ganz andere Shell als FreeBSDs ash, auch wenn sie die gleiche Abstammung haben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben