Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Geplanter Fehler

Ist die Installation erfolgreich abgeschlossen, gelangt man wieder in das Hauptmenü von »sysinstall« zurück. Es ist hier nicht möglich, die Treiber im Fixit-System auf die Festplatte zu übertragen, deshalb wird noch einmal von der DVD gebootet. Der einfache Neustart schlägt in der FOSS-Cloud an dieser Stelle grundsätzlich fehl, man muss die Maschine im Webfrontend ohne Änderung des Boot-Devices von CD-ROM auf Platte manuell aus- und wieder einschalten.

Im Hauptmenü von »sysinstall« wählt man dann den Punkt »Fixit« und dort »CDROM/DVD« . Man landet an einem Prompt mit der Kennung »Fixit#« . Hier laden die folgenden Befehle die Root-Partition der Festplatte und übertragen alle wichtigen Dateien von der Installations-CD:

mount /dev/vtbd0s1a /mnt
cd /mnt/boot/modules
cp /dist/boot/modules/* .
cd ..
cp /dist/boot/loader.conf .

Im letzten Schritt der Installation muss man noch die soeben kopierte Datei mit »ee loader.conf« in den Systemeditor laden und bearbeiten. In der Datei müssen die ursprünglichen Verweise auf das Starten von der RAM-Disk entfernt oder auskommentiert werden:

# mfsroot_load="YES"
# mfsroot_type="mfs_root"
# mfsroot_name="/boot/mfsroot"
virtio_load="YES"
...

Damit ist die Installation von FreeBSD 8 in der FOSS-Cloud beendet. Die Eingabe von »exit« beendet das Fixit-System. Über das Hauptmenü von »sysinstall« startet man das System neu. Im Webfrontend muss dafür noch die Bootreihenfolge umgestellt werden. Falls das System jetzt nicht booten will, wird es noch einmal gewaltsam im Webfrontend ausgeschaltet und dann wieder aufgerufen. Sobald es sauber von Festplatte startet, sind die Bootprobleme beseitigt.

Bei FreeBSD 10, dem derzeitigen CURRENT, ist das Virtio-System in den normalen Quelltexten enthalten. Die Treiber brauchen also nicht mehr aus den Ports installiert und gesondert auf den Master übertragen zu werden.

Leider findet man auf dem FTP-Server des Projekts derzeit keine vorgefertigten Images, sodass man das System selbst entweder für jede Installation aus den Quellen aus FreeBSD 9 aktualisieren muss (bei einer lokalen Installation akzeptabel) oder man baut sich für das spätere serverbasierte Einrichten selbst zuvor in einer anderen FreeBSD-Installation eine Installations-CD für CURRENT. Dazu müssen lokal einmal entweder über CTM oder aus dem CVS beziehungsweise SVN die Quellen zentral besorgt und dann durchkompiliert werden (siehe [4] ).

Die folgend gezeigten Schritte gehen davon aus, dass die Quellen von FreeBSD 10 bereits installiert sind und das System mit den Aufrufen

cd /usr/src
make buildworld buildkernel
make installkernel installworld
reboot

aktualisiert wurde. Auch das Portverzeichnis wird benötigt, es wird bei Bedarf mit »portsnap fetch install« aufgebaut. Auf keinen Fall dürfen nach dem Bauen des neuen Betriebssystems die Intermediärdateien im Quellbaum mit »make clean« gelöscht werden, denn sie werden noch gebraucht. Nach dem Neustart muss man außerdem »uname -a« prüfen, ob tatsächlich ein CURRENT-System installiert ist. Anschließend geht es so weiter wie in Listing 1 gezeigt.

Listing 1

FreeBSD-10-Installations-CD

 

Die Make-Läufe müssen einmal in »src« selbst, dann in »src/etc« und abschließend in »src/release« durchgeführt werden. Die ISO-Datei befindet sich zum Schluss in »/usr/obj/usr/src/release/« . Die eigentliche Arbeitsdatei heißt »release.iso« . Sie enthält keine modifizierte Kernelkonfiguration. Beim Booten auf dem FOSS-Cloud-Server muss man deshalb die Treiber manuell vor der eigentlichen Installation laden. Im Verzeichnis »/usr/obj/usr/src/release/« sind noch weitere Dateien abgelegt, sie werden aber nicht benötigt.

Image vom Image

Hat man ein Standard-ISO-Image angelegt, kann man damit auch wieder ein neues angepasstes erzeugen. Dazu wird das soeben angelegte ISO-Image zuerst als Pseudolaufwerk eingebunden, dann werden die darin enthaltenen Dateien extrahiert und der neue Master wie oben bereits beschrieben angepasst und auch mit zusätzlichen Daten bestückt. Von diesem Master wird dann wieder ein korrigiertes Image für die FOSS-Cloud geschrieben. Wichtig: Aus den Ports oder den Paketen muss außerdem das Programm »dupmerge« installiert werden. Eingebunden wird das Image folgendermaßen:

mkdir /mnt/iso
mdconfig -a -t vnode -f /usr/obj/usr/src/release/release.iso
md0
mount -t cd9660 /dev/md0 /mnt/iso

»/dev/md0« ist ein Memory-Device, das nach dem Kopieren der Dateien wieder freigegeben werden muss. (Ist »md0« bereits vorher in Betrieb gewesen, wird automatisch ein Geräteeintrag mit einer höheren Nummer angelegt.) Zuerst werden aber mit den folgenden Befehlen die Dateien übertragen:

mkdir -p /usr/foss/tree
cd /usr/foss/tree
cp -Rp /mnt/iso/* .
cp /mnt/iso/.p* .
cp /mnt/iso/.c* .
find ./ -type f -print0 | dupmerge
ee boot/loader.conf

Jetzt müssen wie bereits bei der Vorversion die Treiber in eine neue »boot/loader.conf« geschrieben werden:

virtio_load="YES"
virtio_pci_load="YES"
if_vtnet_load="YES"
virtio_balloon_load="YES"

Das ursprüngliche Image kann nun mit

umount -f /dev/md0
mdconfig -l
md0
mdconfig -d -u md0
mdconfig -l

ausgebunden und danach »md0« bei Bedarf wieder anderweitig genutzt werden. Hat das Ausbinden des Geräteknotens geklappt, zeigt ein anschließender Aufruf von »mdconfig -l« kein eingebundenes Device mehr an. Das hier gezeigte »-f« bei »umount« ist nur nötig, wenn das System meldet, das Device sei noch belegt ist. Erst ein freigegebenes md-Gerät kann abgeschaltet werden.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023