Installation von Debootstrap

Zuerst muss debootstrap vorhanden sein, am einfachsten natürlich mit apt-get install debootstrap. Unter Ubuntu kann mit debootstrap auch die Folgeversion installiert werden. Debian-User können das Ubuntu-Debootstrap direkt von http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/ herunterladen und mit dpkg -i installieren. Nutzer von RPM-Distributionen sollten ein Konvertierungstool installieren oder Debootstrap direkt aus dem .tar.gz installieren.

Vorbereitung eines Images

Für Xen DomUs haben Sie die Möglichkeit, physikalische Festplatten oder deren Partitionen zu nutzen oder Festplattenimages zu verwenden. Bei den Images wiederum gibt es zwei Möglichkeiten: Tap-Disks, die wachsen können und beispielsweise VMware VMDK-Format unterstützen oder “Plain-Images”, die als Loopback-Device gemountet werden können. Ich empfehle bei Testkonfigurationen grundsätzlich und bei Produktivsystemen für die Systempartitionen Images von Partitionen. Die Gründe:

• Im Gegensatz zu partitionierten Festplattenimages kann ein Partitionsimage ohne Verrenkungen vergrößert werden
• Ein Mounten ist simpel mit mount -o loop ... möglich, es muss kein Offset errechnet und angegeben werden
• Im Gegensatz zu VMDK-Images benötigt der Mount auf einer Xen-losen Maschine keine zusätzlichen Werkzeuge

Images erstelle ich als Sparse-Images, das geht schnell und spart Plattenplatz, hat aber bei Maschinen mit vielen Xen-Instanzen deutlich spürbare Einbußen durch doppelte Fragmentierung zur Folge. Zunächst entsteht ein Image für die Systempartition. Da ich gerne auch Kernel in der Xen-Instanz baue, hier 8GB groß, das Swap-Image bekommt ein Gigabyte:

dd if=/dev/zero bs=$((1024**2)) count=1 seek=8191 of=xvda1.img
dd if=/dev/zero bs=$((1024**2)) count=1 seek=1023 of=swap.img

Als nächstes entsteht eine Swap-Signatur und ein Dateisystem auf dem Image xvda1.img. Das Dateisystem mounte ich gleich auf einen noch zu erstellenden Mountpoint /tmp/minibuntu:

mkswap -f swap.img
freeloop=` losetup -f `
losetup $freeloop xvda1.img
echo "loopdevice is $freeloop"
mkfs.ext3 $freeloop
mkdir /tmp/minibuntu
mount $freeloop /tmp/minibuntu

Installation des Basissystems

Die Installation des Basissystems geht innerhalb weniger Minuten mit dem Befehl debootstrap. Auf einem 64-Bit Hostsystem haben Sie die Wahl, 32- oder 64-Bit-Gäste zu installieren. Bei Gästen, die keine allzu große Prozessgröße erwarten lassen, sind 32-Bit-Gäste oft einen Tick flotter und kompakter:

debootstrap --arch i386 lucid /tmp/minibuntu http://archive.ubuntu.com/ubuntu

oder

debootstrap --arch amd64 lucid /tmp/minibuntu http://archive.ubuntu.com/ubuntu

Das so installierte Ubuntu würde sich mit dem Hostkernel schon booten, darüber hinaus jedoch kaum nutzen lassen. Setzen wir einige Einstellungen:

vim /tmp/minibuntu/etc/default/locale

# BEGIN /etc/default/locale
LANG="POSIX"
# oder
# LANG="de_DE.UTF-8"
# END /etc/default/locale

vim /tmp/minibuntu/etc/network/interfaces

# BEGIN /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
# END /etc/network/interfaces

echo '127.0.0.1 localhost' > /tmp/minibuntu/etc/hosts
echo 'lucid-domU.test' > /tmp/minibuntu/etc/hostname

Auch eine vollständige /etc/apt/sources.list wird benötigt:

vim /tmp/minibuntu/etc/apt/sources.list

# BEGIN /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu/ lucid main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid main restricted
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates main restricted
deb http://de.archive.ubuntu.com/ubuntu/ lucid universe
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid universe
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates universe
deb http://de.archive.ubuntu.com/ubuntu/ lucid multiverse
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid multiverse
deb http://de.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid-updates multiverse
deb http://security.ubuntu.com/ubuntu lucid-security main restricted
deb-src http://security.ubuntu.com/ubuntu lucid-security main restricted
deb http://security.ubuntu.com/ubuntu lucid-security universe
deb-src http://security.ubuntu.com/ubuntu lucid-security universe
deb http://security.ubuntu.com/ubuntu lucid-security multiverse
deb-src http://security.ubuntu.com/ubuntu lucid-security multiverse
# END /etc/apt/sources.list

Ohne /etc/fstab geht wenig im domU-System, die Platten heissen nicht mehr wie bei den alten dom0- und domU-Kerneln /dev/sda, sondern /dev/xvda:

vim /tmp/minibuntu/etc/fstab

# BEGIN /etc/fstab
proc /proc proc defaults 0 0
/dev/xvda1 / ext3 defaults 0 1
/dev/xvda2 none swap sw 0 0
# END /etc/fstab

Eine Konsole für Xen. Xen nutzt /dev/hvc0 als Systemkonsole, diese muss noch mit einem getty versehen werden. Das erledigen Sie durch Kopieren der Definition von tty1 und entsprechende Anpassungen:

cp /tmp/minibuntu/etc/init/{tty1,hvc0}.conf
sed -i 's/tty1/hvc0/g' /tmp/minibuntu/etc/init/hvc0.conf

Chroot, Passwort und Kernel

Zum Abschluss der Installation und der Nachinstallation von Software müssen Sie per chroot in das frisch installierte Ubuntu wechseln. Zunächst benötigen Sie dafür einige spezielle Dateisysteme:

mount -t proc none /tmp/minibuntu/proc
mount -t devpts none /tmp/minibuntu/dev/pts 

Wenn Host und Gast die gleiche Architektur nutzen, klappt der Chroot klassisch:

LANG=C chroot /tmp/minibuntu /bin/bash

Ist der Host dagegen 64 bittig und der Gast 32 bittig, ist setarch zu verwenden:

LANG=C setarch i386 chroot /tmp/minibuntu /bin/bash

Zunächst aktivieren wir Shadow-Passwörter und setzen ein Root-Passwort:

shadowconfig on
passwd

Auf 32-Bit-Gästen muss zwingend ein PAE-Kernel installiert werden. Nur dieser enthält Unterstützung für pvops. Kernel ohne PAE laufen nur auf dem “nackten Metall”. Bei 64 Bit sollten alle Kernel pvops unterstützen:

apt-get install linux-image-generic-pae

Da ein Bootloader bei unserer Konfiguration keinen Sinn macht, sind entsprechende Nachfragen mit [No] zu beantworten.

Aufbau des Initramfs

Im Gegensatz zu gängigen Dateisystemtreibern enthält Ubuntus Kernel die Frontend-Treiber für Blockdevices und das Netz nur als Module. Diese sind entsprechend zu Initramfs-Konfiguration hinzuzufügen:

vim.tiny /etc/initramfs-tools/initramfs.conf

MODULES=list

Diese Liste ist entsprechend anzupassen:

vim.tiny /etc/initramfs-tools/modules

