Toys

SUSE Linux 10 and an Apple iPod

If you want to get your iPod running with SUSE 10, you probably expect everything to work just out of the box without further tweaking; after all, SUSE is a mature distribution and the iPod has both been on the market and supported on Linux systems for a while now. Unfortunately, this is not at all the case: SUSE Linux's media player has only limited and buggy support for the iPod, data transfer rates are extremely slow and the "Do not disconnect!" warning on the iPod's display just doesn't want to go away. In the following, we will find ways to overcome these annoyances.

The iPod I tested all this with is a fifth generation iPod video with a 30 GB harddisk. The following mostly applies to similar models, like the fifth generation 60 GB and the iPod nano.

A world without iTunes: Choosing a media player

Before everything else, we need to decide on an application to fill the iPod with. Amarok comes to mind first, but it turns out its iPod support in the current 1.3 branch is more than a little shaky:

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

Obviously, using Amarok to fill the iPod is not a solution. I have encountered this bug myself: It is not limited to the iPod nano, but probably affects all iPods from the fifth generation. On a sidenote, the Amarok version shipped with SUSE 10 has serious thread-safety problems on SMT/SMP boxes and is therefore unusable anyway -- that is, if you have Hyperthreading, a dual core CPU or multiple CPUs; the Amarok 1.3.7 from the KDE 3.5 update works around that by binding itself to a single logical CPU on startup.

There is another choice, however. The excellent packman rpm repository provides a package of a recent gtkpod version for SUSE 10 here:

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

Contrary to what this page says, we also need libgpod to install gtkpod; we can get it from here:

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

HFS+ or FAT32: Choosing a file system for the iPod

Apple's iPods are formatted with HFS+ as their default filesystem. If you plug an iPod into a Microsoft Windows box, the iPod software reformats the device's hard disk with a FAT32 filesystem, because Windows cannot deal with HFS+ at all. On SUSE 10, the choice which filesystem to use is first and foremost our own: The shipped kernel can deal with both HFS+ and FAT32. FAT32 has the advantage that its support is generally considered more mature than HFS+ on Linux and that you can also use your iPod as a mobile hard disk on nearly any computer everywhere for transferring data. If you opt to stay with HFS+, only a Macintosh or another Linux box (with a recent 2.6 kernel) will be able to mount the iPod as an external hard disk. So converting the iPod to FAT32 before using it is recommended, unless you are certain you either don't want to plug your iPod into a Windows box ever (or any machine without HFS+ support), or have no intention to use the iPod as a stylish portable USB hard disk at all.

As I have already mentioned above, the conversion to FAT32 happens more or less transparently when you plug your iPod into a Windows OS machine and it has a HFS+ file system. If you do not have access to a Windows machine and want to convert to FAT32 anyway, there are a number of tutorials to be found online how to achieve this with Linux tools only. It's easy to do, but plugging once into a Windows machine sure is easier.

Speeding up transfer rates

