SUSE Linux 10 und Apple iPod

Wenn man seinen iPod unter SUSE 10 zum Laufen bekommen möchte, erwartet man wahrscheinlich, dass das ohne weiteres Zutun einfach funktioniert; schließlich handelt es sich einerseits bei SUSE um eine ausgereifte Linux-Distribution, andererseits ist der iPod nun schon längere Zeit auf dem Markt und gilt als von Linux generell unterstützt. Leider ist das nicht der Fall: Der primäre Media-Player unter SUSE Linux weist nur begrenzte und fehlerträchtige Unterstützung für den iPod auf, die Datenübertragung ist extrem langsam und auch die "Bitte nicht trennen!" Meldung auf dem Display des iPod will einfach nicht verschwinden. Im folgenden werden wir Wege suchen und finden, um diese kleinen Ärgernisse zu umgehen.

Der iPod, mit dem ich das getestet habe, ist ein iPod video der fünften Generation mit einer 30GB Festplatte. Das folgende gilt größtenteils auch für ähnliche Modelle, wie den 60 GB iPod der fünften Generation und den iPod nano.

Eine Welt ohne iTunes: Der Mediaplayer

Zuallererst müssen wir uns für ein Programm entscheiden, um den iPod mit Musik zu befüllen. Da fällt einem zunächst natürlich Amarok ein, aber wie es sich herausstellt, ist die iPod-Unterstützung in den aktuellen Versionen des 1.3er-Zweiges mehr als nur ein bisschen wackelig:

http://amarok.kde.org/component/option,com_simpleboard/Itemid,/func,view/catid,8/id,9127

Offenbar ist Amarok keine geeignete Lösung zum Befüllen des iPod. Den beschriebenen Bug konnte ich nachvollziehen: Er tritt nicht nur beim iPod nano auf, sondern betrifft wahrscheinlich alle iPods der fünften Generation. Nebenbei: Die Amarok-Version, die mit SUSE 10 ausgeliefert wird, hat deutliche Probleme mit der Threadsicherheit auf SMT/SMP-Rechnern und ist von daher ohnehin unbenutzbar -- jedenfalls, wenn man Hyperthreading, eine aktuelle Dualcore-CPU oder mehrere CPUs hat; die Amarok-Version 1.3.7 aus dem KDE 3.5-Update umgeht diese Schwierigkeiten einfach dadurch, dass sie sich beim Start an eine einzelne logische CPU bindet.

Es gibt jedoch noch eine andere Möglichkeit: Das hervorragende Packman-RPM-Repository stellt hier eine aktuelle Version von gtkpod für SUSE 10 zur Verfügung:

http://packman.links2linux.de/?action=320

Im Gegensatz zu dem, was auf der Seite steht, müssen wir jedoch auch noch libgpod als Abhängigkeit installieren; das können wir hier herunterladen:

http://packman.links2linux.de/?action=756

HFS+ oder FAT32: Ein Dateisystem für den iPod

Apples iPods sind mit HFS+ als Standard-Dateisystem formatiert. Wenn man einen iPod in einen Rechner mit Microsoft Windows stöpselt, formatiert die iPod-Software die Festplatte des Geräts mit einem FAT32-Dateisystem, da Windows mit HFS+ absolut nichts anfangen kann. Unter SUSE 10 bleibt die Wahl des Dateisystems gänzlich dem Anwender selbst überlassen: Der Kernel kann sowohl mit HFS+ als auch mit FAT32 umgehen. FAT32 hat den Vorteil, dass die Unterstützung dafür im allgemeinen als stabiler angesehen wird als die für HFS+ unter Linux und dass man seinen iPod zusätzlich als mobile Festplatte zur Datenübertragung mit fast jedem PC überall auf der Welt verwenden kann. Wenn man sich für HFS+ entscheidet, kann nur ein Macintosh oder ein anderer Rechner mit Linux (und einem aktuellen Kernel aus der 2.6er Reihe) den iPod als externe Festplatte einbinden. Von daher empfiehlt es sich, den iPod auf FAT32 zu konvertieren, bevor man ihn verwendet -- zumindest, wenn man sich nicht ganz sicher ist, dass man ihn unter keinen Umständen jemals in eine Windows-Kiste stöpseln will (oder einen anderen Rechner ohne HFS+-Unterstützung) oder überhaupt nicht beabsichtigt, den iPod als schicke USB-Festplatte zu verwenden.

Wie bereits erwähnt findet die Konvertierung auf FAT32 relativ transparent statt wenn man den iPod an einen Windows-Rechner anschließt und er mit HFS+-Dateisystem daherkommt. Wenn man keinen Zugang zu einer Windows-Maschine hat und die Konvertierung nach FAT32 trotzdem durchführen will, finden sich online eine Reihe von Tutorials, wie man das mit reinen Bordmitteln von Linux erreicht. Nicht schwer zu machen, aber einfach einmal in eine Windows-Kiste einstöpseln ist natürlich noch einfacher.

Datenübertragung beschleunigen

