Paket voller Kompromisse

Da Asus noch kein Testgerät liefern konnte, kaufte ich einen x101 auf mein Unternehmen. Die dahinterstehende Kalkulation war, dass selbst bei einem Weiterverkauf mit 25% Wertverlust kein allzu großer Schaden eintreten würde. Allerdings habe ich derzeit einen Eee PC 1015B mit Zweikern AMD zur Hand, der für Fotos herhalten muss und als Vergleichsobjekt hinsichtlich der Verarbeitungsqualität.

Was sofort auffällt ist die dünne Bauform und das relativ leichte Gewicht. Das Gewicht ist nicht nur dem Wegfall der Festplatte, sondern auch dem vergleichsweise kleinen Akku geschuldet, der mit drei Zellen und 28Wh rund vier Stunden durchhält. Das ist meiner Erfahrung nach ausreichend, da ich längere Zugfahrten meide und sogar auf der Argentinienreise der alte Eee PC 701 als elektronisches Reisetagebuch auf langen Busfahrten genug durchhielt.

Schaut man sich das x101 näher an, stellt man eine Reihe weiterer Kompromisse fest:

• Tastatur: Die F-Tastenreihe fehlt. Um überhaupt USB-Anschlüsse unterbringen zu können, mussten diese an den dicksten Teil des Gehäuses rutschen, der Platz reichte dort dennoch nicht für darüber angebrachte Tasten. Die F-Tasten wurden kurzerhand gespart und die Tiefe der Tasten reduziert. Auch der Hub fällt geringer aus, so lässt sich gerade noch flüssig tippen.

• Ethernet: Gibt es nicht, es musste schon beim 1015B in einer Klapplösung umgesetzt werden. Fürs Netz gibt es nur WLAN.

• VGA/HDMI: Gibt es nicht, es war schlichtweg kein Platz für den Port da.

• USB: Zwei Ports müssen genügen, USB 3.0 und eSATA fehlt.

• Kartenleser: Statt SD ist MicroSD eingebaut – der hat unter der Tastatur Platz.

• Audio In/Out: Es gibt nur einen kombinierten Port, beispielsweise zur Verwendung mit typischen Handy-Headsets.

Gut zu erkennen – die F-Tastenreihe wurde geopfert, ansonsten hätte kein USB-Port Platz gehabt:

Die Dicke im direkten Vergleich mit dem Eee PC 1015B – dieser sieht plötzlich klobig aus:

Software

Vorinstalliert ist MeeGo in Version 1.1. Die ist schon etwas älter und weist einige Lücken bei der Lokalisierung auf. Ich habe daher nach einer halben Stunde rumprobieren Ubuntu 11.04 (in der 32 Bit Variante) mit Unity als Desktop installiert. Auf MeeGo 1.2 werde ich an anderer Stelle eingehen, ich sehe ein recht großes Potential für viele typische Netbook-Nutzer.

Zurück zu Ubuntu: Dank für Desktopeffekte brauchbar umgesetzter Hardwarebeschleunigung des Intel GMA 3150 läuft Unity schonmal reibungslos. Sowohl Sound, WLAN als auch ACPI (Helligkeit, rfkill) funktionieren einwandfrei. Anwendungen sind merklich träger als bei einem Dual-Core Atom oder AMD C-Serie, aber noch absolut im Bereich des gut Nutzbaren. Meine Ubuntu-Installation umfasste eine Root-Partition mit vier Gigabyte, eine Home-Partition mit deren drei und ein GB Swap. Eine meiner Ansicht nach bessere Partitionierung mit /usr auf einem SquashFS-Container werde ich demnächst separat vorstellen.

Fazit

Die eingegangenen Kompromisse sind spürbar, aber nicht schmerzhaft. Die F-Tastenreihe dürfte einigen Powerusern fehlen, mir fiel die umständliche Zugänglichkeit der Textkonsole (Strg+Alt+Fn+2) oder des oft in regulären Ausdrücken benötigten “^” auf. Abgesehen davon ist die Tastatur um längen besser als bei den Neunzöllern von vor drei oder vier Jahren. Als mobiles Admin- und Präsentationstool eignet sich das x101 dagegen nur eingeschränkt: Muss man eine Präsentation halten, ist ein USB-VGA-Adapter nötig, der nicht immer einfach einzurichten ist. Gleiches gilt für die Netzwerkwartung, wo ich gerne mit einem TFTP-Bootserver auf dem Notebook herumlaufe, der aber einen Ethernetport erfordert – da werde ich wohl weiterhin Lenovos x100e mitnehmen (und dieses mittelfristig durch ein x121e ersetzen).