Now, whatever file system we have on the iPod, SUSE 10 will recognise it if we plug it in and gtkpod will be able to talk to it. However, once we begin actually transferring a large number of songs to the iPod, we will see that SUSE/Novell decided to severely cripple the usefulness of pluggable hard disks (and that's exactly what the iPod is as far as SUSE 10 is concerned) when it comes to performance: To make their OS more idiot-proof, SUSE/Novell opted to mount all removable and writable media with the sync mount option. Effectively, this disables all write-caching between our machine and the device, so that whenever we unplug the device without unmounting or manually ejecting ("Safely remove") it first, no data loss or corruption should occur.

That may be the case, but there are two problems with this approach: First, performance degrades badly. So badly, in fact, that filling my iPod's 30 GB of data would have taken ages. Second, this approach is only a band aid for the underlying problem: Writable devices need to be unmounted, period: There's just no way around this. Mac OS X knows that, the iPod itself knows that, even Windows does. Why shouldn't SUSE? Even worse: The iPod actually expects to be unmounted and displays its "Do not disconnect!" warning until it receives notification from the host machine that it has been. If you're just a little paranoid about data integrity, you certainly won't feel too comfortable unplugging a device while it is screaming at you in glaring red not to do that.

SUSE/Novell have apparently been aware of this problem even before the release of SUSE 10:

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

One comment in this bugzilla mentions a workaround: Tell the HAL daemon (Hardware Abstraction Layer) to mount removable devices without the sync option. Of course, this applies to all removable media we ever plug into the machine, so all of these will need unmounting from then on (including flash drives, external hard disk enclosures and digital cameras).

The workaround is implemented by creating (as root) a file in /usr/share/hal/fdi/policy/95userpolicy (this directory might need to be created first), called whatever we like ("usb_nosync.fdi", for example), with the following content:

<?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>

Getting "Safely Remove" to work

Now the iPod will be mounted without sync and speed will be tolerable. However, we now have to be careful to always properly unmount the iPod when we're done with it (and, again, any other removable device plugged in via USB, IEEE1394 or any other bus). This turns out to be a lot more complicated than expected, because SUSE 10 actually wants to prevent us from doing that. If you have a look at the "system:/media" URL in konqueror, you will find that the iPod is visible there once plugged in (it may even be on your desktop, if you have KDE configured that way), but choosing "Safely remove" from the context menu will not work: SUSE will tell you it cannot find /media/ipod in /etc/fstab and you have no root privileges, so it cannot unmount the file system there.

Both SUSE/Novell and the KDE developer team apparently have been informed of this problem, and their reactions are a little amusing: KDE's developers say it's a SUSE-specific problem while SUSE/Novell maintain it's just a KDE bug:

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

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

I would rather take the side of the KDE team in this matter (after all, SUSE/Novell are responsible for their entire distribution the way it is being shipped, that is, even including any bugs KDE itself might have), though we will see that the KDE developers also contributed a little to the existance of this bug. Whoever might be to blame or not -- how do we find a workaround?

If we switch to a shell and try to unmount the iPod manually, we will find the same result. And the system is indeed all but correct: /etc/fstab does not have an entry for /media/ipod, because this mount point is handled by the HAL daemon.

There are several possible solutions, but none is easily implemented while still using subfs for automounting and HAL the way it is set up on SUSE 10. Interestingly enough, we are able to unmount the iPod with a different command: Simply calling eject /media/ipod from the shell actually works! This is because /bin/eject is set up as setuid root under SUSE 10.

We could stop here and just invoke eject /media/ipod from the command line each time we're finished transferring data to the iPod. If you find this solution acceptable, there's certainly nothing at all wrong with it. However, one question remains: Why doesn't selecting "Safely remove" from the iPod icon's context menu work, then? One would assume it also calls /bin/eject.

A look in the KDE svn repository, at the source code of kio_media_mounthelper, the program that does all the mounting and unmounting for KDE in the background, reveals that it actually does, via a wrapper script called kdeeject (which does no harm). However, it wants to unmount the device first and gives up if it can't. This is a a bit unfortunate: /bin/eject will try to unmount the device anyway, so there's really no need for KDE to attempt this. There's no way around this problem but patching the source for kio_media_mounthelper.

This patch, applied to the plain KDE 3.5 sources of /kdebase/kioslave/media/mounthelper/kio_media_mounthelper.cpp will make it only call kdeeject, not try to unmount on its own:

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);

You can download the svn diff here.

The patch is simple and should have no ill side-effects, as far as I can tell, because calling /bin/eject should always unmount the device in question. Nevertheless, patching system programs always comes with an inherent risk and you should be aware of what you are doing if you decide to use the patched version of kio_media_mounthelper on your machine. Of course I can take no responsibility for any damage this could effect.

After applying the patch, you will need to rebuild the kio_media_mounthelper binary and copy it to /opt/kde3/bin/kio_media_mounthelper. Note that you might not want to overwrite the original, but move it away first. Afterwards, having copied over the patched binary, ejecting the iPod from within konqueror's "system:/media/" URL should work as expected.

Finally, we have a working setup: We can plug in the iPod, SUSE will recognise it, we can transfer data to it from within gtkpod with decent speed and we can easily unmount it once we're done at the click of a single mouse button. This is, I might add, as it should have been right from the start.

Toys

The Nokia 9500 Communicator >>