Upgrade auf -current

nihonto

Well-Known Member
Moinmoin:)!

Ich hätte da mal eine Verständnissfrage zum Wechsel von -stable zu -current. Ich habe das gestern mal gemacht, bin dabei auf die Nase gefallen und möchte jetzt mal ein wenig Ursachenforschung betreiben:D.

Meine Frage wäre: Bin ich evtl. schon grundsätzlich falsch vorgegangen?

Und so hab' ich's gemacht:

1. bsd.rd aus dem "snapshot"-branch von ftp.openbsd.org gezogen, nach / verschoben und den alten bsd.rd in bsd.rd_old umbenannt

2. Neu gebootet und eingegeben "boot> bsd.rd"

3. Bei der Frage, ob ich (I)nstallieren oder (U)pgraden möchte, das Upgrade ausgewählt

4. Upgrade durchgezogen, neu gebootet und mergemaster durchlaufen lassen, damit /etc auch auf dem aktuellen Stand ist.

So, hier dann die Frage: Nun müsste ich doch einen Snapshot installiert haben, oder?

5. Gemäß FAQ (5.3.3):

# cvs -d$CVSROOT checkout -P src

Das Gleiche mit ports und xenocara und dann noch jeweils ein

# cvs -d$CVSROOT up -Pd

durchlaufen lassen.

6. Gemäß FAQ (5.3.4) habe ich dann einen Kernel erzeugt:

# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make depend && make
[... jede Menge Ausgabe ...]
# make install

und das System neu gestartet.

Tja, und dann war Hängen im Schacht. Der Teil des Bootprozesses, der in weißer Schrift auf blauem Grund verläuft ist glatt durchgelaufen, aber dann kamen sehr schnell Fehlermeldungen en masse (unter anderem irgendwas mit tty, die nicht gefunden wurden, hab's leider nicht notiert). Konnte dann nur noch über den Power-Knopf das Laptop abschalten.
Hab' dann die 4.3 CD gegriffen und -release re-installiert.

Tja, und jetzt stell' ich mir die Frage: Bin ich schon grundsätzlich falsch an das Upgrade von -stable auf -current herangegangen, oder hab' ich evtl. einfach nur 'nen verbockten Snapshot erwischt?
 
den zweiten schritt unter 5. hättest du weglassen können, da du kurz vorher nen checkout von dem branch gemacht hast.

zum testen könntest du auch vom snapshot aus mal installieren und schauen, was er dann macht (damit ersparst du dir dann auch die schritte, das etc. upzudaten bzw. die restlichen änderungen für -current).
ohne fehlermeldung, ist das natürlich auch schwierig, zu diagnostizieren, was denn evtl. schief gelaufen ist...
 
den zweiten schritt unter 5. hättest du weglassen können, da du kurz vorher nen checkout von dem branch gemacht hast.

Ja, hatte ich mir fast schon gedacht, wollte aber auf Nummer sicher gehen - interessanterweise wurde da auch noch so einiges geladen:confused:

zum testen könntest du auch vom snapshot aus mal installieren und schauen, was er dann macht (damit ersparst du dir dann auch die schritte, das etc. upzudaten bzw. die restlichen änderungen für -current).

Würde ich sofort machen - wenn ich 'nen Testrechner hätte;). Aber 'ne richtige Neu-Installation mit 'nem Snapshot möchte ich eher vermeiden, da mein OpenBSD grade ganz nett eingerichtet ist. Außerdem schwitz' ich jedesmal Blut und Wasser beim Partitionieren - das ist sowas von unübersichtlich.

ohne fehlermeldung, ist das natürlich auch schwierig, zu diagnostizieren, was denn evtl. schief gelaufen ist...

Da haste natürlich recht:D! Ich werd's wohl jetzt am WE nochmal probieren, und wenn's wieder schief geht, notier' ich mir diesmal die letzten Fehlermeldungen.
 
wieso partitionieren? wenn du partitioniert hast und ein disklabel vorhanden ist, brauchst das doch nicht nochmal machen? einfach fdisk und disklabel beenden und gut ist. nach disklabel wirst du dann noch nach den mountpoints gefragt und nen newfs drübergebügelt (/home dann vlt. später von hand in die fstab eintragen ;)).
das mit dem snapshot installieren hättest du anstatt dem release mal testen können (da ich das für eine neuinstallation gehalten habe). der aufwand wär weniger gewesen (s. fdisk und disklabel) und die packages aus den snapshots wären auch relativ aktuell (für deinen $PKG_PATH) zum snapshot.
 