Im angepeilten Einsatzbereich – Social Media, Schreibmaschine für Unterwegs und Internet Client trifft Asus die Zielgruppe fast punktgenau und überzeugt hier mit dem leichten Gewicht und dem schnellen Start. Den günstigen Preis muss ich etwas relativieren, mittlerweile haben Speicherriegel (11€ für 2GB) und Micro-SDHC-Karte (20€ für 16GB) den Preis auf genau 200€ hochgetrieben – das liegt über dem eines besser ausgestatteten Acer Aspire One D525 mit fast doppelter Akkulaufzeit und 250GB Festplatte – aber eben 300 Gramm mehr und einem klobigeren Netzteil (188€ derzeit bei Media Markt Krefeld).

Einziges Ärgernis ist nur den Verzicht auf Bluetooth, weil eben noch nicht jeder ein Handy mit AP-Funktion hat und eben auch viele BT-Mäuse im Umlauf sind. Nach den ersten Tagen mit dem x101 kann ich jedenfalls ziemlich sicher sagen, dass ich wieder häufiger mit Netbook unterwegs sein werde und hoffe insgeheim, dass Asus den wiedergefundenen “wahren Netbook-Pfad” nicht verlässt und stattdessen vielleicht eine Luxus-Variante des x101 auflegt – wie wäre es mit einem Dual-Core Atom, zwei GB RAM, 32GB SSD und Bluetooth im gleichen Gehäuse mit gleicher oder möglicherweise etwas besserer Akkulaufzeit?

Ich bin dann so vorgegangen:

1. Beide Platten mit einem SATA2USB-Adapter an den Linux-Desktop-Rechner angeschlossen

2. Mit
   dd if=/dev/sdx of=/dev/sdy bs=1M
   die alte (sdx) auf die neue (sdy) Platte geklont

3. Mit
   gdisk /dev/sdy
   die Platte im GPT-Partitionierungstool geöffnet und eine Partition vom Typ 0700 auf dem Rest der Platte angelegt, mit w bestätigt – das korrigiert die Position der Backup-GPT

4. Die Platte abgestöpselt und in den Mac eingebaut

5. Den Mac gebootet und dort im Festplattendienstprogramm die leere Partition gelöscht und die OS X Partition etwas gestreckt

Klappte prima und erspart mir eine Neuinstallation von OS X. Ich habe jetzt noch Platz, um demnächst Ubuntu drauf unterzubringen.

The content of this blog entry is partially based on the “semi official tutorial” how to cross compile BusyBox and partially on my experience with Linux from Scratch, especially Chapter 5 – Constructing a temporary system. At the time of this being written, I tried to make sure that very few patches are necessary – this will not always be the way, maybe GCC 4.7 will need more patches or BusyBox 1.19 does. uClibc 0.9.32 does not yet build cleanly on x86, thus I stay with uClibc 0.9.31.1 for this time:

Needed files

Sources and patches:

• GNU Binutils 2.21

• GCC 4.6.0 plus gcc-4.6.0-cross_compile-1.patch
• Linux sources 2.6.39.2
• uClibc 0.9.31.1
• BusyBox 1.18.5
• Gmp 5.0.2
• Mpfr 3.0.1
• Mpc 0.9

Configuration files:

• busybox-1.18.5.config
• uClibc-0.9.31.1.config

1. Setting up the environment

Very few modifications to the environment are necessary. We just need three variables:

    export TGTARCH=i486
    export INSTDIR=/usr/local/crosstools
    export PATH=${INSTDIR}/bin:${PATH}

$TGTARCH is the targeted architecture, it should be either i486, i586, i686 or x86_64. Of course it is possible to build for several ARM or MIPS targets if you need a statically linked BusyBox for a rooted Android device or a DSL router. There is one drawback however: My configs for uClibc and BusyBox are very x86 specific. For the first build I recommend using the same target architecture as the machine you are building:

    export TGTARCH=` uname -m `

$INSTDIR is the location of the resulting toolchain. When building for different target architectures, you might also include the name of the target arch into the path. This makes deinstallation easier – you just have to delete a branch in the file system. For example:

    export TGTARCH=i486
    export INSTDIR=/usr/local/uclibc-crosstools-${TGTARCH}
    export PATH=${INSTDIR}/bin:${PATH}

2. Building binutils

Unpack the binutils and create a directory binutils-build on the same level of the file system, then configure binutils:

    tar xvjf binutils-2.21.tar.bz2
    mkdir binutils-build
    cd binutils-build
    ../binutils-2.21/configure \
        --target=${TGTARCH}-linux-uclibc \
        --prefix=${INSTDIR} --disable-nls \
        --disable-werror

