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

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

Benötigte Pakete

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

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

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

apt-get install libc6-xen

Kernel kompilieren

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

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

Meine Konfigurationsdateien:

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

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

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

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

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

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

Xen Hypervisor installieren

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

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

Bootloader konfigurieren

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

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

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

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

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

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

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

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

Installation der Xen-Tools

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

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

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

/etc/init.d/xend start
xm dmesg

Xend in den Runleveln verlinken

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

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

Vorbereitung für Routing-Setup

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

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

Zuerst wird die Datei /etc/modules um eine Zeile

dummy

für den Dummy-Netzwerk-Adapter erweitert.

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

auto lo
iface lo inet loopback

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

auto dummy0
iface dummy0 inet static
        address 172.16.16.113
        netmask 255.255.255.248

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

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

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

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

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

Vielen Dank an...

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

Anmerkungen:

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

• Details zur domU-Konfiguration bei Hetzner folgen

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

Wie dem auch sei: Die hochgeladenen Artikel findet Ihr unter cdprojekte.mattiasschlenker.de/Public/Artikel/, ich erspare es mir, jeden Artikel einzeln zu verlinken. Naturgemäß sind zwei bis vier Jahre alte Artikel nicht gerade die aktuellsten. Alles mit Workshop-Charakter ist daher sehr vorsichtig zu behandeln. Immerhin sind einige “zeitlose” Artikel dabei, wie die 64Bit-Einführung (PDF) (wer Flash-Probleme hat, wird einen 32Bit-Chroot zu schätzen wissen) oder die Einführung in Cygwin incl. X11 (PDF) sowie die beiden Artikel zum Thema PXE- und TFTP-Boot (PDF) oder zur freien Suchmaschine Yacy (PDF). Einige andere Artikel bspw. zum ersten EeePC spiegeln eher den Zeitgeist wider und lesen sich schon nach gut zwei Jahren wie Erinnerungen aus einer längst vergangenen Zeit…

Daneben hat Magnus.de selbst einige meiner Artikel online gestellt, ganz aktuell beispielsweise zu Grub 2 als Universalbootloader auf Linux- und Windows-Systemen (HTML) (trägt als Zeitstempel der Einstellung den 30. März 2010 ) oder dessen Vorgänger auf Basis von Grub 0.97 (HTML).

Erster Bootversuch

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

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

Installation von Ubuntu 9.10

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

Kernelkompilierung und Segfaults

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

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

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

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

Teilerfolg und fehlende Grafiktreiber

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

aticonfig: No supported adapters detected

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

Dateien

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

Das Nokia 5230

Wir brauchten “schnell mal” ein weiteres Mobiltelefon, das als Bluetooth-HSDPA-Modem taugt und auch dazu genutzt werden kann, unterwegs kurz nach den Mails zu schauen oder im Internet zu surfen. Fußgängernavigation ist nett, war aber kein “must-have”. Bei Kampfpreisen von etwa 115 Euro netto und Verfügbarkeit im lokalen Fachhandel war die Entscheidung für das 5230 schnell gefallen.

Beim ersten Blick handelt es sich beim 5230 um ein 5800 mit andersfarbigem Gehäuse. Beide sind mit etwa 15 Millimetern Dicke nicht gerade die kompaktesten. Der Touchscreen ist mit 3,2 Zoll und 640×360 Pixeln schön scharf, einige Hardwaretasten (Annehmen, Abweisen, Menü, Sperren, Lautstärke und Kameraauslöser) machen die “blinde” Nutzung einfacher. Die technischen Unterschiede zum 5800 sind das fehlende WLAN, eine einfachere Kamera ohne Blitz und der Lieferumfang: Keine Speicherkarte etc. Der resistive Touchscreen ist erfreulich gut mit den Fingern zu bedienen, was Nokia wohl dazu animiert hat, den Wecker mit Slidern á la iPhone auszustatten. Dennoch empfiehlt sich eher die Nutzung eines Stiftes mit Kunststoffspize (Tipp: Kugelschreiber “unausgeklickt” oder Zweiminenkugelschreiber, bei dem eine Mine durch eine weiche Kunststoffspitze ersetzt ist).

Die Software

Bei Series60 5th Edition handelt sich es um eine simple Umsetzung von Series60 3.2 auf Touchscreens. Die D-Pad-Navigation in den Menüs wurde 1:1 auf den Touchscreen übertragen. Das Resultat: In Menüs muss man doppelklicken: einmal um einen Eintrag zu selektieren, ein weiteres Mal um die hinterlegte Aktion schließlich zu starten. Icon-Grids profitieren nicht wirklich vom hochausflösenden Touchscreen: Wie bei 3.2 werden 12 Icons abgebildet — immerhin hübscher und höher aufgelöst –, will man mehr, muss man scrollen. Auch bei den übrigen Anwendungen belegen rechts eingeblendete Buttons, die Hardwaretasten ersetzen wertvolle Bildschirmfläche.

Das Resultat ist eine Oberfläche, die kaum Vorteile gegenüber der touchscreenlosen 3.2 bietet. Wer von einem Nokia-Handy mit Tastatur kommt, wird sich sofort zurecht finden. Eine ordentliche Anpassung an den Touchscreen bieten immerhin Webbrowser, Videoplayer und das hervorragende (neue) Ovi-Maps mit kostenloser Navigation (muss separat installiert werden).

Würde ich es wieder tun?

Das 5230 ist mit Sicherheit sein Geld wert, alleine die hervorragende Fußgängernavigation und die Nutzung als UMTS-Modem haben sich für uns ausgezahlt. Dass ein brauchbarer Mailclient und Browser (auf Basis von WebKit) an Bord sind, ist auf jeden Fall positiv. Dennoch würde ich kein “High-End-Telefon” für den dreifachen Preis auf Basis von Series60 5th Edition haben wollen. Zu klein sind die Fortschritte gegenüber 3.2, da werden auch aufgesetzte Widgets eines N97 nichts daran ändern. Ich werde also erstmal beim E71 bleiben und mal sehen, was der MWC so Android-mäßiges bringt oder ob ein kompakterer Bruder des N900 ansteht.

Doch zunächst zu den technischen Finessen: Das Gtk-Problem besteht nun nicht mehr, Ihr könnt die im letzten Artikel gesetzte Umgebungsvariable also wieder entfernen. Vermutlich wurde auch das Kompilationsproblem gefixt, allerdings wage ich hier keine konkrete Aussage, denn eine Neuinstallation verhält sich hinsichtlich Update der Module immer ein wenig anders als eine komplette Neuinstallation auf einem sauberen System.

Auf einigen Host-Systemen soll der Player nun Aero- und Glass-Gäste beherrschen, auf die Schnelle habe ich davon auf dem Linux-Host mit nVidia-Closed-Source-Treiber nix gemerkt. Unity, also die Möglichkeit, die VMware-Fenster auf den Linux-Desktop zu holen, ist etwas schneller geworden, aber immer noch zu laggy (auf einer Vierkernmaschine mit 8GB RAM…), so dass ich nach wie vor Vollbild bevorzuge.

Herunterzuladen ist der Player wie immer hier.