4. Upgrade durchgezogen, neu gebootet und mergemaster durchlaufen lassen, damit /etc auch auf dem aktuellen Stand ist.
Seit 4.4 (bzw. 4.3-current) kannst du hierfür auch das von OpenBSD angebotene sysmerge(8) benutzen.
 
Seit 4.4 (bzw. 4.3-current) kannst du hierfür auch das von OpenBSD angebotene sysmerge(8) benutzen.

Danke für den Tipp:)! Hatte ich auch von gelesen, aber schon wieder vergessen. Hat gestern Abend beim Upgrade auf 'nen Snapshot prima funktioniert.
 
Ich hab' jetzt ein paarmal versucht, von einem Snapshot mittels cvs auf -current upzudaten. Allerdings ist das jedesmal gescheitert - sogar, wenn ich mir nur den Snapshot installiert habe und den Kernel neu kompiliert habe (ohne jede Veränderung):confused:.

Irgendwas mach' ich falsch, aber was?

Nochmal mein Vorgehen:

Ausgangspunkt: OpenBSD 4.3-stable mit unverändertem GENERIC-Kernel.

1. Ich besorge mir einen Ramdisk-Kernel von hier: ftp://openbsd.informatik.uni-erlangen.de/pub/OpenBSD/snapshots/i386

2. Kopiere den Ramdisk-Kernel nach / und reboote

3. Ich wähle (U)pgrade, gehe all weiteren Punkte durch und lasse das System von oben genannter ftp-Quelle ziehen.
Danach reboote ich das System.

4. sysmerge -a

5. dmesg zeigt:

Code:
OpenBSD 4.3-current (GENERIC) #926: Fri Jun 13 07:55:49 MDT 2008
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

6. In meiner .profile steht:

Code:
export CVSROOT=anoncvs@anoncvs.ca.openbsd.org:/cvs

7. Update von src, ports und xenocara

Code:
# cd /usr
# cvs -d$CVSROOT checkout -P src ports xenocara

8. Kernel neu bauen:

Code:
# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make depend && make
    [... blablubb ...]
# make install

9. Reboot

Interessanterweise bootet dann aber ein "OpenBSD 4.3-stable (GENERIC)" Kernel:eek:

Und der verreckt natürlich! Zum Schluss kommt nur noch:

Code:
init: can't exec getty '/usr/libexec/getty' for port /dev/ttyC<verschiedene_zahlen>: No such file or directory

und wiederholt sich ad infinitum.

Hat evtl. jemand eine Idee, was ich da falsch mache?
 
Code:
# cd /usr
# cvs -d$CVSROOT checkout -P src ports xenocara

Hattest du bereits einen Sourcetree für OpenBSD 4.3-stable in /usr/src? Führe einfach mal folgenden Befehl aus:

Code:
# cat /usr/src/CVS/Tag

Ich schätze mal, dass für dich "TOPENBSD_4_3" erscheint. Wenn das der Fall ist, dann hast du einfach den falschen Sourcetree für dein -current-System. Wenn du -current folgst, dann darf die Datei nicht vorhanden sein (manuell löschen ist selbstverständlich der falsche Weg!).

Führe folgenden Befehl aus, um alle Tags und Optionen zurückzusetzen und die aktuellen Dateien herunterzuladen:

Code:
# cd /usr/src; cvs update -AP
 
Hattest du bereits einen Sourcetree für OpenBSD 4.3-stable in /usr/src? Führe einfach mal folgenden Befehl aus:

Code:
# cat /usr/src/CVS/Tag

Ich schätze mal, dass für dich "TOPENBSD_4_3" erscheint. Wenn das der Fall ist, dann hast du einfach den falschen Sourcetree für dein -current-System. Wenn du -current folgst, dann darf die Datei nicht vorhanden sein (manuell löschen ist selbstverständlich der falsche Weg!).

Jepp, hast recht:

Code:
/home/nihonto $ cat /usr/src/CVS/Tag                                           
TOPENBSD_4_3

Das bedeutet aber auch im Klartext, dass ein "checkout" der Sourcen nicht die alten Sourcen überschreibt, oder? Davon war ich nämlich ausgegangen.

Und wieso wäre das manuelle Löschen der falsche Weg? Ich hätte gedacht, löschen und dann ein neuer checkout würde reichen?!

