FreeBSD-Installation übertragen?

H

Hubert

Well-Known Member
Ich habe ein FreeBSD 6.1 komplett aus den Sourcen neu gebaut, also Kernel und Userland. Jetzt ist es aber so, dass ich diesen Vorgang nicht auf demselben Rechner durchführen konnte, weil der zu klein ist (insbesondere hat er zu wenig Festplattenplatz). Ich habe daher das System auf einem anderen Rechner inklusive der Sourcen installiert und dort Kernel und Userland neu gebildet. Die einzige Änderung, die ich vor dem Neu-Bilden an den Sourcen vorgenommen habe, ist die Änderung der Limits UT_NAMESIZE und MAXLOGNAME.

Jetzt ist aber meine Frage, wie ich die geänderten Dateien auf das kleine System übertragen kann. Gibt es da ein offizielles Verfahren?

Mein bisheriger Ansatz ist der folgende: Ich habe auf beiden Systemen rsync installiert und würde dann auf dem großen Rechner folgenden Befehl ausführen:

Code: 
rsync --existing --archive --exclude "/dev" --exclude "/etc" --exclude "/root" --exclude "/home" --exclude "/var/run" --exclude "/var/log" --exclude "/var/db" --exclude "/var/spool" --exclude "/tmp" --exclude "/var/tmp" --exclude ".snap" --exclude "/entropy" / kleinerRechner:/

Ich schrecke jetzt aber noch ein wenig davor zurück. Ist das so machbar?
 
Hubert schrieb:
Code: 
rsync --existing --archive --exclude "/dev" --exclude "/etc" --exclude "/root" --exclude "/home" --exclude "/var/run" --exclude "/var/log" --exclude "/var/db" --exclude "/var/spool" --exclude "/tmp" --exclude "/var/tmp" --exclude ".snap" --exclude "/entropy" / kleinerRechner:/

Ich schrecke jetzt aber noch ein wenig davor zurück. Ist das so machbar?
Zum Vergrößern anklicken....

Ich mache mittels rsync ein Backup zwischen zwei DOS-Partitionen (FreeBSD Slices).

Optimierungen:
1. an Stelle der ganzen Excludes diese in eine Datei schreiben und mittels --exclude-from=<Dateiname> einbinden
2. sicherstellen, dass die fehlende Verzeichnisse nachträglich angelegt werden
3. und zwar mit den entsprechenden Rechten (1777 bei /tmp und /var/tmp)
4. IMMER das Ganze zuerst mit -n (--dry-run) laufen lassen.
5. ggf. Dateien wie /etc/fstab, /etc/rc.conf, ... auf das Zielsystem anpassen
6. ACLs und file flags werden nicht übertragen, es gibt zwar Patches die zwar im Source Tree mitgeliefert werden, aber der Portmainter bindet diese nicht ein

HTH
 
Zuletzt bearbeitet von einem Moderator:
Das offizielle Verfahren ist /usr/obj auf der build-Maschine per NFS zu exportieren und auf dem Client einzuhängen. Und dann make installkernel/make installworld.
 
Danke für eure tollen Antworten :)

Ich verspreche, es beim nächsten Mal gleich richtig zu machen ;) aber für dieses eine Mal reicht es mir, die geänderten Dateien einfach zu übertragen. Ich habe mich jetzt doch einfach mal getraut, den rsync-Befehl anzuwenden, und es scheint alles wie gewünscht zu funktionieren. Das würde mir erstmal reichen.
 
Das mit dem "scheinen" ist so ne Sache ... du muesstes eigentlich Fehlermeldungen erhalten haben, dass ein paar Dateien nicht ersetzt werden konnten, wegen dem SCHG-Flag.

NFS ist immer am bequemsten, aber Elessars Antwort ist nur halb korrekt: Es wird nur unterstuetzt, dass der "Buildhost" die Daten via NFS auf den Zielrechner schreibt!
Aber keine Sorge, ich (und viele, viele andere) machen es genau anders herum. Also mount vom "Buildhost" und lokales Ausfuehren von make installworld

Du kannst dir ja auch mal release(7) ansehen, wenn du deinen eigenen FreeBSD-Release bauen willst.
 
MrFixit schrieb:
Das mit dem "scheinen" ist so ne Sache ... du muesstes eigentlich Fehlermeldungen erhalten haben, dass ein paar Dateien nicht ersetzt werden konnten, wegen dem SCHG-Flag.
Zum Vergrößern anklicken....

Mir sind keine Fehlermeldungen aufgefallen.

Ich habe aber eine Vermutung, warum es keine Fehlermeldungen gegeben hat. Vermutlich sind die Dateien auf beiden Systemen identisch, weil sie sich auch auf dem Build-System nicht verändert haben. Ich bin nämlich vor "make installworld" nicht in den single user mode gegangen. Und dann konnten vermutlich die Dateien mit schg-Flag schon auf dem Build-System selbst nicht ersetzt werden.

