Hinweis: Auf dieses Tutorial folgt ein weiteres, das die hier gezeigte Konfiguration um GRUB erweitert (um 32-Bit-Systeme booten zu können) und eines, das erklärt, wie schließlich ein hybrider Stick entsteht, der auf MBR- und UEFI-Systemen startet. Wer aus dem dritten Tutorial das Optimum herausholen möchte, sollte eine dritte, 100 bis 200MB große, leere FAT32-Partition einplanen.

Wie bootet UEFI sicher vom Stick?

Der Vorgang von USB ist etwas einfacher als von Festplatte, zumindest wenn es sich um einen GPT partitionierten Stick mit einer einzigen FAT32-Partition handelt. In diesem Fall genügt es, eine Ordnerstruktur “BOOT/EFI” anzulegen, die den Bootloader “BOOTX64.EFI” enthält. Hintergrund dieser Vereinfachung ist wohl, dass es ermöglicht werden soll, alleine durch das Entpacken eines Zips mit den Bootdateien einen Stick bootfähig zu machen – aber das ist Spekulation, weder habe ich nachgeprüft welche UEFI-Implementierungen den einfachen Start unterstützen, noch habe ich getestet, ob in nennenswerten Stückzahlen USB-Sticks am Markt sind, die sowohl GPT als auch BIOS-MBR aufweisen.

In diesem Tutorial möchte ich mit dem simpelsten Bootmechanismus mit dem PreLoader.efi der LinuxFoundation als erste Stufe und Gummiboot als zweiter Stufe zum Start zum Start von 64-Bit-EFI-Kerneln beginnen. Zum Start von 32-Bit-Kerneln muss ein zwischengeschalteter GRUB genutzt werden, dafür wird es ein Follow-Up geben. Der Stick bekommt zwei Partitionen: Eine EXT4-Partition für die ISO-Images vorne und eine kleine Bootpartition, die Kernel, Initramfs und EFI-Boot-Dateien aufnehmen muss, hinten. Beachten Sie, dass die Bootdateien für ein LessLinux rund 50MB groß sind, die für ein Ubuntu etwas über 20MB – für zweimal LessLinux, zweimal Ubuntu und die EFI-Boot-dateien sind demnach 150MB einzuplanen.

Die Partitionierung

Zunächst gilt es, den Stick zu partitionieren. Damit keine Spuren von MBR, Partitionstabelle, GPT und möglicherweise alten Partitionsanfängen vorhanden sind, sollten die ersten vier Megabyte komplett genullt werden:

USBSTICK=/dev/sdx
dd if=/dev/zero bs=1M count=4 of=$USBSTICK

Zur Partitionierung kommt “parted” auf der Kommandozeile zum Einsatz:

parted $USBSTICK

Sie befinden sich nun in der Shell von Parted, hier gilt es, eine GUID Partition Table anzulegen:

Willkommen zu GNU Parted! Geben Sie 'help' ein, um eine Liste der verfügbaren Kommados zu erhalten.
(parted) mklabel gpt                                                      
(parted) print                                                            
Modell: Kingston DataTraveler 2.0 (scsi)
Festplatte  /dev/sde:  4039MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt

Nummer  Anfang  Ende  Größe  Dateisystem  Name  Flags

(parted)

Als erste Partition erstelle ich eine einfache Linux-Partition, die der Gesamtgröße minus 150 MB entspricht, sie soll später Daten aufnehmen:

(parted) mkpart primary ext4 0 3890M

Inkorrektes Alignment kann man beim USB-Stick zumeist ignorieren (sollte man aber nicht bei SSDs und schnellen Platten). Es folgt die Bootpartition fürs EFI, diese muss FAT12/16/32 sein:

(parted) mkpart primary fat32 3890M 4039M

Diese zweite Partition bekommt jetzt das Bootflag gesetzt (eigentlich heisst dies bei GPT, dass der Typ auf EF00 gesetzt wird), danach betrachten wir das Ergebnis und schreiben die Partitionstabelle:

(parted) set 2 boot on                                                    
(parted) print                                                            
Modell: Kingston DataTraveler 2.0 (scsi)
Festplatte  /dev/sde:  4039MB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt

Nummer  Anfang  Ende    Größe   Dateisystem  Name     Flags
 1      17,4kB  3890MB  3890MB               primary
 2      3890MB  4038MB  148MB                primary  boot

(parted) quit

Die Prüfung mit

gdisk -l $USBSTICK

offenbart etwas mehr als “parted” (ich verwende parted, weil es sich auch gut scripten lässt):

