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

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.

• Systemstart per Netzwerk: Es ist nun kein lokaler Datenträger mehr nötig. Stattdessen kann beim Systemstart ein ISO-Image per WGET heruntergeladen werden. Das landet im Arbeitsspeicher und wird Loopback gemountet. NFS-Boot folgt, mein Testbuild hier zu Hause macht es schon… Weiter im LessLinux-Blog

• Zugriff per VNC: Per Cheatcode kann nun angegeben werden, statt einer lokalen Grafikkarte einen VNC-Server anzusteuern. Das klappt offen fürs ganze Netz oder auf localhost für unsichere Umgebungen Weiter im LessLinux-Blog

• LessLinux selbst bauen: Buildscripte, Anleitungen und ein VMware-Image in dem der Build garantiert durchläuft, sind Online Teil 1 und Teil 2 im LessLinux-Blog

• Wie stark suckt Flash? Es gibt eine Beta der 10.1 für Linux, Hardwarebeschleunigung inbegriffen, News bei LinuxForDevices.com.

  Ich konnte mich nie wirklich mit Flash unter Linux, BSD oder MacOS X anfreunden und werde es wahrscheinlich nie wirklich können. Auf meinem 64 Bit Desktop läuft Flash im Plugin-Wrapper und schmiert zweimal am Tag ab. Ich bin damit die meiste Zeit ohne Flash unterwegs und vermisse es nicht wirklich. Nur wenn ich gerade Flash für ein kleines Video brauche, ist es nicht da. Ich hoffe, dass HTML5-Video bald soweit verbreitet ist, dass man auch für die Freizeit kein Flash-Plugin mehr braucht.

• Endlich kostenlose Navigation auf dem Nokia E71 Nokia reagiert auf protestierende Nutzer: News bei engadget.com.

  Dass Nokia seine kostenlose Navigation beim Start nur für eine Hand voll Geräte anbot, fand ich ärgerlich. Sollte ich ein ein Jahr altes E71 wegwerfen und ein mir ein E72 kaufen, um in den Genuß der Navigationslösung zu kommen? Der Protest der letzten Monate hat gewirkt: Nokia bietet die kostenlose Ovi Maps Version 3.0.3 nun auch für E66 und E71.

• Mein YaCY-Host läuft wieder! Ich mache wieder bei der freien Suchmaschine mit und helfe, mich und andere von Google abzunabeln.

  Auf dem Büroserver läuft nun eine Xen-Instanz mit 1,25GB RAM und 30GB Platte. 25GB Plattenplatz und 1GB RAM darf sich Yacy nehmen, dafür habe ich die CPU-Zyklen etwas beschränkt und stelle nur einen Prozessorkern bereit. Cool: Wenn man die Proxy-Indexierungstiefe auf 1 setzt und hin und wieder doch zu Google greifen muss, indexiert Yacy die auf den gelesenen Google-Ergebnisseiten verlinkten Seiten.

  Nachtrag: Hier gibt es einen älteren Artikel von mir zu Einrichtung und Funktionsweise von YaCY.

• Xen 4.0 erschienen: Neue Version des Hypervisors, News bei Golem.

  Wenn ich die Nachricht richtig deute, läuft Kernel 2.6.31 dann mit pv_ops auf Xen (der Kernel erkennt, ob er auf Xen oder direkt auf der Hardware läuft), wenn ein Prozessor mit Intels oder AMDs Virtualisierungserweiterungen gefunden wird. Damit ist der Einsatz neuer Xen-Versionen auf vielen Maschinen die älter als zwei Jahre sind, in weite Ferne gerückt. Immerhin: Da pv_ops ein fester Bestandteil des Kernels ist/wird, hat das manuelle Patchen des dom0-Kernels bald ein Ende. Ich hoffe, dass Xen damit eine Zukunft im SMB-Bereich und nicht nur im Rechenzentrum hat, denn KVM hat mit PCI Passthrough u.ä. in letzter Zeit mächtig aufgeholt.

• Einsteiger-Smartphones von Nokia C3, C6 und E5, News bei Golem, News bei Engadget und News bei Infosync.

  Immer noch kein Symbian^3, stattdessen das neu gelabelte Symbian^1 (TOFKAS605TH = The OS Formerly Known As Series 60 5th Edition), nett und meine Erfahrungen mit E71 und 5230 zeigen, dass Nokia durchaus brauchbare Geräte mit langen Standby-Zeiten und schneller Navigation bauen kann, auch die Preise sind moderat und die Tastatur des E5 hoffentlich so gut wie beim E71, aaaaaber von einem Gerät wie dem C6 hätte ich langsam das neue Touchscreen-Symbian erwartet.