Führe folgenden Befehl aus, um alle Tags und Optionen zurückzusetzen und die aktuellen Dateien herunterzuladen:

Code:
# cd /usr/src; cvs update -AP

Ok, versuche ich mal - vielen Dank:cool:;)!!!
 
Das bedeutet aber auch im Klartext, dass ein "checkout" der Sourcen nicht die alten Sourcen überschreibt, oder?

Wenn du "checkout" mit einem bestehenden Sourcetree verwendest, dann ist es im Grunde identisch mit "update".

Und wieso wäre das manuelle Löschen der falsche Weg? Ich hätte gedacht, löschen und dann ein neuer checkout würde reichen?!

Ich bezog mich damit auf die CVS/Tag-Datei. Den kompletten Sourcetree zu löschen würde natürlich auch helfen. ;)
 
Ok, das hat funktioniert:D!

Nachdem ich

Code:
# cd /usr/src; cvs update -AP

ausgeführt hatte, ließ sich auch ein -current-Kernel bauen (GENERIC). Allerdings hat's dann beim Bau des Userlands gehakt:rolleyes:.

Wollte gemäß FAQ so vorgehen:

Code:
# rm -rf /usr/obj/*
# cd /usr/src
# make obj
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
# cd /usr/src
# make build

Erst endete das "make obj" mit dem Hinweis, dass die neue WPA-Funktionalität nicht erkannt wird. Daraufhin hab' ich nochmal die Sourcen upgedatet, Kernel neu gebaut und bin wieder ans Userland gegangen.
Diesmal sah auch alles so aus, als ob es funktionieren würde. Leider ist dann das "make build" mit 'ner Fehlermeldung bezüglich ssh abgebrochen (nachdem "make build" schon etwa 'ne Stunde gelaufen war:ugly:).

Versuche es grade nochmal - mal sehen, ob's jetzt klappt:D?!
 
Hmmm, nö, bricht wieder ab:

Code:
cc -O2 -pipe -g -DKRB5 -I/usr/include/kerberosV -DGSSAPI -I/usr/src/usr.bin/ssh/sshd/..  -DLIBWRAP  -c /usr/src/usr.bin/ssh/session.c
/usr/src/usr.bin/ssh/session.c: In function `do_rc_files':
/usr/src/usr.bin/ssh/session.c:1033: error: syntax error before '<<' token
/usr/src/usr.bin/ssh/session.c: At top level:
/usr/src/usr.bin/ssh/session.c:1054: error: syntax error before "else"
/usr/src/usr.bin/ssh/session.c:106: warning: `do_authenticated2' used but never defined
/usr/src/usr.bin/ssh/session.c:108: warning: `session_pty_req' used but never defined
*** Error code 1

Stop in /usr/src/usr.bin/ssh/sshd (line 92 of /usr/share/mk/sys.mk).
*** Error code 1

Stop in /usr/src/usr.bin/ssh (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/src/usr.bin (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/src (line 48 of /usr/share/mk/bsd.subdir.mk).
*** Error code 1

Stop in /usr/src (line 73 of Makefile).

Die Fehlermeldung sagt mir nicht wirklich was. Frage mich jetzt, ob das halt ein "typischer" Kollateralschaden des Betriebs von -current ist, oder ob's an mir liegt:confused:.
 
Code:
/usr/src/usr.bin/ssh/session.c:1033: error: syntax error before '<<' token

Ganz einfach: Du hast die Patches von der errata43.html-Seite eingebunden, statt dem -stable-CVS zu folgen. Dementsprechend enthält die Datei einen Konflikt, den du manuell beheben müsstest (oder du löschst die Datei einfach und CVS bezieht sie für dich neu wenn du nochmal "update" durchführst).

Also:

Code:
# cd /usr/src/usr.bin/ssh
# rm channels.c session.c 
# cvs update
 
Ganz einfach: Du hast die Patches von der errata43.html-Seite eingebunden, statt dem -stable-CVS zu folgen. Dementsprechend enthält die Datei einen Konflikt, den du manuell beheben müsstest (oder du löschst die Datei einfach und CVS bezieht sie für dich neu wenn du nochmal "update" durchführst).

Also:

Code:
# cd /usr/src/usr.bin/ssh
# rm channels.c session.c 
# cvs update

Klasse Tipp, das hatte ich schon wieder total vergessen:o. Jetzt ist alles glatt durchgelaufen - dicken Dank dafür:cool:;)!
 
Back
Top