Für welches Dateisystem auch immer wir uns auf dem iPod entschieden haben: SUSE 10 erkennt ihn, wenn wir ihn einstecken, und gtkpod kann mit ihm reden. Allerdings werden wir feststellen, dass SUSE/Novell den Nutzwert externer Festplatten (und genau das ist der iPod aus Sicht von SUSE 10) in Punkto Geschwindigkeit ernsthaft beschnitten haben, wenn wir versuchen, eine größere Anzahl Songs auf den iPod zu übertragen. Um ihr OS narrensicherer zu machen, haben sich SUSE/Novell dazu entschieden, alle beschreibbaren Wechselmedien mit der "sync" Mountoption ins System einzubinden. Unterm Strich wird dadurch jedes write-caching zwischen Rechner und externem Gerät außer Kraft gesetzt, so dass es zu keinem Datenverlust kommen kann, wenn man das Gerät ohne unmount oder manuellen Auswurf ("Sicher entfernen") vom Rechner trennt.

Das mag schon so sein, aber dieser Ansatz birgt zwei Probleme in sich: Zum einen leidet die Performance darunter erheblich. So erheblich sogar, dass das Befüllen meines 30GB-iPod Ewigkeiten gedauert hätte. Zum anderen ist dieser Ansatz nur ein notdürftiger Flicken für das zugrunde liegende Problem: Beschreibbare Geräte müssen mit unmount entfernt werden, Punkt: Kein Weg führt daran vorbei. Mac OS X weiß das, der iPod selber weiß das, sogar Windows ist sich dessen bewusst. Warum also nicht SUSE? Schlimmer noch: Der iPod erwartet ja, dass er per unmount entfernt wird und zeigt seine "Bitte nicht trennen!"-Warnung an, bis er vom Rechner das Signal erhält, dass er tatsächlich nicht mehr gemountet ist. Wenn man auch nur ein bisschen besorgt um die Integrität seiner Daten ist, fühlt man sich sicherlich nicht besonders wohl dabei, ein Gerät einfach vom Rechner zu trennen, dass einem in grellem Rot entgegenschreit, genau dies nicht zu tun.
SUSE/Novell war dieses Problem anscheinend sogar schon vor der Veröffentlichung von SUSE 10 bekannt:

https://bugzilla.novell.com/show_bug.cgi?id=105871

Ein Kommentar in diesem Bugzilla erwähnt einen Workaround: Dem HAL (Hardware Abstraction Layer) zu sagen, dass er Wechselmedien nicht mit der "sync"-Mountoption einbinden soll. Das betrifft dann natürlich alle Wechselmedien, die wir jemals in unseren Rechner einstöpseln, also werden wir die alle in Zukunft von Hand unmounten müssen (einschließlich USB-Memory-Sticks, externen Festplatten und Digitalkameras).

Der Workaround wird in Kraft gesetzt, indem man (als root) eine Datei in /usr/share/hal/fdi/policy/95userpolicy anlegt (wobei das Verzeichnis möglicherweise zunächst erstellt werden muss), die einen beliebigen Namen tragen kann ("usb_nosync.fdi" zum Beispiel), und folgenden Inhalt hat:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">

  <device>

    <match key="block.is_volume" bool="true">

      <match key="volume.fsusage" string="filesystem">

        <merge key="volume.policy.mount_option.sync" type="bool">false</merge>

      </match>

    </match>

  </device>

</deviceinfo>

"Sicher entfernen" zum Laufen bringen

Jetzt wird der iPod ohne "sync" eingebunden und die Geschwindigkeit wird erträglich. Allerdings müssen wir nun darauf achten, den iPod jedesmal richtig zu unmounten, wenn wir mit ihm fertig sind (und nochmal: das gilt auch für alle anderen externen beschreibbaren Medien, die wir über USB, IEEE1394 oder einen anderen Anschluss mit dem Rechner verbinden). Dies erweist sich als wesentlich komplizierter als gedacht, denn SUSE 10 will uns regelrecht davon abhalten, genau dies zu tun. Wenn man sich den Inhalt von "system:/media" im Konqueror anschaut, stellt man fest, dass der iPod dort erscheint, sobald man ihn einsteckt (oder sogar auf dem Desktop selbst, sofern KDE so konfiguriert ist, Wechselmedien dort anzuzeigen), aber wenn man dann "Sicher entfernen" aus seinem Kontextmenu auswählt, wird das nicht funktionieren: SUSE sagt dann, dass es /media/ipod nicht in /etc/fstab finden kann und man keine root-Rechte hat, so dass das dort gemountete Dateisystem nicht ausgehängt werden kann.

Sowohl SUSE/Novell als auch das KDE-Entwicklerteam wurden anscheinend von dieser Problematik in Kenntnis gesetzt, und die jeweilige Reaktion ist amüsant: Die KDE-Entwickler behaupten, es gehe um ein SUSE-spezifisches Problem, während SUSE/Novell darauf hinweisen, dass es sich um einen Bug in KDE handele:

http://bugs.kde.org/show_bug.cgi?id=116209