# BEGIN /etc/initramfs-tools/modules
xen-kbdfront
xen-netfront
xen-blkfront
# END /etc/initramfs-tools/modules

Und anschließend wird das Initramfs neu aufgebaut:

mkinitramfs -o /boot/initrd.img-2.6.32-24-generic-pae 2.6.32-24-generic-pae

Verlassen Sie nun den Chroot wieder und unmounten Sie die beiden speziellen Dateisysteme.

exit
umount /tmp/minibuntu/proc
umount /tmp/minibuntu/dev/pts

Kopieren der Kernel, Aufbau der domU-Konfiguration

Kopieren Sie nun Kernel und Initramfs von /tmp/minibuntu/boot in das Verzeichnis, welches Festplattenimages und später die Konfiguration enthält. Erstellen Sie dann eine Datei ubuntu.cfg mit folgendem Inhalt (selbstverständlich ist der Pfad zum Installationsverzeichnis anzupassen und Kernel sowie Initramfs umzubenennen oder zu verlinken):

kernel = "/usr/local/xendomains/lucid_test/vmlinuz"
ramdisk = "/usr/local/xendomains/lucid_test/initrd.gz"
memory = 512
name = "lucid-test"
vif = [ 'mac=00:16:00:00:42:23' ]
disk = [ 'file:/usr/local/xendomains/lucid_test/xvda1.img,xvda1,w',
         'file:/usr/local/xendomains/lucid_test/swap.img,xvda2,w' ]
root = '/dev/xvda1 ro'
extra = 'console=hvc0'

Jetzt nicht vergessen, das Loopback-Device zu unmounten und freizugeben:

umount /tmp/minibuntu
umount $freeloop
losetup -d $freeloop

Dann kann auch die neue domU gestartet werden:

xm create -c ubuntu.cfg

Melden Sie sich in der Konsole der domU an und installieren Sie die Xen-Version der C-Bibliothek, sowie OpenSSH nach:

apt-get install ssh libc6-xen

Beim nächsten Mal kann dann die Domain ohne -c gestartet und per SSH zugegriffen werden. Soll die virtuelle Festplatte vergrößert werden, kann dies nach dem Herunterfahren mit dd erfolgen:

dd if=/dev/zero bs=$((1024**2)) count=1 seek=16383 of=xvda1.img
freeloop=` losetup -f`
losetup $freeloop xvda1.img
fsck.ext3 -f $freeloop
resize2fs $freeloop
losetup -d $freeloop

That’s it! Soll die domU automatisch mit dem Xend des Hostes starten, die .cfg in /etc/xen/auto verlinken und darauf achten, dass das Startscript /etc/init.d/xendomains beim Systemstart unmittelbar nach xend gestartet wird. Die so erstellte Domain ist prinzipiell portabel, man sollte sich allerdings keine allzugroßen Hoffnungen auf einen Boot unter alten Xen-Versionen (vor 3.4) machen. Sind noch alte dom0s vorhanden, schafft möglicherweise Ubuntus ec2-Kernel für Amazons Elastic Computing Cloud Abhilfe.

Ich habe einmal testweise ein Setup auf einer AMD64-Maschine erstellt, auf 32-Bit-Systemen sind lediglich einige Kleinigkeiten anders: Der Kernel muss PAE-Support haben und es muss zwingend ein Prozessortyp ausgewählt werden, der über Virtualisierungserweiterungen verfügt. Da heutzutage kaum Rechner als Xen-Host zum Einsatz kommen dürften, die nicht 64-Bit-tauglich sind, sollte sich die Frage nach pvops-Dom0s auf 32-Bit-Hardware kaum stellen.

Die Vorbereitung

Fürs Bauen des Kernels müssen zuerst einige Debian-Pakete nachinstalliert werden. Meine Testmaschine war ein recht blankes Netinstall, so dass diese Liste hoffentlich vollständig ist:

apt-get install build-essential libncurses5-dev python-twisted \
        git-core zlib1g-dev gettext libX11-dev uuid-dev libssl-dev\
        bin86 bcc flex bison python-dev bridge-utils

Neuere Xen-Versionen benötigen Intels ACPI-Compiler. Den habe ich noch nicht in den Ubuntu-Paketlisten gefunden, stattdessen habe ich ihn aus den Quellen gebaut und mittels install installiert. Da nur ein einziges Binary benötigt wird, ist es leicht möglich, das temporäre Build-Verzeichnis in den Pfad aufzunehmen und so das System nicht zu verschmutzen. Bitte prüft vor der ACPICA-Installation, ob unter http://www.acpica.org/downloads/ neuere Versionen bereitstehen:

cd /usr/src
wget http://acpica.org/download/acpica-unix-20100806.tar.gz
tar xvzf acpica-unix-20100806.tar.gz
cd acpica-unix-20100806/compiler
make
install -m 0755 iasl /usr/bin

Bau und Boot des pvops-Kernels

Wie eingangs erwähnt, ist Support für pvops-Dom0 noch nicht Teil des offiziellen Kernels. Es muss daher Jeremys 2.6.32er mit pvops-Patches ausgecheckt werden. Falls jemand abkürzen möchte, kann er hier die von mir verwendeten Sourcen herunterladen, diese beinhalten bereits eine .config.

cd /usr/src
git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-2.6-xen
cd linux-2.6-xen
git reset --hard
git checkout -b xen/stable-2.6.32.x origin/xen/stable-2.6.32.x

Beim Selbstbau dürfte es meist ganz gut passen, die Kernelconfig des Ubuntu als Basis zu verwenden und mit make oldconfig die Xen-spezifischen Punkte zu ergänzen. Wer dabei die richtigen Treiber statisch einbindet, braucht auch an der Initramfs-Konfiguration nichts zu modifizieren:

cd /usr/src
cd linux-2.6-xen
cp /boot/config-` uname -r ` .config
make oldconfig

Zum Vergleich hier meine Xen-spezifischen Optionen:

CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=32
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_SWIOTLB_XEN=y
CONFIG_MICROCODE_XEN=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_DOM0_PCI=y
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_PCI_XEN=y
CONFIG_XEN_PCIDEV_FRONTEND=y
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_KBDDEV_FRONTEND=m
CONFIG_HVC_XEN=y
CONFIG_XEN_FBDEV_FRONTEND=m
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_BLKDEV_TAP=y
CONFIG_XEN_BLKBACK_PAGEMAP=y
CONFIG_XEN_PCIDEV_BACKEND=y
CONFIG_XEN_PCIDEV_BACKEND_VPCI=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_MCE=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_S3=y
CONFIG_ACPI_PROCESSOR_XEN=y
CONFIG_XEN_PLATFORM_PCI=m

Wer möchte, kann meine Konfiguration komplett oder als unified diff (gegen Ubuntus 2.6.32-24 Kernel) herunterladen und diese verwenden. Das Bauen geht dann wie gewohnt, ich strippe die Kernelmodule und erstelle gleich eine GRUB-Konfiguration:

make
make install
make modules_install
find /lib/modules/2.6.32.18-xen0-pvops/ -name '*.ko' -exec strip --strip-unneeded {} \;
mkinitramfs -o /boot/initrd.img-2.6.32.18-xen0-pvops 2.6.32.18-xen0-pvops
update-grub

Der erste Neustart

