Meine Arbeitsumgebung präsentierte sich in Form eines Ubuntu 7.10. Mein Zielobjekt war ein Hetzner DS 3000 (gemietet 01/2008). Das gewünschte Betriebssystem hört auf den Namen FreeBSD (6.3).
Soweit zur Ausgangslage. Das größte Problem ist wohl, dass Hetzner kein BSD-Rettungssystem zur Verfügung stellt, sondern lediglich ein Debian 4.0. Die erste Konsequenz ist also, dass unser UFS2-Filesystem vom Rettungssystem aus zwar gelesen aber nicht beschrieben werden kann. Alle Einstellungen müssen also lokal mit qemu vorgenommen werden, danach heißt es dann rüberladen, rebooten und hoffen.

Ich habe mir den Server mit einem minimalen Debian 4.0 ausliefern lassen. Der erste Schritt ist herauszufinden, welche Hardware in der Kiste steckt. Mittlerweile gibt es mehrere Erfahrungsberichte von depinguisierten Hetzner-Servern und Hardwareunterschiede sind an jeder Ecke auszumachen, von daher bringt dich eine Liste von mir nur bedingt weiter. Wahrscheinlich führt sie dich eher zu falschen Annahmen. Sehr wichtig sind vor allem die Festplatten und die Netzwerkkarte, denn diese Komponenten müssen im Wesentlichen von dir konfiguriert werden.
Folgende Befehle sollten Aufschluss liefern:

Außerdem sollte die Datei /etc/resolv.conf gesichert werden, damit später auch die Namensauflösung auf Anhieb funktioniert.

Erst einmal zurück auf unser lokales System. Ich befinde mich in /home/rtg/Freebsd und habe hierhin auch bereits die erste FreeBSD-CD als ISO geladen. Im ersten Schritt muss die “Festplatte” erschaffen werden, in die unser FreeBSD installiert wird. Dazu benutzen wir dd.

Diese Anweisung erstellt eine Datei mit etwas mehr als 8GB Größe gefüllt mit frischen Nullen aus /dev/null. Man würde auch mit wesentlich weniger Platz auskommen, so spare ich mir aber das nachträgliche Vergößern von Partition und Filesystem. Beim Upload ist die Größe nicht sonderlich entscheidend, da wir die Datei mit gzip packen werden und viele Nullen lassen sich ganz gut zusammenfassen.
Also dann qemu angeworfen und los geht die Installation:

Was bedeuten die Parameter?
-hda zeigt auf die Festplatte. Hier geben wir unsere mit Nullen gefüllte Datei an. -cdrom zeigt auf unser ISO-Image, das als Installationsmedium benutzt werden soll. -net steht für Netzwerkunterstützung. Wir schalten sie für die Installation ab. -boot gibt an von welchem Medium gebootet werden soll.
Im FreeBSD-Installationsmenü kann die Standardinstallation genutzt werden. Allen verfügbaren Platz in einen Slice, Root-Partition anlegen und bei Bedarf auch eine Swap-Partition. Die Dialoge können eigentlich alle mit der Standard-Antwort beantwortet werden. Lediglich beim Thema SSH-Login sollte man Yes anwählen. Distributionsset ist bei mir “minimal”, damit mein DSL 3000 nicht all zu viel uploaden muss. Außerdem solltet ihr dringend einen unpreviligierten User anlegen und in die Gruppe wheel packen. Alles fehlende kann später auf dem Server nachgepflegt werden.
Ist die Installation abgeschlossen, schließen wir qemu und booten von unserem FreeBSD-Image:

Folgende Dateien müssen angepasst werden:
/etc/resolv.conf
/etc/rc.conf
/etc/fstab

Die resolv.conf kann einfach aus der vorhandenen Debian-Installation übernommen werden, der Syntax ist gleich. In der rc.conf muss das Netzwerk konfiguriert werden. Ich erledige das Ganze mit DHCP, dann muss man sich nicht mit den Hetzner-Routen rumschlagen und schließt einen potentiellen Fehler aus:

In der fstab ist es nun wichtig, dass die Festplattenbezeichnungen stimmen. Mich hat es einige Stunden gekostet, herauszufinden, dass meine Festplatte am dritten Controller hing und dementsprechend über /dev/ad4 angesprochen werden möchte. Dementsprechend sah meine fstab wie folgt aus:

Nachdem wir die Anpassungen vorgenommen haben, fahren wir die virtuelle Maschine herunter und bereiten unser FreeBSD auf die Reise ins Rechenzentrum vor:

In der Zwischenzeit kann nun über das Kundenmenü von Hetzner der Rescue Modus aktiviert werden. Das System schicken wir danach per