./ati-driver-installer-10-3-x86.x86_64.run

probierte ich erneut

aticonfig --initial

Das Ergebnis war ernüchternd: Wieder wurde mir gesagt, dass keine unterstützten Karten im Rechner vorhanden waren, eine Konfiguration daher nicht möglich sei. Zur Erinnerung: lspci erkennt die Karte wie folgt:

01:00.0 VGA compatible controller [0300]: ATI Technologies Inc Device [1002:68e0]

Doch heute packte mich ein wenig der Spieltrieb und ich probierte zunächst anhand einer minimalen xorg.conf, ob denn die Karte erkannt wird, wenn ich dem Treiber explizit mitteile, dass er für sie zuständig ist — das besorgt die Zeile ChipID. Über SSH loggte ich mich also am Notebook ein und baute die Konfigurationsdatei auf. Bereits mit einer Section “Screen” und einer Section “Device” erhielt ich ein Bild in der nativen Auflösung des Widescreen-Displays. Die minimale xorg.conf:

Section "Screen"
        Identifier      "Screen_AUTO_1366x768"
        Defaultdepth    24
        SubSection "Display"
             Modes "1366x768" "1024x768" "1024x600" "800x600"
        EndSubSection
EndSection

Section "Device"
        Identifier  "Card0"
        Driver      "fglrx"
        ChipId      0x68e0
        VendorName "ATI"
        BusId      "PCI:1:0:0"
EndSection

Die vollständige xorg.conf kann hier heruntergeladen werden. Die größte Änderung dürfte sein, dass ich Option "SWCursor" "true" aktiert habe, um nach einem Logout das Fehlen des Zeigers zu vermeiden. Wer diese xorg.conf als Basis für eigene Experimente verwendet, sollte wie ich sich per SSH einloggen, den gdm stoppen und dann remote versuchen, ob sich der Xserver starten lässt: Logdatei und Meldungen in der Konsole, in dem der Start durchgeführt werden, sind aussagekräftig – Oft muss ChipId oder BusId angepasst werden.

Fehlendes Kernelmodul

Leider lässt sich auf meinem 2.6.33.1 das fglrx-Kernelmodul nicht kompilieren. Nach dem Wechsel nach /lib/modules/fglrx/build_mod und Aufruf von ./make.sh mäkelt das Script zunächst über zwei fehlender Header. Nach dem softlinken dieser Header geht es aufgrund geänderter Funktionen auch nicht weiter. Ich werde dieses Problem irgendwann angehen, gebe mich zunächst mit weniger (gar keiner?) Beschleunigung zufrieden.

Nerviges Overlay “Unsupported Hardware”

Im rechten unteren Eck befindet sich ein Overlay “Unsupported Hardware”. Dieses lässt sich nur abschalten, indem man mit dem Hex-Editor an das Treiber-Binary herangeht. Der User “Crypto2600″ aus den Ubuntu-Foren hat hierfür ein kleines Script geschrieben, das den Vorgang automatisiert:

#!/bin/sh
DRIVER=/usr/lib/xorg/modules/drivers/fglrx_drv.so
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6
}'); do
echo found $x
sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER
done 

Das Ende vom Lied?

Fürs erste läuft die Grafik zufriedenstellend. Das fehlende Kernelmodul rüste ich bei Gelegenheit nach — ich mutmaße einmal, dass die Buildscripte für Lucid bald gepatcht sind, so dass diese Änderung nicht mehr viel Arbeit bedarf. Und vielleicht supported Ati die 5470 ja irgendwann einmall ganz offiziell…

Nachtrag, 6. April 2010: “fglrx” hatte die Lösung. Umgesetzt habe ich sie, indem ich nach dem Download des Patches von http://aur.archlinux.org/packages/catalyst/catalyst/fglrx-2.6.33.patch und Anwenden desselben die Module unterhalb von /lib/modules gebaut habe. Quick and dirty gelang diese mit:

cd /lib/modules/fglrx
patch -p5 < /tmp/fglrx-2.6.33.patch
cd build_mod
./make.sh
cd ..
./make_install.sh

Anschließend lies sich das Modul wie erwartet laden und Hardwarebeschleunigung ist nun aktiv aktiv.

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