Rebooten Sie nun den Rechner und wählen Sie den neuen pvops-Kernel als Startkernel aus. Die Maschine sollte problemlos hochfahren, tut sie das nicht, stehen die Chancen schlecht, dass dieser Kernel auch auf Xen sauber startet.

Installation von Xen und den Xen-Tools

Als dieses Tutorial erstellt wurde, war mit Xen 4.0.1 gerade die erste Maintenance-Release der 4.0er-Reihe erhältlich. Falls Sie noch 3.4.x oder 4.0.0 verwenden (und damit zufrieden sind): Aktualisieren Sie auf jeden Fall auf 4.0.1, weil hier einige Bugs im Zusammenspiel von Xen und dom0-pvops-Kerneln beseitigt wurden:

cd /usr/src
wget http://bits.xensource.com/oss-xen/release/4.0.1/xen-4.0.1.tar.gz
tar xvzf xen-4.0.1.tar.gz
cd xen-4.0.1
make xen
make install-xen
make tools
make install-tools PYTHON_PREFIX_ARG=

Es folgt die Erstellung einer Bootloder-Konfiguration, bitte die UUID entsprechend anpassen:

vim.tiny /etc/grub.d/50_xen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Ubuntu 10.04 - Xen 4.0.1 - 2.6.32.18 pvops" {
        insmod ext2
        set root=(hd0,1)
        search --no-floppy --fs-uuid --set dc50c3d6-787a-45d7-951b-20836d10443c
        multiboot /boot/xen-4.0.1.gz dummy=dummy
        module /boot/vmlinuz-2.6.32.18-xen0-pvops root=UUID=dc50c3d6-787a-45d7-951b-20836d10443c ro dummy=dummy
        module /boot/initrd.img-2.6.32.18-xen0-pvops
}

chmod a+x /etc/grub.d/50_xen
vim.tiny /etc/default/grub

GRUB_DEFAULT="Ubuntu 10.04 - Xen 4.0.1 - 2.6.32.18 pvops"
GRUB_HIDDEN_TIMEOUT=30
GRUB_HIDDEN_TIMEOUT_QUIET=false

Anschließend nicht vergessen, die Grub-Konfiguration noch einmal neu aufzubauen:

update-grub

Ein Dateisystem für Xen: Einige Scripte benäötigen das alte /proc/xen. Dieses wird durch einen Eintrag in der /etc/fstab beim nächsten Neustart gemountet:

xenfs /proc/xen xenfs defaults

Dann benötigen wir noch zwei Module und deren Devices – die Module sollten in die /etc/modules eingetragen werden:

modprobe -v xen-evtchn
modprobe -v xen-gntdev

mkdir /dev/xen
mknod -m 0660 /dev/xen/gntdev c 10 57
mknod -m 0660 /dev/xen/evtchn c 10 58

Das war es: Beim nächsten Neustart startet der eben gebootete pvops-Kernel nicht auf nacktem Metall, sondern auf dem Hypervisor. Mit pvops-Kernel sollte es auch möglich sein, die beschleunigten Grafiktreiber von AMD und nVidia zu nutzen, ausprobiert habe ich dies nicht, weil bei mir Xen nur auf dem Server eingesetzt wird.

Auf die Konfiguration von pvops-DomUs gehe ich in den nächsten Tagen ein: Für diese halten aktuelle Distributionen oft passende Kernel bereit, ich werde jedoch auch zeigen, wie man mit einem frischen Vanilla-Kernel 2.6.35.x ein wenig mehr herausholt.

Vielen Dank an…

• …das offizielle Xen-Blog, an dessen Anleitung ich mich grob orientiert habe
• …die Mitarbeiter des Xen-Wikis, die viele wertvolle Informationen zu pvops zusammengetragen haben

Update, 31. August 2010

• bridge-utils zur Paketliste hinzugefügt
• Ergänzung zu /proc/xen
• Ergänzung zu fehlenden Devices und Modulen