Ich werde das überprüfen.

Ich sehe, ich muss noch viel lernen :)

Vielen dank auf jeden Fall ;)
 
Hubert schrieb:
[...]
Ich bin nämlich vor "make installworld" nicht in den single user mode gegangen.
[...]
Zum Vergrößern anklicken....

Singleusermod ist zwar empfohlen aber nicht zwingend, wenn Du ein update via ssh (remote) machst und keinen Seriellen zugriff hast, dann hast Du gar keine andere Schanks.

Aron
 
Das sollte aber einfacher ohne Sicherheitslücke (=NFS) und Zusatzsoftware (rsync) wie folgt gehen:

Man kompiliert seine World und den Kernel, kopiert dann /usr/src und /usr/obj auf die Zielmaschine (scp, tar ...) und führt dort nur ein installworld und installkernel aus.
 
rosa schrieb:
Singleusermod ist zwar empfohlen aber nicht zwingend, wenn Du ein update via ssh (remote) machst und keinen Seriellen zugriff hast, dann hast Du gar keine andere Schanks.
Zum Vergrößern anklicken....

Naja, und wie löst man das das Problem mit den Dateien, die nicht ersetzt werden können? schg-Flag entfernen, Datei ersetzen und schg-Flag wieder setzen (was ohnehin nur bei einem Securelvel von < 1 funtioniert)?
 
Zuletzt bearbeitet:
Na ja Du kannst jetzt nen "wilden" Skript schreiben der das löst oder einfach einer der Möglichkeiten die hier beschrieben sind nutzen und es "sauber" lösen. Mittels rsync ist auf jeden fall kein stück sauber.
 
rosa schrieb:
Na ja Du kannst jetzt nen "wilden" Skript schreiben der das löst oder einfach einer der Möglichkeiten die hier beschrieben sind nutzen und es "sauber" lösen. Mittels rsync ist auf jeden fall kein stück sauber.
Zum Vergrößern anklicken....

Mh, mir ist der Kontext jetzt unklar, worauf bezieht sich das jetzt?

Um aber kurz darauf einzugehen: Ich habe die rsync-Methode verwendet bevor ich gewusst habe wie es richtig geht.

Meine letzte Frage war aber, wie "make installworld" vorgeht, wenn man nicht in den Single User Mode geht, denn die Dateien mit gesetztem schg-Flag können ja in dem Fall auch nicht so ohne weiteres ersetzt werden.
 
Mit CHFLAGS(1) kannst Du die Dateien so modifizieren das sie ersetz bar sind, erst ab einem securelevel ab 1 (INIT(8)) geht dies nicht mehr.
Das war doch deine Frage?
 
rosa schrieb:
Mit CHFLAGS(1) kannst Du die Dateien so modifizieren das sie ersetz bar sind, erst ab einem securelevel ab 1 (INIT(8)) geht dies nicht mehr.
Das war doch deine Frage?
Zum Vergrößern anklicken....

Nein. Dass man das Flag vor dem Ersetzen entfernen kann, wenn der Securelevel < 1 ist, habe ich selbst vor ein paar Postings gesagt. Das hast du dann vermutlich übersehen oder so.

Meine Frage war, was "make installworld" macht (d.h. wie es mit dem Problem der geschützten Dateien umgeht), wenn man nicht vorher in den Single User Mode bootet.

Auf diese Frage bin ich eigentlich nur gekommen, weil du gesagt hattest, dass der Single User Mode nicht unbedingt zwingend notwendig ist. Aber angesichts der Dateien mit schg-Flag müßte das doch eigentlich notwendig sein - es sei denn, "make installworld" würde von sich aus versuchen, das Flag vor dem Ersetzen zu entfernen und danach wieder zu setzen.

Die Frage ist im Grunde genommen nicht so wichtig, weil man auf jeden Fall auf der sicheren Seite ist, wenn man vorher in den Single User Mode bootet, wie es auch in der Dokumentation steht. Es hatte mich nur prinzipiell interessiert, ob das Installationsskript von sich aus versucht, mit gesetzten schg-Flags umzugehen, denn möglich wäre es ja bei einem Securelevel < 1.
 
Natürlich:

Code: 
> find /usr/src -name "Makefile*" -exec grep chflags {} \; | wc -l 
    25
 
Soweit ich das nach einem kurzem Blick sehen kann, entfernen die Skripte eventuell vorhande schg-Flags, wenn Dateien gelöscht werden sollen, weil rm(1) die Flags nicht von sich aus vorher entfernt.

Zum Ersetzen von Dateien hingegen reicht es, install(1) zu verwenden, das im Gegensatz zu cp(1) vorhandene schg-Flags vor dem Ersetzen entfernt, was ich auch durch einen kleinen Test bestätigen konnte.
 
hihi nächstes mal gleich selber ein Blick reinwerfen? *fg*

Grüße Aron, der jetzt ins bett geht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben