Zwei Fragen zum Umzug eines Systems

[Errorsmith]

Hi

Ich ersetze gerade eine defekte Platte in einem FreeBSD Rechner.

Erstens:
Im manual ist die Rede davon das ich, um ein Dateisystem auf eine neue Platte umzuziehen das da eingebe:

dump -0 -af - / | restore -rf -

Soweit so gut.
Kopiert er dann auch /usr und /var die jeweils auf anderen Partitionen liegen?

Zweitens:
Bekomm ich dann auch den Bootloader und so weiter auf die neue Platte - und wenn nein: Wie stell ich das an?

Grüße,
Errorsmith

[Illuminatus]

du musst für jedes slice/mountpoint die dump-restore Prozedur jeweils durchführen.
Ergo muss auch deine neue Ersatzfestplatte, welche das Ziel ist, entsprechend partitioniert und formatiert sein! Mit boot0cfg kannst du den Bootloader auf die Ersatzfestplatte schreiben. Wenn du es möglichst einfach haben möchtest, starte doch einen Installer von deiner aktuell benutzten FreeBSD Version, beginne die Einrichtung der neuen Festplatte, und brich das Setup ab - bzw. formatiere die neuen Mountpoints.
Labels werden dir später beim Mounten behilflich sein, den Überblick zu behalten

[Errorsmith]

Also muß ich mir keine sorgen darum machen das er auf mein neues / auch gleich die anderen mountpoints mit drauf kopiert?
Super, darum ging es mir nämlich

boot0cfg werd ich mir dann entsprechend auch ansehen.

Danke,

Errorsmith

[cla]

Zitat von Errorsmith

Also muß ich mir keine sorgen darum machen das er auf mein neues / auch gleich die anderen mountpoints mit drauf kopiert?

Nein, Illuminatus hat genau das Gegenteil behauptet.

Wenn du also separate Mountpoints für
/
/usr
/home
/var
hast, musst du alle vier einzeln von A nach B befördern.

Mit anderen Worten: Jeder separate Mountpoint muss behandelt werden. Wenn du jetzt allerdings alles in einem Mountpoint drinliegen hast, dann brauchst du natürlich nur diesen einen Übertragen.

[Errorsmith]

nein passt schon, das ist genau was ich wollte (und vermutet habe).

Danke und Grüße,

Errorsmith
(geht nun basteln)

[pit234a]

Ist schon etwas älter, aber ich stelle das mal wieder hier ein, weil es dieses Thema doch streift.
Da wird auch ein bootbares Medium erstellt und ein Filesystem angelegt.
Die Installation fällt bei dir natürlich weg, aber wie ein Filesystem auf einem Medium erstellt werden kann, dieses Bootbar angelegt wird und dann eingebunden werden kann, um dorthin Daten zu transportieren, ist evtl doch interessant. Gerade auch die Möglichkeit, diese Dateisysteme zu Labeln, zu benennen und dann die fstab so zu ändern, dass alles fertig ist und bei nächsten Neustart direkt in Aktion kommt ist interessant.

Das habe ich so ähnlich gemacht, als ich meinen Stick kopierte, auf dem mein System installiert ist. Ich wollte eine Kopie und einiges ist auch auf anderen Medien zu finden. Die komplette Kopie legte ich zur Laufzeit an und korrigierte dann meine fstab und beim nächsten boot konnte ich den neuen Stick nutzen.
Das hat einige Vorteile gegenüber dd, das im Zweifel natürlich Wunder wirkt und auch den MBR mitnimmt.
FreeBSD dd hatte immer nur eine bs von >= 512 gekonnt, was ein echter Nachteil gegenüber Linux dd ist. Ich meine, es gibt da sdd in den Ports und dass ich das schon erfolgreich benutzt habe. Mit bs < 512 lassen sich die Teile des MBR ohne Partitionstabelle kopieren und das ist immer gut, die zu haben.

Building bootable FreeBSD/i386 images
From time to time I hear people complain at how hard it is to build an image from the FreeBSD sources. This week, I'll explain how I built a bootable i386 image on a USB flash device and also make some observations about the results.