root@caesium:~#  dd if=/dev/sda bs=448 count=1 | strings
1+0 Datensätze ein
1+0 Datensätze aus
448 Bytes (448 B) kopiert, 4,2288e-05 s, 10,6 MB/s
ZRr=
`|f
\|f1
GRUB
Geom
Hard Disk
Read
 Error

Das ist wohl GRUB, beim Syslinux-MBR (Extlinux) sieht die Ausgabe so aus:

RPf1
Missing operating system.
f`f1
|fRfP
Ht[y9Y[
Multiple active partitions.
Operating system load error.

Beim Neuaufsetzen eines Servers ist es besser, gleich eine PointToPoint-Lösung mit 255.255.255.255-Maske aufzusetzen. Damit können bei einer 29-Bit-Maske (255.255.255.248) acht statt fünf IP-Adressen genutzt werden — satte 60% mehr (bei vier, fünf, oder sechs Bit Masken fällt der Gewinn natürlich kleiner aus). Die Änderungen gegenüber dem Setup von gestern sind, dass dummy0 in der /etc/network/interfaces der dom0 entfällt. In der /etc/xen/xend-config.sxp wird das extern erreichbare Interface eingetragen (in der Regel eth0):

(network-script 'network-route netdev=eth0')
(vif-script     'vif-route netdev=eth0')

Die Netzwerkkonfiguration der domU bekommt nun die primäre IP-Adresse der dom0 als Gateway eingetragen, dazu das Schlüsselwort pointopoint (nur ein ‘t’!) und die “dichte” Netzmaske:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 172.16.16.114
        netmask 255.255.255.255
        gateway 192.168.1.2
        pointopoint 192.168.1.2
        post-up ethtool -K eth0 tx off

Vielen Dank an…

• Umstellung Debian Etch mit XEN 3 auf routed …die fleissigen Dokumentatoren im Hetzner-Wiki
• …den Admin bei 1&1, dessen Default-Setup mit pointopoint auf der primären IP mich dazu anregte, hier nochmal nachzuforschen

Ziel waren zwei Server: Ein 64-Bit-System fürs Büro und ein 32-Bit-System für einen alten (AMD Athlon XP 2000, 512MB, 80GB) Hetzner Rootie (Presse-Testsystem). Beide Systeme wurden zunächst mit einem Ubuntu Minimalsystem ausgestattet. Bei Hetzner geschah dies aus dem Notfall-System per debootstrap (fertige OS-Images werden nur einmal am Tag aufgespielt, was stört, wenn man nach einer abgeschossenen Installation neu aufsetzen möchte) und der Server zuhause wurde per Debian-Installer per PXE-Netboot eingerichtet. Die zwei Möglichkeiten, einen Hetzner-Server mit Ubuntu oder Debian auszustatten — debootstrap und den Debian-Installer im SSH-Modus — erkläre ich bei Gelegenheit im Detail.

Benötigte Pakete

Mit dem folgenden Befehl sollten alle Abhängigkeiten aufgelöst werden, die zum Bau von Xen und dem Betrieb einer Dom0 benötigt werden:

apt-get install rsync screen build-essential bin86 bcc libssl-dev \
      gettext libncurses-dev python python-dev pciutils-dev libx11-dev \
      pkg-config python-twisted bridge-utils gawk

Unter 32 Bit-Systemen sollte man aus Performance-Gründen noch die angepasste C-Bibliothek installieren:

apt-get install libc6-xen

Kernel kompilieren

Ubuntu selbst bietet einen Kernel für Amazons EC2, der sollte einigermaßen gut auf aktuellen Xen-Versionen laufen. Getestet habe ich es nicht. Stattdessen habe ich selbst drei Kernel kompiliert: Einen für AMD64 mit vollem Dom0-Support und vielen Treibern, einen mit stark abgespeckten Treibern (für 64Bit-DomUs) und einen i686-Kernel mit vollem Dom0-Support und der Möglichkeit, auf älteren Xen-Versionen gestartet zu werden. Die für Xen benötigten Frontend- sowie Backend-Treiber habe ich statisch integriert, was den Vorteil hat, dass an der Konfiguration des Initramfs nichts geändert werden muss. Alle Konfigurationen bieten Verbesserungspotential, beispielsweise beim Abspecken um nicht benötigte Treiber. Hier sei allerdings darauf verwiesen, dass das Entfernen vermeintlich nicht benötigter Funktionen Unresolved Symbols und damit Kompilationsabbrüche zur Folge haben kann.

Als Kernel kommt hier Gentoos 2.6.31.12 — konkret das Patchset xen-patches-2.6.31-12.tar.bz2 — zum Einsatz. Die verwendeten Patches stammen größtenteils von openSUSEs Xen-Kernel, wurden aber von SuSE-Spezifika befreit. Das macht das Bauen und die Installation einfacher. Gepflegt werden die Patches als eigenes Projekt bei Google Code.

Meine Konfigurationsdateien:

• config-2.6.31.12-mfs002-xen0-compat-i586
• config-2.6.31.12-mfs001-xen0-amd64
• config-2.6.31.12-mfs006-xenU-minimal-amd64

Und nun zum Bauen des Kernels, hier für AMD64:

mkdir xen-patches-2.6.31-12
cd xen-patches-2.6.31-12
tar xvjf ../xen-patches-2.6.31-12.tar.bz2
cd ../linux-2.6.31
for i in ../xen-patches-2.6.31-12/*.patch1 ; do patch -p1 < $i ; done
wget -O .config http://cdprojekte.mattiasschlenker.de/Public/Xen-Kernel/config-2.6.31.12-mfs001-xen0-amd64
make oldconfig
make
make install
make modules_install

Der Kernel braucht noch ein passendes Initramfs, dieses entsteht mit:

mkinitramfs -o /boot/initrd.img-2.6.31.12-mfs001-xen0-amd64 2.6.31.12-mfs001-xen0-amd64

Falls Sie Xen Frontend- oder Backend-Treiber in Module ausgelagert haben, müssen Sie ggf. die Modulliste des Initramfs anpassen!

Xen Hypervisor installieren

Ohne Xen nützt der schönste Kernel nichts, also bauen und installieren wir Xen 3.4.2 aus dem offiziellen Tarball von www.xen.org:

tar xvzf xen-3.4.2.tar.gz
cd xen-3.4.2
make xen
make install-xen

Bootloader konfigurieren

Der einfachste Weg ist die Erstellung eines simplen Scriptes /etc/grub.d/50_xen, welches hart kodiert Kernelnamen, Xen-Version und Pfade (Root-Device ist hier /dev/sda4) enthält. Zweimal root=... ist kein Tippfehler, sondern als Workaround für einen kleinen Bug in den Scripten des Initramfs gedacht:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Ubuntu 9.10 - Xen 3.4.2 + Linux 2.6.31" {
        insmod ext2
        set root=(hd0,4)
        multiboot /boot/xen-3.4.2.gz
        module /boot/vmlinuz-2.6.31.12-mfs001-xen0-amd64 root=/dev/sda4 ro root=/dev/sda4
        module /boot/initrd.img-2.6.31.12-mfs001-xen0-amd64
}

Das Script muss nun noch ausführbar gesetzt werden, sonst wird der neue Eintrag nicht in die GRUB-Konfiguration übernommen!

chmod a+x /etc/grub.d/50_xen

In der Datei /etc/default/grub sollten Sie den Standard-Booteintrag auf den neuen Kernel setzen:

GRUB_DEFAULT="Ubuntu 9.10 - Xen 3.4.2 + Linux 2.6.31"

Danach rufen Sie update-grub auf um die Bootloader-Konfiguration neu aufzubauen. Rebooten Sie jetzt den Rechner mit Xen und dem neuen Kernel.

Installation der Xen-Tools

Die Xen-Tools habe ich in einem frisch entpackten Xen-Tarball kompiliert. Die bei der Installation angegebene Variable ist wichtig, damit die Python-Module in den bei Ubuntu üblichen Pfaden landen. Gibt man diese Variable nicht an, ist es ggf. erforderlich eine Umgebunsvariable PYTHONPATH zu setzen und diese ggf. in das Script /etc/init.d/xend einzubauen:

rm -rf xen-3.4.2
tar xvzf xen-3.4.2.tar.gz
cd xen-3.4.2
make tools
make install-tools PYTHON_PREFIX_ARG=

Wenn alles geklappt hat, lässt sich der Xend starten. Läuft dieser, können die Bootmeldungen des Hypervisors ausgelesen werden.

/etc/init.d/xend start
xm dmesg

Xend in den Runleveln verlinken

Ich habe Xend vor dem SSH-Server verlinkt, den Start der domU-Instanzen danach. Grund waren Probleme mit dem SSH-Server: Upstart (oder der Xend?) versucht diesen neu zu starten, wenn neue Interfaces auftauchen. Das gelingt nicht immer, so dass ich während meiner Tests häufiger ohne SSH da stand. Auf einem Root-Server ist so etwas natürlich ganz bescheiden.

update-rc.d xend start 14 2 3 4 5 . stop 80 0 1 6 .
update-rc.d xendomains start 21 2 3 4 5 . stop 79 0 1 6 .

Vorbereitung für Routing-Setup

Achtung: Siehe auch den Nachtrag vom 19. März für ein besseres Setup!

Provider wie Hetzner oder Strato routen einem Server zugewiesene Subnetze auf dessen primäre IP-Adresse. Deshalb muss bei diesen Servern das Xen-Netzwerk von bridged auf routed umgestellt werden. Achtung: Einige Provider klemmen Server gnadenlos ab, wenn hinter einem Port des Routers bislang unbekannte MAC-Adressen auftauchen. Wer den Xend bei so einem Provider startet, ohne vorher auf routed umgestellt zu haben, fliegt aus der SSH-Verbindung raus und darf mit dem Support telefonieren!

Zuerst wird die Datei /etc/modules um eine Zeile

dummy

für den Dummy-Netzwerk-Adapter erweitert.

Es folgt die statische Konfiguration der primären IP-Adresse auf eth0 und der ersten nutzbaren IP-Adresse auf dummy. In diesem Fall haben wir das Subnetz 172.16.16.112/ 255.255.255.248 (acht Adressen von .112 bis .119) zugewiesen bekommen, .112 ist hier die Adresse des Netzes, .113 wird auf dummy0 gelegt, .114 bis .118 (fünf von acht Adressen) sind für die domUs nutzbar und .119 ist die Broadcast-Adresse:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        gateway 192.168.1.1

auto dummy0
iface dummy0 inet static
        address 172.16.16.113
        netmask 255.255.255.248

In der Konfigurationsdatei /etc/xen/xend-config.sxp des Xend muss die Einstellung von bridged auf routed umgestellt werden. Das zu routende Device muss explizit angegeben werden:

# (network-script network-bridge)
# (vif-script     vif-bridge)
(network-script 'network-route netdev=dummy0')
(vif-script     'vif-route netdev=dummy0')

An dieser Stelle ist ein Neustart des Xend, besser ein Reboot erforderlich. Anschließend können die domUs konfiguriert werden. Die Routing-Informationen werden hierfür in der Client-Config eingetragen:

kernel = "/boot/vmlinuz-2.6.31.12-mfs006-xenU-minimal-amd64"
ramdisk = "/boot/initrd.img-2.6.31.12-mfs006-xenU-minimal-amd64"
memory = 256
name = "ubuntu-amd64-minimal"
vif = [ 'ip=172.16.16.114' , 'mac=00:16:00:00:00:27' ]
disk = [ 'file:/usr/local/xendomains/test01_64/sda1.img,sda1,w' ]
root = "/dev/sda1 ro"
extras = "console=hvc0 xencons=tty"

Daneben ist es erforderlich, die IP-Konfiguration in der /etc/network/interfaces der domU einzutragen -- DHCP möchte ich an dieser Stelle nicht erklären, das würde den Rahmen sprengen.

Vielen Dank an...

• Installing Xen on Ubuntu 9.10 -- Brandon's Blog ...für die Idee mit dem Gentoo-Kernel und die GRUB-Konfiguration
• An introduction to custom Xen networking -- Debian Administration ...für die Hinweise zum Routed-Setup

Anmerkungen:

• Nie erst Ubuntus Xen-Tools 3.3 installieren und dann diese Anleitung durchführen. Das resultierende Versionsmischmasch wird garantiert kein funktionierendes Netzwerk zur Folge haben!

• Details zur domU-Konfiguration bei Hetzner folgen

• Details zur Ubuntu-/Debian-Installation aus Hetzners Rettungssystem folgen

Erster Bootversuch

Meinen ersten Bootversuch unternahm ich mit der aktuellen Testversion der Computerbild-Notfall-CD 2.1. Diese basiert auf “LessLinux“, meiner eigenen LFS basierten Distribution. Da Kernel 2.6.33 einen stabilen JME-Treiber mitbringt (JMicron Gigabit Ethernet) und Unterstützung für viele Atheros-WLAN-Chips hinzufügt war ich neugierig, wie sich diese CD schlagen würde. Das Ergebnis war gar nicht schlecht:

• Ethernet: nutzbar, flott, stabil
• WLAN: nutzbar, stabil, moderate Systemlast
• Grafik: VESA 1024×768 statt nativer 1366×768

Installation von Ubuntu 9.10

Da Ubuntus 2.6.31er-Installationskernel den JME-Treiber nicht kennt, schlug die favorisierte Netzwerkinstallation über unseren “Plug&Install-Server” leider fehl. Ich brannte also eine Xubuntu Alternate Install CD und installierte von dieser. Das folgende Update und die Nachinstallation von build-essential, m4 und libncurses-dev erfolgte über einen Ralink 2561 802.11g USB-Stick.

Kernelkompilierung und Segfaults

Den Kernel 2.6.33 entpackte ich unter /usr/src und kopierte Ubuntus Konfigurationsdatei nach .config. Ein anschließendes make oldconfig fragt nach den neuen Treibern, die aktiviert werden sollen. Als Faustregel gilt, dass Treiber, die als Modul bereitstehen, als Modul gebaut werden sollen und ansonsten der Vorschlag befolgt werden soll.

Seltsames passierte beim anschließenden Lauf von make: Ich hatte mehrere Segfaults. Da diese zunächst in eher exotischen Treibern auftauchten, vermutete ich Probleme im Zusammenspiel Compiler-Kernel-Architektur. Nach mehrfachen Reboots gelang es mir jedoch, den Kernel durchzukompilieren und zu installieren. Ich wählte den nicht ganz Debian konformen Ansatz mit

make
make install
make modules_install
find /lib/modules/2.6.33 -name '*.ko' -exec strip --strip-unneeded {} \;
update-initramfs -c -k 2.6.33
update-grub

Nach dem Reboot mit dem Kernel 2.6.33 lief der Rechner stabil, auch zwei gleichzeitige Kernel-Kompilierungen parallel konnten ihn nicht mehr aus dem Tritt bringen. Ich tendiere nun dazu anzunehmen, dass eher Probleme von Linux 2.6.31 dem Chipsatztreiber oder dem Core i3 ursächlich für das instabile System waren. wer sich den Ärger ersparen möchte, kompiliert den Kernel auf einer anderen Maschine, erstell mit make deb-pkg ein Debian-Paket und installiert dieses anschließend auf dem A52JR.

Teilerfolg und fehlende Grafiktreiber

Mit Kernel 2.6.33 lädt auch Ubuntu 9.10 korrekt jme für die Gigabit-Ethernetkarte und ath9k für die WLAN-Karte, Sound geht und die Webcam funktioniert mit Cheese (das Bild steht halt Kopf). Mein nächster Versuch galt also ATIs Catalyst-Treiber 10.2 vom 16. Februar 2010. Und da verließen sie ihn…

aticonfig: No supported adapters detected

Eine kurze Recherche auf Atis Website ergab, dass für die Mobility Radeon HD 5470 noch keine Treiber bereitstehen – weder für Linux noch für Windows. Da die Mobilversion andere PCI-IDs verwendet als die verwandte Desktopversion, kann diese erst seit Anfang des Jahres ausgelieferte Karte noch nicht zufriedenstellend genutzt werden. Geht die beigelegte Treiber-DVD verloren, schauen auch Windows-Nutzer in die Röhre. Zumindest bis zum nächsten Update der Catalyst-Treiber. Sollte ASUS sich an seinen bisherigen Zyklus halten, stehen um Mitte März die Treiber für Linux bereit, zehn Tage später Windows-Versionen. Solange muss ich wohl noch mit 1024×768 auskommen. Fortsetzung folgt…

Dateien

• Ausgabe von lspci -vv
• Ausgabe von lspci -nn
• Ausgabe von lsusb
• Ausgabe von dmesg (Kernel 2.6.33)
• Verwendete Kernelkonfiguration für Kernel 2.6.33 (benötigt noch Feinschliff)

Probleme bereitete die Installation und Nutzung des VMware-Players, den ich gerne als recht flexible Virtualisierungslösung einsetze.

Das Installationsproblem

Die Installation ist eigentlich simpel: Man setzt das *.bundle auf executable und startet das Paket dann mit Rootrechten. Doch ein Erfolg wollte sich nicht einstellen. Irgendwo auf halber Strecke hängt der Installer und bewegt sich weder vor noch zurück. Greppt man die Ausgabe von ps waux nach gcc-Prozessen durch, wird man schlafende oder wartende Kompilationsvorgänge finden.

Warum das? Die Kompilierung der VMware-Module verursacht viele Warnungen über fehlende Symbole. Daran verschluckt sich nun der umgebende Python-Prozess und nichts geht voran. Die Lösung hat das VMware-Forum parat:

• Man startet die Installation in zwei Fenstern (je mit Rootrechten)
• In einem der Fenster startet man das Bundle mit dem Parameter --ignore-errors
• Im zweiten Fenster tötet man gnadenlos alle Modul-Bauprozesse:
  while true; do killall -9 vmware-modconfig-console; sleep 1; done
  Die Schleife mit Strg+C abbrechen, wenn die Installation durch ist.
• Am Ende hat man zwar eine VMware, aber keine Kernelmodule, die baut man hinterher mit
  vmware-modconfig --console --install-all
• Nun noch den VMware-Dienst neu starten und der Player lässt sich nutzen

Das Mausproblem

Schnell werdet Ihr feststellen, dass die Maus in der VMware hüpft und immer wieder aus der VMware raus oder in sie rein wechselt. Ein vernünftiges Arbeiten ist so nicht möglich.

Die Lösung des Problems hat Rootloot.de herausgefunden: Eine Inkompatibilität, zwischen Ubuntus Gtk+ und dem Gtk, das die VMware erwartet. Der Trick: Einfach die VMware zwingen, das mitgelieferte Gtk+ zu nutzen, auch wenn die Darstellung nicht zu 100% mit dem Rest des Desktops kongruent sein sollte. Am besten per Export einer Umgebungsvariable. Da ich die VMware eh immer aus einer Shell starte, habe ich mich mit

export VMWARE_USE_SHIPPED_GTK=force

beholfen. Bingo, klappt alles!

• Starke Verschlüsselung: Das Backup muss sicherer sein als diese unsägliche ZIP-Verschlüsselung hinreichend sicher sein und ein statistischer Angriff soll keinen Erfolg versprechen.

• Gute Komprimierung: Ich möchte in kurzer Zeit das Backup klein eindampfen können und beim Zugriff effizient entpacken, also nur die Dateien, die ich benötige.

• Mountbares Backup: Ganz ohne vorheriges Entpacken soll ein sofortiger Zugriff auf alle Dateien im Backup möglich sein.

• Keine unverschlüsselten temporären Dateien: Weder beim Packen noch beim Entpacken sollen unverschlüsselte temporäre Dateien anfallen, einerseits aus Sicherheitsgründen, andererseits weil eine temporäre Datei auf einem zufällig verschlüsselten Dateisystem Prozessorlast erzeugt.

Bis vor kurzem habe ich einfach Archive mit Tarballs mit Twofish verschlüsselt (openssl bietet ein komfortables Subkommando) und diese auf DVD gebrannt. Neben den oben genannten Nachteilen kam das Problem dazu, dass auf einem ISO-9660-Dateisystem die Dateigrößengrenze bei 2GB lag.

Meine Lösung sah eine Kombination aus bekannten Technologien vor: Eine Containerdatei sollte per losetup zum blockorientierten Gerät mutieren, dort wiederum sollte mit cryptsetup ein verschlüsselter Datenträger entstehen, der wiederum ein komprimiertes Squashfs-Dateisystem aufnehmen sollte. Klingt kompliziert? Ist es aber nicht:

Benötigt werden die im Tutorial /home reisetauglich verschlüsselt erwähnten Pakete und die squashfs-tools sowie SquashFS-Module für den laufenden Kernel.

Anlegen des Containers und Befüllen mit Daten

Zuerst wird ein Container angelegt, verschlüsselt und dann mit Daten gefüllt

• Erstellen des Containers: Ein Sparse-File mit der maximal zulässigen Größe einer DVD5 (4700372992 Bytes oder 2295104 Blöcke — bei einer DVD9 müssten es 4150388 Blöcke sein) entsteht mit dem folgenden Befehl. Die Datei belegt am Anfang nur 2048 Byte, angezeigt wird dennoch die maximale Größe:

  dd if=/dev/zero bs=2048 count=1 seek=2295103 of=crypt_squash.data

• Erstellen eines Loop-Devices: Mittels losetup entsteht jetzt eine der Datei zugeordnete Blockdevice:

  losetup /dev/loop0 crypt_squash.data

  Sollte /dev/loop0 bereits besetzt sein, zeigt losetup -f freie Loop-Devices.

• Erstellen des Containers: Auf der Loop-Datei wird nun das verschlüsselte Blockgerät vorbereitet:

  cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y /dev/loop0

• Öffnen des verschlüsselten Gerätes: Nun wird die verschlüsselte Gerätedatei geöffnent. Das Resultat ist ein Blockdevide /dev/mapper/cryptdvd auf das geschrieben werden und von dem gelesen werden kann. Die Verschlüsselung erfogt hier komplett transparent:

  sudo cryptsetup luksOpen /dev/loop0 cryptdvd

• Erstellen des komprimierten Dateisystems: In /dev/mapper/cryptdvd entsteht nun das komprimierte Dateisystem SquashFS. Weil wir in eine Gerätedatei schreiben, muss explizit -noappend angegeben werden, um diese zu überschreiben. Die restlichen Parameter sind Kosmetik: Ich bevorzuge noch aus Kompatibilitätsgründen Komprimierung mit gzip und möchte nur einen Prozessor einspannen.

  mksquashfs Projekte WichtigeDaten /dev/mapper/cryptdvd  -nolzma -check_data -noappend -processors 1

Test des Containers

Nun ist der Test des Containers dran. Funktioniert das Backup so, wie wir es uns vorgestellt haben?

• Mounten des Containers: Das Cryptdevice existiert ja noch, mounten wir es einfach:

  mkdir /tmp/cryptdvd
  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

  Falls ein unbekanntes Dateisystem angegeben wird, sollten Sie sicherstellen, dass das SquashFS-Modul geladen ist und gegebenenfalls den Dateisystemtyp angeben:

  mount -t squashfs /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten:

  umount /dev/mapper/cryptdvd

• Auflösen des Cryptdevices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices: So stellen wir sicher, dass auch alle Daten im Container gelandet sind und wir gefahrlos brennen können:

  losetup -d /dev/loop0

Brennen der DVD

• Brennen der DVD: cdrecord ist es herzlich egal, was für Daten da gebrannt werden, es bannt unseren Container 1:1 auf den optischen Datenträger:

  cdrecord -v -speed=4 -dev=/dev/scd1 crypt_squash.data

Test der gebrannten DVD — Mounten und Unmounten des Backups

• Loop-Device erstellen: Zunächst entsteht ein Loopdevice auf der gebrannten DVD. Es könnte eigentlich auch ohne funktionieren:

  losetup /dev/loop1 /dev/scd1

• Öffnen des Crypt-Devices: Jetzt wird die Datei /dev/mapper/cryptdvd erzeugt, welche die Entschlüsselung transparent macht. Hier ist die Eingabe des Passwortes erforderlich:

  sudo cryptsetup luksOpen /dev/loop1 cryptdvd

• Mounten des Dateisystems: Möglicherweise ist die Angabe des Dateisystemtyps erforderlich:

  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten wie oben:

  umount /dev/mapper/cryptdvd

• Lösen des Crypt-Devices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices:

  losetup -d /dev/loop1

  Nun kann die DVD entnommen werden.

Die meisten der angegebenen Schritte lassen sich leicht automatisieren, so dass sichere Backups sehr einfach durchgeführt werden können und der Zugriff genauso einfach möglich ist. Ein Manko bleibt: Für das Hinzufügen neuer LUKS-Schlüssel muss der Container natürlich mit dd auf Festplatte transferiert und in ein Loop-Device überführt werden, bevor er neu gebrannt wird.

Nachtrag I: Ich stelle diesen Artikel hiermit unter BY-SA zur Verfügung. Wer möchte, kann ihn also per Copy und Paste ins UbuntuUsers-Wiki (oder andere Wikis) übernehmen und dort weiterbearbeiten, solange auf mich als Urheber verwiesen wird. Viel Spaß damit! creativecommons.org/licenses/by-sa/3.0/de/

Nachtrag II: Da einige Community-Wikis NC-BY-SA verwenden und BY-SA nicht nach NC-BY-SA überführt werden kann, zusätzliche Bereitstellung unter NC-BY-SA. Viel Spaß damit! creativecommons.org/licenses/by-nc-sa/3.0/de/

Wer Windows in der von Microsoft vorgesehenen Reihenfolge — erst XP, dann Vista, dann 7 — installiert, wird selten Probleme bekommen: Jedes Windows erkennt seine Vorgänger und bindet diese in den eigenen Bootloader ein. Trickserei ist aber gefragt, wenn kein Windows vom anderen Kenntnis haben soll oder man zu jeder Zeit ein beliebiges Windows durch eine Neuinstallation ersetzen möchte. Der Standard-Bootmanager von Windows scheitert hieran, Abhilfe schafft der kostenlose und von Linux-Distributionen bekannte GRUB. Netter Nebeneffekt meiner Lösung: Jedes Windows hat den Laufwerksbuchstaben C: für die Systempartition.

Im folgenden b eschreibe ich, wie man Windows XP, Windows Vista und Windows 7 unabhängig voneinnader installiert. Je nach Bedarf können Sie auch zweimal XP und einmal 7 installieren oder die Reihenfolge variieren. Einzige Einschränkung ist die Limitation bootfähiger Windows-Versionen auf drei, was durch die maximale Anzahl an primären Partitionen bedingt ist. Wer GRUB auf eine zweite Festplatte, Diskette, USB-Stick oder CD auslagert, kommt auf vier.

Als Werkzeugkiste kommt eine Sidux-Live-CD in Version 2008-04 zum Einsatz. Im Prinzip sollte es jede Live-CD tun, die Gparted und fdisk mitbringt. Schlimmstenfalls sind auf Grund anderer Mountpoints etc. einige Parameter anders einzugeben.

Vorbereitung der Festplatte

Die Partitionierung der Festplatte nehmen wir unter Sidux vor. Rufen Sie in einem Terminalfenster sudo gparted auf, um den Partitionseditor zu starten. Hier legen Sie nun eine primäre Partition mit NTFS-Dateisystem für die erste Windows-Installation, zwei weitere primäre Partitionen ohne Dateisystem und eine kleine (alles ab 30MB aufwärts genügt) primäre FAT16- oder FAT32-Partition für den Bootloader an. Schreiben Sie die Änderungen der Partitionstabelle und ändern Sie anschließend die Flags: Die NTFS-Partition muss das Bootflag gesetzt haben, damit sich Windows problemlos installieren und starten lässt. Bei dieser Gelegenheit können Sie sich gleich mit der Notation für Laufwerke unter Linux vertraut machen: /dev/sda ist die erste Festplatte, die enthaltenen Partitionen sind nummeriert: eins bis vier für primäre, respektive erweiterte und fünf bis unendlich für logische Partitionen.

Installation von Windows XP

Nun ist die Installation von XP an der Reihe. Hier gibt es wenig Spektakuläres zu vermelden: Bei der Installation ist auf die Auswahl der richtigen Partition zu achten, führen Sie eine Schnellformatierung durch, damit sichergestellt ist, dass XP mit der Version des Dateisystems klarkommt.

Sicherung der XP-Installation und Aktivierung einer weiteren Partition

Wir booten nun erneut das Live-Linux-System. Allerdings ist jetzt etwas Kommandozeilen-Voodoo nötig. Achten Sie auf die Details: ein # kennzeichnet einen Root-Prompt, den wir zuvor mit sudo su angefordert haben. Da wir unsere XP-Installation sichern und dann mutwillig beschädigen (!!!) werden, benötigen Sie bspw. einen USB-Stick. In unserem Beispiel dient eine 16GB-Festplatte (es handelt sich um eine VMware) mit einer einzigen FAT32-Partition als Sicherungsmedium. Sie wird als /dev/sdb erkannt.

1. Mounten Sie das Laufwerk, welches zur Sicherung dient, indem Sie es im Bereich “Speichermedien” auf dem Desktop einfach anklicken. Der Befehl “mount” oder “df” verrät dann Mountpoint, also Ordner, unter dem der Datenträger verfügbar ist. In unseren Fall ist dies /media/disk2part1.

   

2. Öffnen Sie ein Terminalfenster, in dem Sie mit sudo su Rootrechte erlangen. Dort lassen Sie dich mit fdisk die aktuelle Partitionierung anzeigen — die XP-Partition wird meist /dev/sda1 sein. Nun sichern Sie mit dd die ersten 16MB der Partition auf die zweite Festplatte oder den USB-Stick: if=... kennzeichnet dabei die als Eingabedatei verwendete Windows-Partition. Anschließend überschreiben Sie die ersten 16MB mit Nullen (Eingabedatei /dev/zero). Sie verhindern so, dass die nächste Windows-Installation das Dateisystem findet und versucht, einzubinden.

   

3. Mit fdisk /dev/sda starten Sie nun den Partitionseditor auf der ersten Platte. Den Typ der ersten Partition ändern Sie mit t auf da (Data), den Typ der zweiten Partition auf NTFS (7). Schließlich entziehen Sie /dev/sda1 mit a das Bootable-Flag und setzen es ebenfalls mit a auf /dev/sda2. Wenn p das gewünschte Ergenis anzeigt, sichern Sie die Partitionstabelle mit w.

   

4. Starten Sie nun den Rechner neu, beispielsweise durch Eingabe des Kommandos reboot.

Installation von Windows Vista

Nun ist die Installation von Vista an der Reihe. Hier gibt es wenig Spektakuläres zu vermelden: Bei der Installation ist auf die Auswahl der richtigen Partition zu achten, führen Sie eine Schnellformatierung durch, damit sichergestellt ist, dass Vista mit der Version des Dateisystems klarkommt.

Sicherung der Vista-Installation und Aktivierung einer weiteren Partition

Wir booten nun erneut das Live-Linux-System. Wieder ist etwas Kommandozeilen-Voodoo nötig. Wir sichern und beschädigen die Vista-Partition so, wie wir es zuvor mit der XP-Partition getan haben. Vergessen Sie das Einbinden des Laufwerks, auf dem Sie die Sicherung ablegen, nicht!

1. Öffnen Sie ein Terminalfenster, indem Sie mit sudo su Rootrechte erlangen. Dort lassen Sie dich mit fdisk die aktuelle Partitionierung anzeigen — die Vista-Partition wird meist /dev/sda2 sein. Auch hier sichern Sie mit dd die ersten 16MB der Partition auf die zweite Festplatte oder den USB-Stick: if=... kennzeichnet dabei die als Eingabedatei verwendete Windows-Partition. Anschließend überschreiben Sie die ersten 16MB mit Nullen (Eingabedatei /dev/zero). Sie verhindern so, dass die nächste Windows-Installation das Dateisystem findet und versucht, einzubinden.

   

2. Mit fdisk /dev/sda starten Sie nun den Partitionseditor auf der ersten Platte. Den Typ der zweiten Partition ändern Sie mit t auf da (Data), den Typ der dritten Partition auf NTFS (7). Schließlich entziehen Sie /dev/sda2 mit a das Bootable-Flag und setzen es ebenfalls mit a auf /dev/sda3. Wenn p das gewünschte Ergenis anzeigt, sichern Sie die Partitionstabelle mit w.

   

3. Starten Sie nun den Rechner neu, beispielsweise durch Eingabe des Kommandos reboot.

Installation von Windows 7

Nun ist die Installation von Windows 7 an der Reihe. Sie verläuft wie die von Vista. Formatieren Sie die vorgesehene Partition und fahren Sie wie gewohnt fort.

Schreiben des Bootloaders

Jetzt muss der GRUB-Bootloader geschrieben werden. Mounten Sie hierfür die Partition, die GRUB später aufnehmen wird (im Beispiel /dev/sda4, gemountet unter /media/disk1part4) und die Partition, welche die gesicherten Partitionsanfänge enthält (im Beispiel /dev/sdb1, gemountet unter /media/disk2part1).

1. Prüfen Sie zunächst mit df | grep sd, ob die beiden benötigten Partitionen wirklich eingehängt sind. Anschließend schreiben Sie GRUB mit den auf dem Screenshot erkennbaren Parametern: --root-directory=/media/disk1part4 kennzeichnet die Partition, auf der die Konfiguration abgelegt ist, /dev/sda ist die Zielplatte.

   

2. GRUB benötigt nun noch eine Konfigurationsdatei /boot/grub/menu.lst auf der Installationspartition, hier also /media/disk1part4/boot/grub/menu.lst. Verwenden Sie den Befehl sudo kate /media/disk1part4/boot/grub/menu.lst um die Konfigurationsdatei anzulegen.

   

   Hier die vollständige Konfiguration für Copy&Paste:

   default 1
   timeout 10
   
   title Windows XP
   root (hd0,0)
   hide (hd0,1)
   hide (hd0,2)
   unhide (hd0,0)
   savedefault
   makeactive
   chainloader +1
   
   title Windows Vista
   root (hd0,1)
   hide (hd0,0)
   hide (hd0,2)
   unhide (hd0,1)
   savedefault
   makeactive
   chainloader +1
   
   title Windows 7
   root (hd0,2)
   hide (hd0,0)
   hide (hd0,1)
   unhide (hd0,2)
   savedefault
   makeactive
   chainloader +1

   Zu bemerken ist, dass GRUB Laufwerke anders kennzeichnet als Linux selbst: Zunächst fängt die Zählung bei Null an, zudem verwenden Platten keine Buchstaben. (hd0,0) ist also die erste Partition der ersten Festplatte. Unsere GRUB-Konfiguration versteckt bei jedem Start einer Windows-Installation die anderen (hide) und holt die eigene hervor (unhide). Übrigens: Um immer den zuletzt gewählten Eintrag zu starten, verwenden Sie default saved.

Anpassung der Partitionstypen

Nun müssen die mutwillig beschädigten Installation von XP und Vista repariert werden und die Partitionstypen wieder korrigiert werden:

1. Verwenden Sie wieder dd, um die gesicherten Partitionsanfänge zurückzuschreiben. Blockgröße und -anzahl sind jetzt nicht nötig:

   

2. Mit fdisk setzen Sie die Typen der als Datenpartition markierten Partitionen sda1 und sda2 jetzt wieder auf NTFS (7):

   

Der erste Start

Und so sieht GRUB dann aus:

Sollten Sie eine Windows-Installation neu installieren müssen, ist dies ganz einfach: Sichern Sie mit dd die Partitionsanfänge der beiden anderen, überschreiben Sie diese mit Nullbytes und ändern Sie den Partitionstyp auf da. Dann installieren Sie das Windows erneut. Nach abgeschlossener Installation setzen Sie die Partititionstypen zurück und spielen die gesicherten Partitionsanfänge zurück. Unter Umständen müssen Sie GRUB erneut installieren, wobei jedoch die Konfiguration erhalten bleibt.

So, nach den Startschwierigkeiten gestern klappte nun die Installation von Ubuntu 8.04.1 auf dem Akoya E1210. Als Installationsmedien verwendete ich einen USB-Stick (SD-Karten funktionieren ebenfalls). Bootfiles hierfür habe ich so zusammengestellt, dass auch unbedarfte Nutzer schnell zur Alternate Install kommen dürften:

• Laden Sie die Datei ubuntu-8.04.1-alternate-i386.usb.zip (Ubuntu 8.04.1), ubuntu-8.10-alternate-rc1-20081024-i386.usb.zip (Ubuntu 8.10 RC) oder xubuntu-8.10-alternate-rc1-20081024-i386.usb.zip (Xubuntu 8.10 RC, bevorzugt!) herunter und entpacken Sie das Archiv

• Entpacken Sie das (in der ZIP-Datei) enthaltene Paket syslinux-3.55.tar.bz2 (nur unter Linux notwendig)

• Schreiben Sie mit dem Befehl

  cat syslinux-3.55/mbr/mbr.bin > /dev/sdx

  den MBR des Sticks (x bitte durch b, c, d… wasauchimmer ersetzen)

• Stellen Sie sicher, dass die erste/einzige Partition des Sticks bootfähig/aktiv markiert ist (gparted oder fdisk)

• Unmounten Sie den Stick (falls er gerade gemountet ist) und schreiben Sie mit dem Befehl

  ./syslinux-3.55/unix/syslinux /dev/sdx1

  den Bootloader auf den Stick

• Windows-Nutzer: Es liegt eine makeboot.bat bei, welche sowohl den MBR als auch den Bootloader schreibt und nach dem Laufwerksbuchstaben fragt

• Kopieren Sie nun den gesamten Inhalt des Unterordners stick/ in das Wurzelverzeichnis des USB-Sticks

Der USB-Stick ist nun bootfähig und kann unmittelbar nach dem BIOS-Selbststest mit F11 (Medion Akoya E1210) oder Esc (EeePC 701 und 900) als Bootmedium ausgewählt werden. Die Installationsroutine durchsucht dann alle Laufwerke nach dem Installations-Image und startet die Alternate-Install ansonsten genau wie von CD.

Xubuntu oder Kubuntu: Wer statt dem gewöhnlichen Ubuntu ein Kubuntu oder Xubuntu installieren möchte, sollte das Zip-Archiv ubuntu-8.04.1-alternate-i386-bootonly.usb.zip verwenden. Kopieren Sie dann das 8.04.1-Alternate-ISO-Image der gewünschten Ubuntu-Geschmacksrichtung in den Ordner install/ und passen Sie in der Datei syslinux.cfg den Namen des Seeds an. Für 8.10 folgt diese Option mit der finalen Version.

Idee von http://ubuntuforums.org/showpost.php?p=4404569&postcount=37.

Eventuell hilfreich:

• Artikel PC Magazin Linux 03/2006 “Pocket-Pinguin” — Konfiguration und Einrichtung von Syslinux

Update, 18. September, 10. Oktober, 24. Oktober: Unter eeepc.mattiasschlenker.de stehen auch Installationsimages für Ubuntu 8.10 Alpha Beta RC bereit. Die werden alle ein bis zwei Wochen aktualisiert.