in ebendiesen.

Jetzt müssen wir das Image hochladen:

Nachdem der Upload geglückt ist, können wir im Rescue System mit Hilfe von

die Festplatte weiter aufteilen. Ich lege einen zweiten Slice mit fast allem verfügbaren Speicherplatz an. Das wird später mein Slice für /usr. Zusätzlich lege ich noch einen weiteren Slice mit dem verbliebenen Plattenplatz an. Diesen Slice benötige ich noch, um /usr auf den neuen Slice zu schieben. Dazu später mehr.
Immer daran denken den Slices auch den entsprechenden Typ FreeBSD (A5) mitzugeben. Die erste Partition mit unserem FreeBSD-System muss das bootable-Flag besitzen.
Nachdem die Änderungen geschrieben wurden, gilt es zu rebooten.

Was tun, wenn mein System nicht wieder hochfährt?
Ruhe bewahren und auf Fehlersuche gehen. Es kann dafür sehr unterschiedliche Ursachen geben und ich kann hier nicht alle Gründe aufzählen, aber mal die Gängigsten:

Das Netzwerk ist nicht korrekt eingerichtet!
Auch wenn ihr DHCP benutzt, kann das der Grund sein. Einerseits kann natürlich der DHCP-Server von Hetzner ausfallen, viel wahrscheinlicher ist es aber, dass ihr für euer Interface den falschen Treiber gewählt habt. Wenn das wirklich der Grund ist, konnte euer FreeBSD also booten, nur SSH war logischerweise nicht erreichbar. In diesem Fall habt ihr leichtes Spiel. Aktiviert wieder das Rescue System und löst dann einen Hardware Reset über das Webinterface aus. Wenn ihr wieder im Rescue seid, mounted eure FreeBSD Root Partition:

Schaut euch die Logiles unter /var/log an. Die Logeinträge, die während des Bootens gemacht wurden, verraten euch, wie ihr eure Netzwerkkarte ansprechen müsst. Sobald ihr die Bezeichnung herausgefunden habt, geht das Spiel von vorne los: qemu an, Änderungen durchführen, hochladen, rebooten.

Meine Festplatte wird nicht gefunden!
Das war übrigens auch der Fehler, der meinen Depinguinierungsdurchmarsch bei Hetzner behindert hat. Die Festplatten hängen an einem RAID-Controller. Da es sich nicht um SCSI-Devices handelt, beziehen sich die Zahlen der Festplatten auf ihren Platz an den jeweiligen Controllern und werden nicht einfach von 0 startend durchgezählt.
Meine Platten sind /dev/ad4 und /dev/ad6.

Mein Server ist online, aber ich kann mich per SSH nicht als Root einloggen!
Das ist ganz normal. Um dieses “Problem” zu beheben, musst du entweder die SSHd-Konfiguration ändern (PermitRootLogin yes) oder, wie ich weiter oben vermerkt habe, einen unpreviligierten Benutzer anlegen, der sich in der Gruppe wheel befindet. Dann kannst du dich per SSH als dieser User anmelden und mithilfe von su Root-Rechte erlangen.

Die Probleme sind es alle nicht!
Hetzner ist so kulant und bietet kostenfrei eine LARA für zwei Stunden an. Damit kannst du den Bootvorgang beobachten und den Fehler leichter lokalisieren.

Wenn dein FreeBSD schlussendlich gebootet hat, hast du es so gut wie geschafft. Um Platzproblemen aus dem Weg zu gehen, wollte ich auf jeden Fall noch /usr auf einen eigenen Slice legen. Den hatte ich bereits, wie weiter oben beschrieben, im Rescue System angelegt. Aber wie verschiebt man nun eigentlich ein elementares Verzeichnis auf eine andere Partition? Was sich erst einmal trivial anhört, ist es leider nicht, schließlich müssen alle Berechtigungen sauber kopiert werden und gerade die erweiterten Dateiattribute werden von Programmen wie tar nicht beachtet.
Glücklicherweise gibt es dump und restore. Unglücklicherweise können damit nur komplette Partitionen verschoben werden und keine einzelnen Verzeichnisse.
Nochmal meine Ausgangslage, damit du die Schritte besser auf dein System ummünzen kannst:
ad4s1a ist meine root-Partition mit ca. 8GB Platz (~100 MB belegt).
ad4s1b ist mein Swap. Ich erwähne ihn nur der Vollständigkeit halber, der ist hierbei nicht relevant.
ad4s2 ist mein unbenutzter Slice mit 350GB, der in Zukunft /usr beherbergen soll.
ad4s3 ist ein Slice mit ein bisschen übrig gebliebenen Platz, der jetzt erst einmal als Hilfsmittel für das Kopieren und später als /tmp dienen soll.
Der Plan ist jetzt, so wird das Vorgehen auch im FreeBSD-Manual beschrieben, die Root-Partition auf ad4s3 zu kopieren, wobei das Verzeichnis /usr auf ad4s2 landet. Danach kann ich ad4s2 problemlos im Realsystem als /usr einhängen. Dieses Vorgehen ist aufgrund des Einsatzes von dump nötig. Soweit die Theorie, hier die Praxis:

Das war jetzt ganz schön viel auf einmal. Also nochmal Schritt für Schritt:
Ich lege auf den beiden Slices ein neues Dateisystem an, damit ich mit ihnen arbeiten kann.
Ich mounte meinen Helfs-Slice nach /mnt, lege dort das Verzeichnis usr an und mounte darauf meinen zukünftigen /usr-Slice.
Dann dumpe ich / nach /mnt, damit wird auch automatisch /mnt/usr mit den Daten aus /usr befüllt. Ist das geschafft, löse ich die Mounts wieder.
Jetzt nur noch kurz die /etc/fstab bearbeiten:

Danach könnt ihr das aktuelle /usr verschieben und das neue /usr mounten.

Achtet bloß darauf, dass ihr die Datei fstab richtig bearbeitet und speichert. Ich hatte /usr temporär gemounted und vergessen die fstab zu editieren. Nach einem Reboot fehlte /usr, da das alte /usr nun unter /usr.old lag, das neue /usr aber nicht gemounted wurde. Solltet ihr diesen Punkt erreicht haben, hilft soweit ich das überblicke nur das neue Herüberladen eures Images. Das Rettungssystem kann das Filesystem nicht beschreiben und eine LARA anfordern, bringt nicht viel, da man sich aufgrund des fehlenden /usr gar nicht erst einloggen kann.

Es gibt verschiedene Werkzeuge, um die Ports Collection auf dem aktuellen Stand zu halten und Software zu installieren. Ich setze auf relativ neue Programme, die simpler und schneller arbeiten als ihre etwas angestaubten Vorgänger. Namentlich sind das portsnap und portmaster.
Portsnap ist dafür zuständig unsere Ports Collection aktuell zu halten. Wenn das System gerade frisch aufgesetzt wurde, kann die Ports Collection wie folgt besorgt werden:

Dadurch wird der Ports Tree in gepackter Form auf den Server geladen. Außerdem lege ich das Verzeichnis /usr/ports an (möglicherweise geschieht das mittlerweile automatisch). extract sorgt dann dafür, dass der Ports Tree in /usr/ports abgelegt wird.
In Zukunft kann der Ports Tree dann auch mit portsnap aktualisiert werden:

Um nun die Abhängigkeiten von Ports und ihre Aktualisierung zu verwalten, setze ich portmaster ein. Dieses Werkzeug arbeitet nur mit den Informationen, die in /usr/ports stehen und hat kein eigenes DB-Backend. Das ist mir sehr sympathisch, denn damit bleibt eine potentielle Inkonsistenz direkt außen vor. Außerdem ist portmaster ziemlich fix bei der Arbeit. Auf zur Installation:

Als erstes können wir mit portmaster eine Übersicht unserer bisher installierten Ports ausgeben:

Die Ausgabe auf meinem frisch aufgesetzten Server sieht wie folgt aus:

Software lässt sich nun ganz simpel mit portmaster nachinstallieren. Wenn du also beispielsweise ebenfalls die Bash nachinstallieren willst, suchst du als erstes das richtige Verzeichnis in /usr/ports mit

Den zurückgegebenen Pfad gibst du dann als Parameter an portmaster:

portmaster kümmert sich nun um das Bauen der Abhängigkeiten und der gewünschten Software. Dir bleibt Zeit, um dir einen Kaffee (oder wie ich einen Tee) zu holen.
Mit dem Parameter -e lässt sich Software inklusive nicht mehr benötigter Abhängigkeiten wieder entfernen:

Wenn die Ausgabe von portmaster -L dir Kandidaten auflistet, bei denen eine neue Version verfügbar ist und du diesen Versionssprung mitmachen möchtest, dann gehst du genau wie beim Installieren eines Ports vor. Nehmen wir an, wir möchten unsere Bash aktualisieren, dann rufen wir portmaster wieder wie folgt auf:

portmaster überprüft wieder alle Abhängigkeiten, aktualisiert Abhängigkeiten wenn nötig und aktualisiert dann das angegebene Paket.

Alternativ kann portmaster mit dem Parameter -a aufgerufen werden. Daraufhin werden alle Pakete, die aktualisiert werden können, auf den neusten Stand gebracht.