Now build and install binutils:

    make && make install

3. Building GCC

As far as I tested, GCC needs a small patch to result in a properly working cross compiler. Besides this, GMP, MPFR and MPC must be present:

    tar xvjf gcc-4.6.0.tar.bz2
    tar xvjf mpfr-3.0.1.tar.bz2
    tar xvjf gmp-5.0.2.tar.bz2
    tar xvzf mpc-0.9.tar.gz
    mv mpfr-3.0.1 gcc-4.6.0/mpfr
    mv gmp-5.0.2 gcc-4.6.0/gmp
    mv mpc-0.9 gcc-4.6.0/mpc
    mkdir gcc-build
    cd gcc-4.6.0
    cat ../gcc-4.6.0-cross_compile-1.patch | patch -p1
    cd ../gcc-build

Now configure, build and install GCC:

    ../gcc-4.6.0/configure \
        --target=${TGTARCH}-linux-uclibc \
        --prefix=${INSTDIR} \
	--disable-nls --disable-shared --disable-multilib \
        --disable-libmudflap --disable-libssp --disable-libgomp \
        --disable-libquadmath --disable-target-libiberty \
        --disable-target-zlib --disable-decimal-float \
        --disable-threads --enable-languages=c \
	--without-ppl --without-cloog
    make && make install

4. Installing kernel headers