https://bugzilla.novell.com/show_bug.cgi?id=117945

Ich würde mich in dieser Angelegenheit eher der Sichtweise des KDE-Teams anschließen (schließlich sind SUSE/Novell für ihre gesamte Distribution verantwortlich, so wie sie sie ausliefern; das schließt auch eventuelle Fehler mit ein, die KDE haben könnte), auch wenn wir gleich sehen werden, dass auch die KDE-Entwickler zur Existenz dieses Bugs ein wenig beigetragen haben. Wer auch immer die Verantwortung nun tragen mag oder nicht -- wie finden wir eine Lösung?
Wenn wir auf eine Shell gehen und den iPod händisch zu entfernen versuchen, kommen wir zum selben Ergebnis. Und das System hat ja auch vollkommen recht: /etc/fstab enthält keinen Eintrag für /media/ipod, da dieser Mountpunkt vom HAL-Daemon verwaltet wird.

Es existieren mehrere denkbare Lösungsansätze, aber keiner davon lässt sich leicht umsetzen während subfs zum automatischen Mounten und HAL in der Konfiguration von SUSE 10 verwendet wird. Interessanterweise können wir den iPod allerdings mit einem anderen Befehl aushängen: Einfach von der Shell aus "eject /media/ipod" aufrufen funktioniert! Das liegt daran, dass /bin/eject unter SUSE 10 als setuid root eingerichtet ist.

An diesem Punkt könnten wir aufhören und einfach jedes Mal von der Kommandozeile aus "eject /media/ipod" aufrufen, wenn wir mit der Datenübertragung zum iPod fertig sind. Wenn man diese Lösung akzeptabel findet, spricht da sicherlich auch nichts dagegen. Es bleibt jedoch eine Frage offen: Warum funktioniert die Auswahl von "Sicher entfernen" aus dem Kontextmenu des iPod-Symbols dann nicht? Man würde doch vermuten, dass das auch "/bin/eject" aufruft.

Ein Blick ins SVN-Repository von KDE auf den Quellcode von kio_media_mounthelper, dem Programm, das sich im Hintergrund um mounts und unmounts im Auftrag von KDE kümmert, zeigt, dass genau das auch geschieht, wenn auch über den Umweg eines Wrapper-Scripts namens kdeeject (das jedoch keinen schädlichen Einfluss hat). Jedoch soll das entsprechende Gerät zunächst ausgehängt werden und das Programm gibt auf, wenn dies nicht gelingt. Das ist etwas unglücklich: "/bin/eject" wird ohnehin versuchen, das Gerät auszuhängen, so dass es wirklich keinen Grund für KDE geben sollte, dies zu versuchen. Um dieses Problem nun zu umgehen hilft nichts außer dem Patchen des Quellcodes von kio_media_mounthelper.
Der folgende Patch, angewandt auf die Originalquellen von KDE 3.5 in /kdebase/kioslave/media/mounthelper/kio_media_mounthelper.cpp, sorgt dafür, dass nur noch kdeeject aufgerufen wird ohne zu versuchen, zuvor das Gerät auszuhängen:

87,98c87

<               if (medium.isMounted())

<               {

<                      
KIO::Job * job = KIO::unmount( mount_point );

<

<                      
m_device = device;

<                      
connect( job, SIGNAL( result( KIO::Job * ) ),

<                               
this, SLOT( slotResultSafe( KIO::Job * ) ) );

<               }

<               else

<               {

<                      
invokeEject(device, true);

<               }

---

>               invokeEject(device, true);

Sie können den svn diff hier herunterladen.

Der Patch ist simpel und sollte keine ungeahnten Nebenwirkungen mit sich bringen, so weit ich es beurteilen kann, denn der Aufruf von /bin/eject sollte das entsprechende Gerät immer auch aushängen. Nichtsdestotrotz birgt das Patchen von Systemprogrammen immer ein Risiko in sich und man sollte sich im Klaren darüber sein, was man tut, wenn man die gepatchte Version von kio_media_mounthelper auf seinem Rechner einsetzt. Natürlich kann ich keinerlei Verantwortung für eventuelle Schäden übernehmen, die dadurch entstehen könnten.

Nach der Anwendung des Patches muss das kio_media_mounthelper-Programm neu gebaut und nach /opt/kde3/bin/kio_media_mounthelper kopiert werden. Beachten Sie, dass Sie das Original nicht überschreiben, sondern zunächst umbenennen sollten. Nach dem Kopieren des gepatchten Programms sollte das Entfernen des iPod in Konquerors "system:/media"-Ansicht wie erwartet funktionieren.

Zu guter Letzt haben wir also ein funktionierendes Setup: Wir können den iPod einstecken, SUSE wird ihn erkennen, wir können Daten mit akzeptabler Geschwindigkeit mit Hilfe von gtkpod übertragen und wir können ihn auf komfortable Weise mit nur einem Mausklick wieder entfernen, wenn wir fertig sind. Genau so, könnte man hinzufügen, hätte das auch von Beginn an sein sollen.

Spielzeug