Recently, I needed to create a bootable i386 image. The easiest way was to build one on my amd64. Here's what I did. I setup my environment for the build (steps 1-3), built FreeBSD/i386 userland and kernel (steps 4 and 5), prepared the flash (steps 6-11), installed userland and the kernel (steps 12 and 13), added the extra files needed for boot (steps 14-18). The detailed commands follow:

setenv MAKEOBJDIRPREFIX /blah
setenv TARGET i386
setenv TARGET_ARCH i386
make buildworld
make buildkernel KERNCONF=GENERIC
fdisk -I da0
fdisk -B da0
bsdlabel -w da0s1 auto
bsdlabel -B da0s1
newfs /dev/da0s1a
mount /dev/da0s1a /mnt
make installworld DESTDIR=/mnt
make installkernel DESTDIR=/mnt KERNCONF=GENERIC INSTALL_NODEBUG=t
make distrib-dirs DESTDIR=/mnt
make distribution DESTDIR=/mnt
echo /dev/da0s1a / ufs rw 1 1 > /mnt/etc/fstab
echo ifconfig_DEFAULT=DHCP > /mnt/etc/rc.conf
echo hostname=demo >> /mnt/etc/rc.conf

I put all this on an SD card and inserted that into an usb adapater and booted the laptop with it. FreeBSD's base system isn't too big these days, only 205MB for a full system.

% df /mnt
Filesystem 1024-blocks Used Avail Capacity Mounted on
/dev/da0s1a 484822 205570 240468 46% /mnt

This can easily be trimmed, but with a 512MB SD card for $5 at Office Max, there's little point in trimming for the project I needed the flash for. I just needed something that I could boot to transition my FreeBSD/amd64 laptop to a FreeBSD/i386 laptop.

If one needed to reduce the amount of space used by an installation, then there's a number of options than can be used to reduce the footprint of the system. In my experience, it is best to build everything without these options, then use the WITHOUT_* options on the installworld step to keep the image size down. It is easy to cut FreeBSD's footprint in half with these options. In addition, the kernel is 28MB with all its modules, and this can easily be reduced below 5MB in most cases.

nanobsd can be used to automate this process, as can TinyBSD. I'll save for another column the techniques I have used in the past to reach 16MB.
Posted by Warner Losh
at 11:46 PM

9 comments:
Destari said...

Also, in many cases, removable devices can boot with a different device name than it did originally. For instance, it may come up as da0, or da1, or daX, sometimes even adX (think: virtual machines).
In these cases, I label my UFS file system while doing the newfs command with the -L option:

newfs -L "usbroot" /dev/...

or something similar. Then, instead of using /dev/daXXX in the /etc/fstab, I use:

/dev/ufs/usbroot ...

and I also make sure I add GEOM_LABEL into my kernel config (or load as a module). It's relatively small, and very useful.

[Crest]

Ich würde zu gpart raten, weil es einheitlich für alle Schemata funktioniert und imo die freundlichere Syntax hat.

[Errorsmith]

Ich hab gpart benutzt. hat auch soweit alles funktioniert, allerdings beim dump / restore ist irgendwas schief gelaufen oder die platte ist währenddessen dann den Heldentod gestorben. Jedenfalls hab ich bei der Aktion /var komplett verloren...

*seufz*

Also doch neu installieren

[Crest]

Ist die Platte an einem Hardwareschaden oder falschen Parametern gestorben?

[Errorsmith]

Hardwareschaden... Sie klickt nur noch. Wird im BIOS nicht mehr erkannt. Ich denke mal das dump hat ihr den Rest gegeben. Ich hatte sie ja wegen defekten Sektoren getauscht.

Grüße, Errorsmith

[Illuminatus]

aber das ist doch kein Problem, nimm einfach die Version von deinem letzten vollständigen Backupsatz

[Errorsmith]

das beInhaltet leider nicht alles. Unter anderem fehlt mir die PortsDatenbank und das Sambazeug. Die ldap Sachen Hab ich noch. Da muß ich nur die letzten Änderungen rekonstruieren. Naja... Neu installieren ist vielleicht übertrieben. Aber wird ein gutes Stück Arbeit.