The kernel headers used should ressemble the version you intend to run the BusyBox on. Unpack and install them – the sanitizing step is taken from Linux from Scratch:

    tar xvjf linux-2.6.39.2.tar.bz2
    cd linux-2.6.39.2
    make INSTALL_HDR_PATH=dest headers_install
    find dest/include \( -name .install -o -name ..install.cmd \) -delete
    mkdir -p ${INSTDIR}/${TGTARCH}-linux-uclibc/include
    cp -rv dest/include/* ${INSTDIR}/${TGTARCH}-linux-uclibc/include

In the next steps ${INSTDIR}/${TGTARCH}-linux-uclibc will become more populated with headers, libraries and other development files for our build target.

5. Installing uClibc

Unpack uClibc and copy the config into the resulting directory. Since uClibc uses the same configuration scheme as the Linux kernel, some parameters in the config have to be changed with sed, and a run of make oldconfig is needed if you do not run my exact version of uClibc:

    unxz -c uClibc-0.9.31.1.tar.xz | tar xvf -
    cp uClibc-0.9.31.1.config uClibc-0.9.31.1/.config
    cd uClibc-0.9.31.1
    # This fixes the path of the linux headers
    sed -i 's%/usr/local/crosstools/i486-linux-uclibc/include%'${INSTDIR}/${TGTARCH}-linux-uclibc/include'%g' .config
    # This fixes the path to GCC and binutils:
    sed -i 's%/usr/local/crosstools/bin/i486-linux-uclibc-%'${INSTDIR}/bin/${TGTARCH}-linux-uclibc-'%g' .config
    make oldconfig

When building for x86_64 instead of i486-i686, replace the target as well:

    sed -i 's%TARGET_i386=y%#TARGET_i386 is not set%g' .config
    sed -i 's%# TARGET_x86_64 is not set%TARGET_x86_64=y%g' .config
    make oldconfig

Now build and install uClibc:

    make
    make install PREFIX=${INSTDIR}/${TGTARCH}-linux-uclibc/

Everything is in place now. In the next step we are building the statically linked BusyBox:

6. Building BusyBox

Our BusyBox will be statically linked. Since BusyBox also uses the configuration scheme from the Linux kernel, configuration is done by copying the .config file:

    tar xvjf busybox-1.18.5.tar.bz2
    cp busybox-1.18.5.config busybox-1.18.5/.config
    cd busybox-1.18.5
    make oldconfig CROSS_COMPILE=${TGTARCH}-linux-uclibc-

Build BusyBox and install it to the subdirectory _install:

    make CROSS_COMPILE=${TGTARCH}-linux-uclibc-
    make install CROSS_COMPILE=${TGTARCH}-linux-uclibc-

If your build system is x86_64, any i486 to i686 or x86_64 can be directly run. There will be no hassle with libraries since our binary is statically linked:

    # Should result in: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
    file _install/bin/busybox
    # Should print the BusyBox applets contained
    ./_install/bin/busybox

That’s it. Have fun with your BusyBox. In a short time I will tell you how to configure and build a minimal Linux system that just consists of a kernel, BusyBox and Dropbear for SSH logins – that is just enough Linux to do imaging and restoring tasks.

• LessLinux: Die CD “DE-Cleaner-Rettungs-System” (Pressemitteilung) basiert auf meinem LessLinux. War viel Arbeit, weniger im technischen Sinne, mehr im Sinne der Koordination der Projektpartner. Ich bin handwerlich zufrieden mit dem Ergebnis, würde aber aber nach einer Zwischenauswertung der Leserfragen eine deutlich simplere Nutzerführung bevorzugen. Das war in der kurzen Projektphase nicht möglich, also bleibt es bei dieser Oberfläche. Ärgerlich: Es wurden wohl ein paar Tausend fehlgepresste Datenträger ausgeliefert, so dass ich bei Supportanfragen nie weiss, ob ein Problem nun eher auf problematische Hardware, meine Erkennungsroutinen oder eine kaputte CD zurückzuführen ist.

• LessLinux, nochmal: Ich arbeite gerade an einer Funktion, die anhand von Strace-Logs prüft, auf welche Dateien während eines Builds zugegriffen wird und welche gesucht, aber nicht gefunden werden. Ziel ist ein Abhängigkeitsmanagement, welches auch vorschlägt, welche Bibliotheken vorher installiert werden, könnten, beispielsweise wenn ./configure zur Laufzeit anhand installierter Programme festlegt, welche Eigenschaften einkompiliert werden. Momentan läuft eine Analyse einer Glibc-Kompilation — die Strace-Logdatei hat 1,4GB oder 13 Millionen Zeilen und will natürlich komplett durchs RAM und dort analysiert werden…

• Nokia: Wie etwas so sucken kann… Ich habe seit ein paar Tagen ein E5, Nachfolger meines E71. Schönere Kamera, bessere Nutzerführung, toller, übersichtlicher Email-Client. Flotter Webbrowser, spielt Youtube. 3.5mm Klinke. Aaaaber: Um VoIP einzurichten musste ich ein Zusatzprogramm runterladen. Mein Bluetooth-Keyboard will noch immer nicht. Auf der Nokia World stellt Ihr tolle Hardware wie das E7 vor, aber kein Wort zu MeeGo? Sicher ist Symbian^3 nicht wirklich schlecht, sogar richtig viel besser als S60 5th, aber das Highend bedient Ihr damit nicht!

• Auf Wolken gehen: Peter Voit war ein Nachbarjunge, einer der großen, sechs oder sieben Jahre älter als ich. Irgendwie ist aus ziemlich vielen der Nachbarjungen (ich schließe mich da nicht aus) etwas geworden. Peter wurde Mitgründer von Transsolar und die machen nun Wolken. Das kann praktisch sein, wenn man die Lichteintrahlung in einem Gebäude beeinflußen will: Video bei Youtube.

Einige weitere Modifikationen wie Bootsplash mit fbsplash, die demnächst in einem kommerziellen Derivat sichtbar sein werden, sind noch nicht aktiv. Hier geht’s lang zum Blogpost:

http://blog.lesslinux.org/fresh-development-build-isohybrid-conversion-and-boot-on-xen/

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

Auf 64-Bit-Systemen außerdem:

apt-get install libc6-dev-i386

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

Das mag auf den ersten Blick verwundern, auf den zweiten scheint es logisch: Die Anforderungen an die Sicherheitsmechanismen der Sicher-Surfen-CD wurden vom BSI festgelegt, die Umsetzung dieser vom TÜV geprüft. Dabei bin ich durchaus auch eigene Wege gegangen, so habe ich die Integration des einfachen MAC-Modells SMACK statt SELinux durchgesetzt und als Basis eben keine Debian-Distri genommen, sondern mein damals (vor anderthalb Jahren) noch in den Kinderschuhen befindliches LessLinux.

In den letzten Wochen hat sich im Blog von LessLinux wenig getan, hinter den Kulissen umso mehr. Worum es ging, darf ich noch nicht sagen. Stay tuned, in zwei Wochen wisst Ihr mehr.

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.

Der Haken: Es sollte Features bieten oder als stabile Software zu Nachrüstung bereithalten, die ich am E71 nicht mehr missen möchte:

• Tethering möglichst per Bluetooth und Funktion als WLAN-Hotspot
• SIP-Client
• SyncML-Client oder Funambol-Plugin erhältlich
• Unterstützung für Bluetooth-Tastaturen

Eigentlich nix Wildes, aber drei der vier Punkte sind meines Wissens schwer umzusetzen. Dazu würde mich interessieren: Wie haltet Ihr Smartphone und Linux-Rechner synchron? Ich nutze einen eigenen Funambol-Server und das Funambol-Addon für Thunderbird 3.0. Das klappt prima mit Kontakten und Terminen.