GPT fdisk (gdisk) version 0.8.5

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sde: 7888896 sectors, 3.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): E12939B9-C620-435B-9E9B-27312CCBF9BC
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 7888862
Partitions will be aligned on 2-sector boundaries
Total free space is 2438 sectors (1.2 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              34         7597656   3.6 GiB     0700  primary
   2         7598080         7886847   141.0 MiB   EF00  primary

Jetzt noch beide Partitionen formatieren und die Vorbereitung ist abgeschlossen:

mkfs.ext4 ${USBSTICK}1
mkfs.msdos -F32 ${USBSTICK}2

Installation des (Pre-)Bootloaders

Zunächst erstelle ich zwei Mountpoints für die Datenpartition und die Bootpartition und mounte beide. Wieder kommen Variablen zum Einsatz:

USBDATA=/tmp/usbdata
USBBOOT=/tmp/usbboot
mkdir -p ${USBDATA}
mkdir -p ${USBBOOT}
mount ${USBSTICK}1 ${USBDATA}
mount ${USBSTICK}2 ${USBBOOT}

Auf der Bootpartition entsteht nun die Ordnerstruktur für den Start unter EFI:

mkdir -p ${USBBOOT}/EFI/BOOT

In diesen Ordner installieren wir nun PreLoader.efi (als BOOTX64.EFI) und HashTool.efi der Linuxfoundation. Beide Binaries müssen signiert sein, bei diesen kommt demnach kein Selbstbau in Frage:

wget -O ${USBBOOT}/EFI/BOOT/BOOTX64.EFI http://blog.hansenpartnership.com/wp-uploads/2013/PreLoader.efi
wget -O ${USBBOOT}/EFI/BOOT/HASHTOOL.EFI http://blog.hansenpartnership.com/wp-uploads/2013/HashTool.efi

Wer möchte kann auch noch das KeyTool.efi installieren, ich findes es ganz praktisch, um MOKs (Machine Owner Keys zu verwalten. Ein Binary befindet sich im USB-Image von James Bottomley, ich habe es extrahiert:

wget -O ${USBBOOT}/EFI/BOOT/KEYTOOL.EFI http://cdprojekte.mattiasschlenker.de/Public/UEFI-Secure-Boot/keytool.efi

Im Prinzip würde der so erstellte Stick bereits booten, wenn auch nur bis zur Hash-Verwaltung.

Gummiboot als Loader

Als Loader der zweiten Stufe habe ich mich für Gummiboot entschieden, weil er 64-Bit-Linux-EFI-Kernel direkt starten, aber auch andere EFI-Binaries aufrufen kann. Ich habe versucht, Gummiboot auf einem Ubuntu 12.10 gegen die mitgelieferte und eine aktuelle Version der gnu-efi-Bibliothek zu kompilieren und bin gescheitert. Daher habe ich Gummiboot vom USB-Image von James Bottomley kopiert:

wget -O ${USBBOOT}/EFI/BOOT/LOADER.EFI http://cdprojekte.mattiasschlenker.de/Public/UEFI-Secure-Boot/gummiboot-bottomley.efi

Gummiboot benötigt nun einen Ordner für die Konfiguration, der die Bootmenüeinträge aufnimmt:

mkdir -p ${USBBOOT}/loader/entries

Die Konfigurationsdatei ${USBBOOT}/loader/entries/cclessli.conf (eingerückte Zeilen gehören zur Zeile “options”, bitte die Umbrüche entfernen):

title LessLinux Search and Rescue
linux    /ll64.efi
initrd   /ll64.img
options  ultraquiet=1 security=none skipcheck=1 quiet lang=de ejectonumass=1
    skipservices=|installer|xconfgui|roothash|firewall|ssh|mountdrives|
    hwid=unknown laxsudo=1 toram=0 uuid=c7e701f3-bd3c-494b-8395-1e5bdb513f41
    loop.max_loop=32 console=tty2 radeon.modeset=0 nomodeset

Achtung: Ein Bug in LessLinux erfordert es derzeit, die UUID der Partition anzugeben, auf der sich das ISO befindet (uuid=c6e...), ermitteln Sie diese mit dem Befehl blkid:

blkid  -o udev ${USBSTICK}1 
ID_FS_UUID=c7e701f3-bd3c-494b-8395-1e5bdb513f41

…und eine Konfigurationsdatei, um einfach das Hashtool aufrufen zu können, ${USBBOOT}/loader/entries/yyhashto.conf:

title Hashtool
linux    /EFI/BOOT/HASHTOOL.EFI

…und schließlich eine fürs Keytool, um Hashes und Schlüssel zurückziehen zu können, ${USBBOOT}/loader/entries/zzkeytoo.conf:

title Keytool
linux    /EFI/BOOT/KEYTOOL.EFI

Schließlich folgt noch die Konfigurationsdatei für den Gummiboot-Loader selbst, ${USBBOOT}/loader/loader.conf:

timeout 10
default cclessli*

Und nun das Lesslinux-Image

Damit wir wirklich ein bootfähiges System bekommen, dürfen wir das System-ISO nicht vergessen. Zudem müssen Kernel und Initramfs auf die EFI-Boot-Partition kopiert werden:

LESSLINUX=lesslinux-search-and-rescue-uluru-20130226-123741.iso
wget -O ${USBDATA}/${LESSLINUX} http://download.lesslinux.org/testing/lesslinux-search-and-rescue/${LESSLINUX} 
mkdir /tmp/lliso
mount -o loop ${USBDATA}/${LESSLINUX} /tmp/lliso
cp /tmp/lliso/boot/isolinux/l3800sf ${USBBOOT}/ll64.efi
cat /tmp/lliso/boot/isolinux/{initram,i3800sf}.img > ${USBBOOT}/ll64.img
umount /tmp/lliso

Der erste Start

Bitte nicht vergessen, den Stick zu unmounten:

umount $USBDATA
umount $USBBOOT

Nun wird es spannend: Stöpseln Sie den Stick an einen UEFI-PC mit aktiviertem Secure Boot an und starten Sie diesen. Wie bei BIOS-rechnern führt in der Regel F10, F12 oder ESC zum Bootmenü, Lenovo- (und wohl einige Medion-) Notebooks schalten Sie über die kleine Taste (“OneKey Rescue”) neben dem Powerbutton an. Der als BOOTX64.EFI abgelegte PreLoader.efi findet keinen hinterlegten Hash für “LOADER.EFI”, und startet “HashTool.efi”. Wählen Sie hier den zuerst den Hash des als “LOADER.EFI” abgelegten Gummiboots und dann den Hash des Linux-Kernels “ll64.efi” zur Aufnahme aus. Anschließend rebooten Sie das System und starten erneut vom Stick, jetzt erscheint das einfache Bootmenü von Gummiboot, in dem Sie LessLinux, HashTool.efi oder KeyTool.efi (um Hashes zurückzuziehen) auswählen können.

Uffz, geschafft. Bottomleys Gummiboot startet leider nicht Ubuntus signierte Kernel, hierfür muss als zweite Stufe ein GRUB her, doch dazu später mehr…

In diesem Beitrag möchte ich die eher theoretischen Hintergründe erläutern und Entscheidungshilfen geben, demnächst folgen dann Beiträge zur praktischen Umsetzung von Secure Boot eigener Kernel auf USB-Sticks, optischen Datenträgern und via Netzwerk.

Microsoft als Gatekeeper?

Ein großer – nicht von der Hand zu weisender – Kritikpunkt war Microsofts Rolle als Gatekeeper für den gesamten Bootprozess. Zwar war von vorneherein klar, dass UEFI mit Secure Boot (zunächst) abschaltbar und prinzipiell (immer) offen für alle Betriebssystemhersteller sein sollte. Wie dies in der Praxis aussehen sollte, war aber bis Herbst 2012 unklar. Eine totale Kontrolle der Hardware durch Microsoft wäre schon an kartellrechtlichen Bedenken gescheitert, so dass früh klar war, dass die Kontrolle der Schlüssel letztlich beim Eigentümer der Hardware verbleiben sollte. Das hätte in der Praxis aber auch ein striktes “entweder oder” bedeuten können: Ohne Microsofts Kooperation hätten Linux-Distributoren selbst Plattform-Schlüssel bereitstellen müssen. Der Anwender hätte seinen Rechner zur Installation in den “Setup Mode” versetzt und dann recht umständlich die Plattformschlüssel ausgetauscht. Der PC wäre mit allen Vorteilen des UEFI Secure Boot unter Linux gelaufen. Nur ein Dual Boot wäre unmöglich geworden – ein Szenario, mit dem Firmen, die Linux auf Thinclients oder Servern betreiben, durchaus leben können, das jedoch für den ambitionierten Anwender zuhause enorme Restriktionen bedeutet hätte. Der Einsatz von Live-CDs hätte hier immer vorausgesetzt, Secure Boot temporär zu deaktivieren – was keinesfalls standardisiert ist und möglicherweise irgendwann wegfällt.

Kritik erntet auch Microsofts Ansatz, Schlüssel und Hashwerte von Bootdateien auf eine schwarze Liste setzen zu können. Doch um diese schwarze Liste aktualisieren zu können, muss Windows laufen und Verbindungen ins Internet aufbauen können. Mittelfristig ist auch denkbar, dass Linux-Distributoren nach Absprache mit Microsoft Listen mit zurückgezogenen Schlüsseln und Hashes verteilen. Ich sehe hier durchaus Vorteile, beispielsweise wenn eine bestimmte Kernel- oder Bootloaderversion anfällig fürs Einschleußen von Rootkits ist. Unterm Strich bleibt aber die Freiheit, sowohl um Microsoft als auch um die großen Distributoren einen Bogen machen zu können und dennoch mit Microsofts Schlüsseln im NVRAM ein komfortables und (relativ sicheres) System nutzen zu können.

GRUB als Sicherheitsrisiko?

Derzeit existieren zwei Ansätze, einen komfortablen Linux-Start mit Secure Boot gewährleisten zu können: Bei beiden handelt es sich um kleine, vorgeschaltete Bootloader, die erst in der zweiten Stufe den eigentlichen Bootloader starten, der dann wiederum Kernel und Initramfs lädt, sowie Parameter übergibt. Aus Gründen der Konsistenz verwende ich derzeit einen selbst gebauten GRUB2 als zweite Stufe, der selbst keinerlei Prüfung durchführt, demnach theoretisch auch einen modifizierten Windows-Kernel mit darunter geschobenem Hypervisor-Rootkit starten kann. Das macht die Anwesenheit eines solchen GRUB und die Hinterlegung seines Hashes zu einem gewissen Sicherheitsrisiko.

Der Ansatz der Linux Foundation

Die Linux-Foundation bietet mit PreLoader.efi und HashTool.efi einen Bootloader und ein kleines Werkzeug zum Verwalten von Hashes. Die Kombination ist recht nutzerfreundlich umgesetzt: Der Anwender bootet Stick oder CD und startet damit den von Microsoft signierten PreLoader.efi. Findet der keinen Eintrag in der Liste erlaubter Hashes, startet er das ebenfalls signierte HashTool.efi. Mit diesem wählt der Anwender ein Binary, dessen Hash zur Liste erlaubter hinzugefügt werden soll – die beispielsweise die nach loader.efi umbenannte GRUB-Version, die beliebige Kernel booten kann. Nach einem Neustart startet PreLoader.efi den nun auf der weissen Liste stehenden Bootloader ohne weitere Nachfrage. PreLoader.efi ist recht simpel umgesetzt und wie bereits erklärt ziemlich nutzerfreundlich: Programmierer müssen Bootloader der zweiten Stufe nicht mit Zertifikaten versehen, stattdessen erklärt der Anwender beim Start, dass er einem bestimmten Binary vertraut. Ein großer Nachteil dieser Lösung ist, dass bei Änderungen am Bootloader der zweiten Stufe eine lokale Bestätigung des Hashes notwendig ist. Für Administratoren in großen Unternehmen mit weit verzweigten Standorten kann dies äußerst unpraktisch sein…

Signaturen statt Hashes: Shim mit MOKs

Shim ist ein etwas aufwendigerer Loader, der derzeit sowohl von Fedora als auch von Ubuntu genutzt wird und in seiner freien Variante auf MOKs – Machine Owner Keys – aufsetzt. Shim 0.2 wird mit einem ebenfalls von Microsoft signierten Binary MokManager.efi ausgeliefert, der es es erlaubt, eigene Signaturschlüssel für vertrauenswürdige Binaries ins NVRAM zu laden. Mit diesen signierte Bootloader führt Shim aus. Im Falle eines Bootloader-Updates muss lediglich der neue Bootloader mit dem gleichen Schlüssel wie der alte signiert werden. Der Vorteil dieses Ansatzes liegt ganz klar in der leichteren Remote-Administration und vereinfachten Updates.

Ein denkbares Szenario für die Vorteile des Shim-Einsatzes ist ein per PXE gebootetes Linux, das als Deployment- und Notfall-System dient: Um aus dem PXE-Boot kein Einfallstor für Schad- und Spionagesoftware zu machen, ist es möglich, die gesamte Boot-Kette vom Bootloader der zweiten Stufe, der nur signierte Kernel und Initrds lädt, über eine prüfende Initrd, die wiederum die Signatur des Root-Images checkt, zu booten. Ein derartiges System könnte für jeden Kunden mit einem eigenen “Machine Owner Key” signiert werden. Der Administrator muss vor dem Deployment eines PCs lediglich den MOK ins NVRAM aufnehmen. So ist auch ein sicherer Start von Thin-Client-Systemen möglich – vor Secure Boot konnte beim PXE-Boot niemand sicherstellen, dass kein korrupter Bootserver Systeme mit integriertem Keylogger ausliefert.

Einigung in Sicht

Ein Kritikpunkt an Shim war die hier implementierte Duplikation von Funktionalität: Shim implementiert ein eigenes Schlüsselmanagement und eigene Prüfungen. Dennoch bietet das Prinzip der Machine Owner Keys wie oben dargelegt viele Vorteile, insbesondere erlaubt es die Nutzung einer kompletten Secure Boot Kette, ohne dass eigene Binaries von Microsoft signiert werden müssen, stattdessen reicht es, auf jeder Machine einmal einen öffentlichen Schlüssel als vertraulich zu importieren. Matthew Garret, der Shim entwickelt, möchte den Code der Linux Foundation deshalb in Shim übernehmen um so die Vorteile beider Loader kombinieren zu können.

Bootloader mit Verfallsdatum?

Mich stört, dass UEFI keinen Mechanismus bereitstellt, einen gewhitelisteten Hashwert oder Schlüssel verfallen zu lassen. Beim Einsatz von Live-Systemen zur Rettung wäre es von großem Vorteil, maximal fünf Mal oder maximal 24 Stunden mit einem Hash booten zu können, bevor dieser automatisch verfällt. So muss der Anwender selbst darauf achten, nicht mehr benötigte Hashes selbst zu löschen, damit ein allzu liberal agierender Bootloader (der alles lädt) nicht als Einfallstor für Schadsoftware mißbraucht werden kann.

Mein Fazit

Als normaler Anwender sollte man keine Angst vor Secure Boot haben und UEFI Secure Boot nach Möglichkeit aktiviert lassen. Beim Testen eigener Kernel oder dem Remastern von Live-Medien wird vielen Anwendern aber nichts anderes übrig bleiben als zu experimentieren: Zu klein ist die Erfahrung in der Community mit UEFI Secure Boot noch und zu klein ist das Angebot an Hardware (und UEFI-Implementierungen), um alle potentiellen Bugs zu kennen. Zudem ist Abwärtskompatibilität nun ein Thema: Gerade Live-Medien wie USB-Sticks oder CDs sollen möglichst auf UEFI- und BIOS-Systemen gleichermaßen bootfähig sein. Das ist möglich, erfordert aber gelegentlich Verrenkungen und zumeist doppelte Konfigurationsdateien: Je eine für den UEFI-Bootloader und den BIOS-Bootloader.

DVD kopieren

Als allererstes kopiere ich die DVD mittels dvdbackup. Damit das mit CSS verschlüsselten DVDs funktioniert, muss eine entsprechende Version der libdvdcss installiert sein. Irgendwo unterhalb von /usr/share/doc gibt es ein Shell-Script, welches dies erledigt:

find /usr/share/doc -name '*css*.sh'

Üblicherweise kopiere ich die ganze DVD und nicht nur das Main-Feature. Das erledigt der Schalter “-M” wie “Mirror”, daneben sind Eingabegerät und Zielordner notwendig:

dvdbackup --verbose -M -i /dev/sr0 -o ./

Es entsteht ein Ordner mit dem Namen des Volumes. Das kann “DVD_VOLUME” sein oder “VIDEO_TS” oder “NAME_DES_FILMS”. Wieder mit “dvdbackup” erfahren Sie einiges über die ID des Main Features und Blickwinkel sowie Tonspuren:

dvdbackup --verbose -I -i VIDEO_TS

Die Ausgabe sieht etwa so aus:

Hauptfilm:
        Titelzusammenstellung, die den Hauptfilm enthält, ist 5
        Das Seitenverhältnis des Hauptfilms ist 16:9
        Der Hauptfilm hat 1 Blickwinkel
        Der Hauptfilm hat 4 Tonspuren
        Der Hauptfilm hat 6 Unterbildkanäle
        Der Hauptfilm hat maximal 37 Kapitel pro Titel
        Der Hauptfilm hat maximal 6 Audiokanäle pro Titel

Oft wichtig ist, ob Titelzusammenstellung 5 weitere Titel enthält:

Titelzusammenstellung 5
                Das Seitenverhältnis der Titelzusammenstellung 5 ist 16:9
                Titelzusammenstellung 5 hat 1 Blickwinkel
                Titelzusammenstellung 5 hat 4 Tonspuren
                Titelzusammenstellung 5 hat 6 Unterbildkanäle

                Der in Titelzusammenstellung 5 enthaltene Titel ist
                        Titel 1:
                                Titel 1 hat 37 Kapitel
                                Titel 1 hat 6 Audiokanäle

Beim Encodieren mit mencoder ist demnach “dvd://5″ oder “dvd://1″ später die Titelangabe, für dvdxchap ist “-t 5″ oder “-t 1″ anzugeben.

Chapter auslesen

Während die DVD im Laufwerk liegt, lesen Sie noch die Chapter aus:

dvdxchap -t 1 /dev/sr0 > chapters.txt

Anschließend kann die DVD aus dem Laufwerk genommen und beiseite gelegt werden.

Encodierung des Videos

Das Video encodiere ich im Twopass-Verfahren. Beim ersten Lauf erkennt mencoder die Stellen, die höhere Bitraten erfordern, beim zweiten Lauf wird die eigentliche Transkodierung erledigt. Das Audio schalte ich in beiden Durchläufen komplett ab, ebenso Untertitel:

mencoder -dvd-device VIDEO_TS dvd://1 -nosub -vf harddup -nosound \
    -ovc x264 -x264encopts \
    bitrate=1500:subq=5:bframes=3:b_pyramid=normal:weight_b:turbo=1:threads=auto:pass=1 \
    -o /dev/null

mencoder zeigt beim Start einige Hinweise auf Tonspuren und verfügbare Untertitel an. Diese sollten Sie per Copy and Paste für später sichern:

audio stream: 0 format: ac3 (5.1) language: en aid: 128.
audio stream: 1 format: ac3 (5.1) language: de aid: 129.
audio stream: 2 format: dts (5.1) language: de aid: 138.
audio stream: 3 format: ac3 (stereo) language: en aid: 131.
number of audio channels on disk: 4.
subtitle ( sid ): 1 language: en
subtitle ( sid ): 3 language: de
subtitle ( sid ): 5 language: de
subtitle ( sid ): 7 language: tr
subtitle ( sid ): 9 language: de
subtitle ( sid ): 11 language: de
number of subtitles on disk: 6

Und nun zum zweiten Durchlauf. Hier entsteht eine AVI-Datei, welche lediglich die H.264 kodierte Videospur enthält – das Containerformat ist zunächst noch AVI:

mencoder -dvd-device VIDEO_TS dvd://1 -nosub -vf harddup -nosound \
    -ovc x264 -x264encopts \
    bitrate=1500:subq=5:8x8dct:frameref=2:bframes=3:b_pyramid=normal:weight_b:threads=auto:pass=2 \
    -o video.avi

Audio transcodieren

Das Audio extrahiere und konvertiere ich in AVI-Dateien, die wiederum nur eine Audiospur und eine Videospur mit Dummy-Codec “frameno” enthalten. Zuerst Englisch, hier mit ID 128:

mencoder -dvd-device VIDEO_TS dvd://1 -oac mp3lame -lameopts abr:br=192 -aid 128 -ovc frameno -o audio_en.avi

Deutsch mit Audio ID 129:

mencoder -dvd-device VIDEO_TS dvd://1 -oac mp3lame -lameopts abr:br=192 -aid 129 -ovc frameno -o audio_de.avi

Untertitel extrahieren

Auch Untertitel kann mencoder extrahieren. Audio ignorieren wir und die Videoframes kopieren wir – nach /dev/null. Die SIDs entnehmen wir der Ausgabe oben. Zuerst Englisch:

mencoder -dvd-device VIDEO_TS dvd://1 -nosound -sid 1 -vobsubout subs_en -ovc copy -o /dev/null

Dann Deutsch:

mencoder -dvd-device VIDEO_TS dvd://1 -nosound -sid 3 -vobsubout subs_de -ovc copy -o /dev/null

Oft finden sich mehrere Untertitelspuren einer Sprache auf der DVD, in der Regel handelt es sich dann um Spuren mit zusätzlicher Beschreibung der Hintergrundgeräusche – “Deutsch für Hörgeschädigte” o.ä., ganz praktisch wenn man ein Video ansehen will, wenn ein Baby im Zimmer schläft.

Alles zusammenfügen

Mittels “mkvmerge” füge ich nun Videospur, beide Tonspuren und die Untertitel zusammen. In diesem Fall besagt “-A -S video.avi”, dass von dieser Datei keine Audiospur und keine Subtitel übernommen werden sollen. “-D -S audio_de.avi” bedeutet, dass diese Datei keine Videospur und keine Untertitel mitbringt, unterschlägt man “-D”, wird die Pseudo-Videospur mit Codec “frameno” übernommen:

mkvmerge --title 'Name des Films' -o Dateiname.mkv \
    --chapters chapters.txt \
    -A -S video.avi \
    -D -S audio_de.avi -D -S audio_en.avi \
    subs_de.idx subs_en.idx

Fertig! Ergänzungsbedarf gibt es möglicherweise beim Cropping (21:9-Material wird mit schwarzen Balken ausgeliefert) oder bei den Audioformaten. Zum Start sollte die beschriebene Vorgehensweise aber genügen und zu ganz guten Ergebnissen führen. Anregungen gerne in den Kommentaren.

http://communities.vmware.com/servlet/JiveServlet/download/2103172-94260/vmware9_kernel35_patch.tar.bz2

Um den Patch anzuwenden, gegebenenfalls zunächst auf Ubuntu 12.10 aktualisieren, dann die VMware-Dienste stoppen:

service vmware stop

Anschließend den Patch entpacken und das enthaltene Script anwenden:

tar xvjf vmware9_kernel35_patch.tar.bz2
cd vmware9_kernel3.5_patch
bash patch-modules_3.5.0.sh

Jetzt noch die Dienste neu starten, dann klappt es wieder mit dem VMware Player…

service vmware restart
vmplayer

Partitionierung

Ungewohnt ist die Partitionierung: GPT kennt keine primären, erweiterten und logischen Partitionen, sondern nur … Partitionen. Maximal 128 derer. Die Partitionstabelle muss daher auch nicht innerhalb der ersten 512 Bytes der Platte residieren, sondern darf etwas mehr Platz beanspruchen, eine Backup-Partitionstabelle wird am Ende der Platte untergebracht, worauf ich im Detail aber erst in einem separaten Beitrag eingehen möchte.

Die Partitionierung erfordert zwingend eine kleine Partition vom Typ ef02, wenn der Rechner ein klassisches BIOS nutzt oder eine Partitition vom Typ ef01 für einen EFI-Rechner. Dahinter werden System- und Swap-Partition angelegt. Zum Einsatz kommt gdisk, welches sich verhält wie das altbekannte fdisk:

gdisk /dev/sda

Das Ergebnis sieht so aus:

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          133119   64.0 MiB    EF02  BIOS boot partition
   2          133120        16910335   8.0 GiB     8200  Linux swap
   3        16910336       226625535   100.0 GiB   0700  Linux/Windows data

Installation des Grundsystems

Die Systempartition wird jetzt formatiert und gemountet:

mkdir -p /tmp/minibuntu
mkfs.ext4 /dev/sda3
mount /dev/sda3 /tmp/minibuntu

Auf Hetzners Rettungssystem war ein Debain-Debootstrap installiert. Ich muss es vom Ubuntu-Mirror herunterladen und mit dpkg installieren:

dpkg -i debootstrap_1.0.41ubuntu1_all.deb

Die Installation des Grundsystems geht dann recht flink mit:

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

Nachbereitung des Systems

Nun sind einige Anpassungen vorzunehmen. Zunächst editieren Sie die /etc/hostname, die /etc/default/locale, die /etc/network/interfaces, die /etc/fstab und gegebenenfalls die /etc/apt/sources.list des frisch installierten Systemes. Mounten Sie dann einige spezielle Dateisysteme:

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

Nun fehlen noch Kernel, Rootpasswort und eine Möglichkeit zur Fernwartung, wechseln Sie per Chroot in das frisch installierte System und nehkmen Sie die notwendigen Änderungen vor:

chroot /tmp/minibuntu
shadowconfig on
passwd
apt-get update
apt-get install linux-image-generic ssh

Mit dem Linux-Kernel wird als Abhängigkeit GRUB installiert. Dieser fragt nach dem Installationsort für den Bootloader, an dieser Stelle ist /dev/sda anzugeben. GRUB schreibt nun einen Kompatibilitäts-MBR, packt seine Binärdateien aber auf die BIOS-Boot-Partition. Jetzt noch einmal die /etc/network/interfaces und /etc/fstab prüfen, dann den Chroot verlassen und rebooten:

exit
reboot

Viel Spaß damit auf dem eigenen Server!

Wir haben daher zunächst mit USB-Servern fürs Netz experimentiert, derartige Geräte gibt es für netto 30 Euro (Ein-Port-Versionen mit unbekanntem chinesischen Hersteller, z.B. bei Conrad) bis 300 Euro (zwei oder vier Ports, Hutschienenmontage, Industriequalität, PoE, z.B. bei WuT). Mir gefiel aber nicht, neben dem Thinclient ein weiteres Gerät mit eigenem Netzteil (günstige Geräte können kein PoE) am Arbeitsplatz zu haben und habe daher nach Softwarelösungen für Linux gesucht. Gestoßen bin ich zunächst auf die kommerzielle Software USB Redirector, die jedoch für unser Szenario mit 75 oder 89US$ je Arbeitsplatz zu Buche schlagen würde. Gelandet bin ich schließlich beim freien Projekt USBIP, das jedoch nicht ganz trivial zur Zusammenarbeit zu bewegen ist. Geschafft habe ich es dennoch, Testsystem ist ein Ubuntu 12.04, die im nachfolgenden Text beschriebenen Schritte dürften so auch auf andere Systeme mit Kernel 3.1 oder höher anzuwenden sein. Als Client habe ich bislang nur Windows probiert über meine Erfahrungen mit Linux werde ich ggf. später berichten.

Auf der Serverseite

Mich machte bereits stutzig, dass das Projekt seit 2009 keine Aktualisierungen für Linux veröffentlicht hat. Dennoch gibt es einen recht aktuellen Client für Windows und Screenshots, die diesen bei der Arbeit zeigen. Ich ging daher davon aus, dass die Version 0.1.7 stabil und erprobt war (USB- in IP-Pakete zu kapseln ist schließlich so aufwendig nicht). Zumal usbip 0.1.7 in den Repositories von Ubuntu 12.04 enthalten ist. Ich installierte es und stieß bereits beim Start des Daemons auf Fehlermeldungen:

    root@caesium:~# usbipd --debug
    usbipd: symbol lookup error: usbipd: undefined symbol: stub_driver

Den Grund zu finden erforderte eine ausgiebige Suche: Tatsächlich wird der Quellcode des USB-IP-Projektes seit einer Weile im Git-Repository des Linux-Kernels gepflegt – und das gilt auch für die Userlandwerkzeuge. Warum Ubuntu das veraltete Paket mitbringt, welches zwar unter neueren Kernel kompiliert, aber darüber hinaus nicht nutzbar ist, ist mir nicht ganz klar. Also: usbip-0.1.7-3 wieder deinstalliert und zurück auf Los.

Ubuntu 12.04 verwendet Linux 3.2 mit eigener Minor-Versionierung. Ich entschied mich daher für 3.2.23, natürlich können Sie auch Ubuntus Quellen verwenden. Entpacken Sie den Kernel und wechseln Sie in das Verzeichnis mit den Userland-Tools und bereiten Sie dort die Kompilation vor:

tar xvjf linux-3.2.23.tar.bz2
cd linux-3.2.23/drivers/staging/usbip/userspace
bash autogen.sh
./configure --prefix=/usr --sysconfdir=/etc

Kleine Anpassungen erforderlich

Möchte man den Windows-Client 0.2.0.0 zusammen mit einem Kernel >3.0 verwenden, ist es gegebenenfalls erforderlich, die Protokollversion anzupassen: Aktuelle Linuxe sind derzeit bei 0×111, der Windows-Treiber kommuniziert nur mit 0×106. Ich habe daher die config.h abgeändert:

sed -i 's%USBIP_VERSION 0x00000111%USBIP_VERSION 0x00000106%g' config.h

Nehmen Sie diese Änderung nur vor, wenn Sie ausschließlich mit Windows-Clients der Version 0.2.0.0 auf den USB-IP-Server zugreifen wollen! Ich vermute, dass bald Windows-Clients erscheinen, welche diese Anpassung nicht erfordern.

Jetzt wird gebaut und installiert:

make && make install

Start des Daemons

Startet man den Daemon, gibt er möglicherweise eine Fehlermeldung aus:

root@caesium:~# usbipd --debug
libusbip: debug: usbip_host_driver.c:244:[open_sysfs_host_driver] sysfs_open_driver_path failed
usbipd: error: please load usbip-core.ko and usbip-host.ko!

Die erforderlichen Module aus dm Staging-Zweig müssen natürlich vorhanden sein (sind sie bei Ubuntu), im Zweifel mal nach USBIP in der Kernel-Config greppen:

root@caesium:~# modprobe -v usbip-host
insmod /lib/modules/3.2.0-24-generic/kernel/drivers/staging/usbip/usbip-core.ko 
insmod /lib/modules/3.2.0-24-generic/kernel/drivers/staging/usbip/usbip-host.ko 
root@caesium:~# usbipd --debug &
libusbip: debug: usbip_host_driver.c:189:[refresh_exported_devices] bind usbip-host.ko to a usb device to be exportable!
usbipd: info: starting usbipd (usbip-utils 1.1.1)
usbipd: info: listening on 0.0.0.0:3240
usbipd: debug: usbipd.c:394:[listen_all_addrinfo] listening on 1 address

Lassen wir uns lokale Geräte anzeigen…

root@caesium:~# usbip list -l
Local USB devices
=================
 - busid 2-4 (0951:1603)
         2-4:1.0 -> usb-storage

 - busid 4-1 (0a12:0001)
         4-1:1.0 -> btusb
         4-1:1.1 -> btusb
         4-1:1.2 -> unknown

…und exportieren dann einen USB-Stick (den sollte man vorher übrigens unmounten):

root@caesium:~# usbip bind -b 2-4 
bind device on busid 2-4: complete

Und nun der Windows-Client

Nun werden die Treiber gemäß der im Zip enthaltenen Installationsanleitung eingerichtet. Zum Verbinden mit dem Server dient das Programm usbip.exe, welches im Zip beiliegt, Caesium hat die IP 10.76.23.55, schauen wir mal nach den freigegebenen Geräten…

…und verbinden dann mit dem USB-Stick:

Kommando zurück: Verbindung trennen

Trennen erfordert etwas mehr Aufwand, zunächst muss unter Windows die Hardware sicher entfernt werden, dann folgt das Lösen der Verbindung zum Server (1 ist die virtuelle Portnummer, welche im zweiten screen beim Verbinden angezeigt wird):

    usbip.exe -d 1

Auf Serverseite ist das Gerät noch verbunden:

root@caesium:~# usbip list -l
Local USB devices
=================
 - busid 2-4 (0951:1603)
         2-4:1.0 -> usbip-host

Es folgt die Trennung:

root@caesium:~# usbip unbind -b 2-4
unbind device on busid 2-4: complete
root@caesium:~# usbip list -l
Local USB devices
=================
 - busid 2-4 (0951:1603)
         2-4:1.0 -> usb-storage

Trennt man nicht, verabschiedet sich Windows beim Shutdown möglicherweise mit einem Bluescreen. Dass USB-Fernzugriff zwischen Linux und Windows möglich ist, wäre damit bewiesen. In meinen kleinen Tests war die Verbindung stets zuverlässig. Wie sich Webcams und DVB-T-Sicks verhalten, probiere ich noch aus. Der weit aufwendigere Teil steht uns allerdings noch vor: Scripting und evtl. Erstellung eines Daemons für Windows, der neu an den Thinclient angeschlossene USB-Geräte, welche keine Drucker, Tastaturen und Mäuse sind, automatisch im Windows verfügbar macht, ohne das der Nutzer allzuviel interagieren muss.

Voraussetzungen prüfen

Um Windows auf Xen laufen lassen zu können, muss die “Hardware Virtual Machine” ran. Die sollten moderne Prozessoren beherrschen, tun sie aber nicht immer. Ein guter Ansatz ist es. den Inhalt von /proc/cpuinfo nach vm zu durchsuchen. Taucht hier vme oder svm auf, schaut es gut aus. Wenn nicht: Zuerst ins BIOS schauen und dort Hardwarevirtualisierung aktivieren – ggf. einen Blick ins Xen-Wiki werfen: wiki.xensource.com/xenwiki/HVM_Compatible_Processors.

grep vm /proc/cpuinfo

Installations-ISO besorgen

Für die Installation benötigen wir ein Verzeichnis für die VM und das Installations-ISO. Legen wir das Verzeichnis und eine leere Festplatte als Sparse File an:

WIN2008DIR=/usr/local/xendomains/win2008
mkdir -p $WIN2008DIR
dd if=/dev/zero bs=1M count=1 of=$WIN2008DIR/xvda.img seek=39999

Das ISO des Windows besorge ich mir von technet.microsoft.com/en-us/evalcenter/dd459137.aspx und kopiere es nach $WIN2008DIR/win2008.iso.

Konfigurationsdatei für die Installation

Meine Konfigurationsdatei /usr/local/xendomains/win2008/xen.cfg für die Installation sieht folgendermaßen aus:

kernel = '/usr/lib/xen-default/boot/hvmloader'
builder='hvm'
memory = 1024
xen_platform_pci=1
# Should be at least 2KB per MB of domain memory, plus a few MB per vcpu.
shadow_memory = 16
name = "win2008"
vif = [ 'type=ioemu, bridge=xenbr0, mac=00:16:17:12:23:01, model=e1000' ]
acpi = 1
apic = 1
disk = [ 'file:/usr/local/xendomains/win2008/xvda.img,xvda,w', 
         'file:/usr/local/xendomains/win2008/win2008.iso,xvdc:cdrom,r' ]
device_model = '/usr/lib/xen-default/bin/qemu-dm'
# boot on floppy (a), hard disk (c) or CD-ROM (d) 
# default: hard disk, cd-rom, floppy
boot="dc"
sdl=0
vnc=1
vncconsole=1
vncpasswd=''
serial='pty'
usbdevice='tablet'

Der erste Start

Nun geht es an den ersten Start:

xm create /usr/local/xendomains/win2008/xen.cfg

Lautet die Ausgabe Error: Domain 'win2008' does not exist. ist ein Blick in die Logdatei /var/log/xen/qemu-dm-win2008.log angeraten. Steht dort etwas wie Could not read keymap file: '/usr/share/qemu/keymaps/en-us' hilft meist ein Softlink:

ln -sf /usr/share/qemu-linaro /usr/share/qemu

Lautet die Ausgabe: Started domain win2008 (id=4) können Sie lokal mit dem VNC Viewer mit der Domain verbinden:

vncviewer localhost

In meinem Fall handelte es sich um einem kopflosen Server. Da musste ich mir den SSH-Port zunächst per Port-Weiterleitung auf den lokalen Rechner holen. 10.76.23.55 ist der Server, auf dem Xen läuft und die DomU eingerichtet werden soll:

ssh -L 5900:localhost:5900 root@10.76.23.55

In einem anderen Terminal kann ich dann auf dem PC, der die SSH-Verbindung initiiert hat die VNC Konsole öffnen: vncviewer localhost. Und bitte keine Panik, wenn während der Installation die VNC-Verbindung mal abreisst. Bei Reboots oder Änderungen der Grafikauflösung ist das normal.

Installation der PV-Treiber

Eine deutlich bessere Performance von Netzwerk und virtuellen Festplatten erhalten Sie nach Installation der GPL PV-Treiber. Sie finden diese unter www.meadowcourt.org/downloads/ Laden Sie das aktuellste gplpv*-Paket für Ihr Windows und installieren Sie dieses. Ist die Installation abgeschlossen, fahren Sie das Windows herunter und ändern Sie die Konfigurationsdatei:

vif = [ 'type=ioemu, bridge=xenbr0, mac=00:16:17:12:23:02, type=paravirtualized' ]
# default: hard disk, cd-rom, floppy
boot="c"

Feintuning zum Schluss

Ist der Windows-Server fertig eingerichtet und das Login mittels rdesktop funktioniert, kann die lokale Serverkonsole per VNC deaktiviert werden:

vnc=0
vncconsole=0

Im Falle eines Falles (Server vergisst Netzwerkeinstellungen o.ä.) muss die betreffende Domain dann natürlich abgewürgt werden und die beiden Parameter müssen wieder auf 1 gesetzt werden. Aus Sicherheitsgründen ist es aber nicht ratsam, die VNC-Konsole dauerhaft zugreifbar zu haben.

Weniger geradlinig ist noch immer der Betrieb: Der Einsatz von HVM-Gästen benötigt VME- bzw. SVM-Erweiterungen des Prozessors (in billigen PCs hart per BIOS deaktiviert) und einige Grafikkarten mit KMS bereiten Ärger, genauso wie die proprietären Grafiktreiber von AMD und nVidia. Um schnell ein Demo-Virtualisierungssystem einzurichten, taugt Xen nicht (dafür sind VMware Player oder VirtualBox viel besser geeignet). Wer dagegen extrem flexible Servervirtualisierung mit geringem Overhead und hoher Flexibilität sucht, wird mit Xen jedoch fündig.

Software-Installation

Installiert wird Xen über das Paket xen-hypervisor-4.1-amd64, alle Abhängigkeiten werden dann nachgezogen. kpartx wird für die Einrichtung der domUs benötigt:

sudo apt-get install xen-hypervisor-4.1-amd64 kpartx

Während der Installation fügt Ubuntu einen Bootmenüeintrag “Xen 4.1-amd64″ hinzu, über den Sie in einem Untermenü landen. Das ist ein guter Ansatz, solange mit den Bootoptionen herumzuspielen (vga=normal nomodeset usw.) bis der Server sauber hochfährt und sich stabil benutzen lässt.

GRUB-Konfiguration anpassen

Ich habe mich für eine etwas unorthodoxe GRUB-Konfiguration entschieden. Ein Script /etc/grub.d/98xen sucht den letzten Linux-Kernel und sein Initramfs und fügt für diesen einen Eintrag in der obersten Ebene des GRUB-Menüs ein. Anzupassen sind UUID und Parameter der Module-Zeile. Bitte nach Änderungen das Script einmal im Terminal ausführen, um zu sehen, ob die Ausgabe plausibel ist. Wer bessere Ideen hat, maile mir diese:

#!/bin/sh

LINUXKERNEL=` ls /boot/vmlinuz-3.2* | tail -n1 `
INITRAMFS=` echo $LINUXKERNEL | sed 's/vmlinuz/initrd.img/g' ` 
XENKERNEL=` ls /boot/xen-4.1* | tail -n1 `  
UUID=eb7a7f54-291f-420f-9f26-7d753c857a3d

exec tail -n +15 $0 | sed 's%XENKERNEL%'${XENKERNEL}'%g' | \
        sed 's%LINUXKERNEL%'${LINUXKERNEL}'%g' | \
        sed 's%INITRAMFS%'${INITRAMFS}'%g' | \
        sed 's%ROOTUUID%'${UUID}'%g' | \
        sed 's%^#%%g'

# Now the template - starting in line 15 - # will be removed
#menuentry "Xen+PVOPS" {
#        insmod ext2
#        set root=(hd0,1)
#        search --no-floppy --fs-uuid --set=root ROOTUUID
#        multiboot XENKERNEL dummy=dummy
#        module LINUXKERNEL root=UUID=ROOTUUID ro nomodeset vga=normal
#        module INITRAMFS dummy=dummy
#}

Damit das ganze funktioniert muss das Script ausführbar sein:

chmod 0755 /etc/grub.d/98xen

nun noch in der Datei /etc/default/grub den Standard ändern:

# GRUB_DEFAULT=0
GRUB_DEFAULT='Xen+PVOPS'

Nach einem

sudo update-grub

und dem folgenden obligatorischen Reboot sollte das Kommando xm dmesg zeigen, dass unterhalb von Linux Xen 4.1 läuft. Das war die halbe Miete.

Netzwerk für Xen einrichten

Xen benötigt eine Netzwerkbrücke. Die MAC-Adressen der unpriviligierten Domains werden dabei an ein bestimmtes Netzwerkinterface gebunden – in Heimnetzwerken und Büronetzen, in denen Sie die Kontrolle haben, ist das die Standardeinstellung. Alternativ gibt es die Möglichkeit, zu den unpriviligierten Domains zu routen (das behandle ich an dieser Stelle nicht). Passen wir also unsere /etc/network/interfaces an:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

auto xenbr0
iface xenbr0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_fd 0

Alternativ gerne mit fester IP, Adresse, Gateway und Maske werden vom primären Interface kopiert:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static

auto xenbr0
iface xenbr0 inet static
    address 10.76.23.55
    netmask 255.255.255.0
    gateway 10.76.23.252 
    dns-nameservers 8.8.8.8 10.76.23.252
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

Danach bitte nochmal Reboot oder wenigstens Neustart des Dienstes Networking.

Meine erste DomU

Meine DomUs (unpriviligierte Domains) liegen unter /usr/local/xendomains. Die zum Testen aufgesetzte unter /usr/localxendomains/12.04ltstest. Sie verwendet den Netinstaller von Ubuntu:

DOMUDIR=/usr/local/xendomains/12.04ltstest
mkdir -p $DOMUDIR
wget -O $DOMUDIR/kernel-install.img http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/vmlinuz
wget -O $DOMUDIR/initrd-install.img http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/xen/initrd.gz
dd if=/dev/zero bs=1M count=1 seek=16383 of=$DOMUDIR/xvda.img

Das Image xvda.img ist ein Sparse File. Es erscheint zwar 16GB groß, nimmt diesen Platz aber zunächst nicht ein. Jetzt noch ne Configdatei $DOMUDIR/xen.cfg:

kernel = "/usr/local/xendomains/12.04ltstest/kernel-install.img"
ramdisk = "/usr/local/xendomains/12.04ltstest/initrd-install.img"
memory = 512
vcpus = 1
name = "ltstest"
vif = [ 'mac=00:16:00:00:42:23' ]
disk = [ 'file:/usr/local/xendomains/12.04ltstest/xvda.img,xvda,w'  ]
root = ""
extra = "console=hvc0 ro xencons=tty"

Nun wird die DomU gestartet. Wichtig ist das -c, denn damit wird die Xen-Konsole aufs laufende Terminal geschaltet:

xm create -c $DOMUDIR/xen.cfg

Während der Installation sollte man noch darauf achten, das Paket openssh-server zu installieren, denn die Xen-Konsole ist äußerst unpraktisch (kennt nur 80×25 etc.). Nach der Installation rebootet das System. Dummerweise mit dem Installationskernel. Würgen wir es ab:

xm destroy ltstest

Eine dauerhafte DomU

Es gibt Möglichkeiten, den Kernel und seine Ramdisk vom Festplattenimage zu laden. Diese gefallen mir jedoch nicht, weil sie gute Einfallspunkte für Rootkits sind. Ich kopiere daher Kernel und Initrd. Zunächst erstelle ich ein Loop-Device für das Festplattenimage (die DomU darf nicht mehr laufen!), wofür wir ein freies Loopdevice brauchen (hier wurde /dev/loop0 gefunden):

losetup -f
losetup /dev/loop0 $DOMUDIR/xvda.img

Linux kommt mit Partitionen auf Loopdevices auf Anhieb nicht so toll klar. Hier kommt der Device-Mapper ins Spiel, der Partitionen auf Loop-Devices erkennt:

kpartx -a /dev/loop0
mkdir -p /tmp/xen-domU
mount /dev/mapper/loop0p1 /tmp/xen-domU

Nun kopieren wir den Kernel und das Initramfs:

cp -v /tmp/xen-domU/boot/vmlinuz-3.2.0-24-generic $DOMUDIR/kernel.img
cp -v /tmp/xen-domU/boot/initrd.img-3.2.0-24-generic $DOMUDIR/initrd.img

Zum Abschluss gilt es noch, die Konfiguration der domU anzupassen:

kernel = "/usr/local/xendomains/12.04ltstest/kernel.img"
ramdisk = "/usr/local/xendomains/12.04ltstest/initrd.img"
# ...
# Je nach Partitionierung ist die root-Zeile ggf. anzupassen!
root="/dev/xvda1"

Dann kann das Loopdevice ausgehängt und aufgelöst werden – ich lasse erst alle Devices anzeigen und löse dann von hinten nach vorn:

umount /tmp/xen-domU
ls -lah /dev/mapper/loop0*
dmsetup --remove /dev/mapper/loop0p5
dmsetup --remove /dev/mapper/loop0p2
dmsetup --remove /dev/mapper/loop0p1
losetup -d /dev/loop0

Nun steht dem Start der DomU mit “produktivem” Kernel nichts mehr im Wege. Dieses Mal ohne -c:

xm create $DOMUDIR/xen.cfg

In den nächsten Tagen werde ich mal auf eine Windows Server 2008 DomU eingehen (keine Angst, kostet nix, kann man 240 Tage am Stück gratis nutzen), was ein guter Einsatz für einen Xen-Host ist, der mit Samba Dateidienste für Windows und Linux anbietet und dank Windows Server 2008 auch Terminalserverdienste anbieten kann. Viel Spaß wünscht Mattias Schlenker!

PS: Autoren gesucht! Wer sich zutraut, einigermaßen geordnet zu schreiben, darf sich gerne bei mir melden. Ich betreue derzeit die LINUX INTERN von Data Becker als “Projektleiter” und bin für diese Zeitschrift auf die Suche nach Autoren. Eure Schreibe muss nicht “schön” im schriftstellerischen Sinne sein, aber man muss erkennen, dass Ihr strukturiert denkt. Honorar gibt es natürlich auch.

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.