Using an iPod with Linux

by Alan Donovan

This page is no longer actively maintained. &mdash adonovan.

This page shows you how to use an iPod with Linux. It's aimed at Linux purists, i.e. people who don't want to have to use a Mac or MS Windows-based PC to get going, nor to have to use Wine or any Windows software. (I fall into this category, not because of any religious convictions, but merely because Linux is all I have).

Also, I do not address any of the non-music features (games, calender, etc) in the latest iPods -- I regard these as feature creep. Buy a PDA if you want that.

This page is not an iPod advocacy site, although this gadget inspires fanatical levels of adulation from its fans about every detail of its design, as a quick Google or Amazon search will prove. I will say, though, that much of this is well-deserved. Even the cardboard box it comes in is a work of art.

This page assumes that you have reasonable Linux competence. Parts of the information presented here are available elsewhere on the web; I just gathered together what I needed to get up and running. Links to related sites are presented at the bottom.

iPod [photo: Apple Computers, Inc.]

Warnings & Disclaimers

DISCLAIMER: I make no claims that any of the instructions below will work for you, and I will take no responsibility for any loss or damage you may incur as a result of them. Following these instructions may potentially invalidate your warranty, so do so at your own risk.

The FAT conversion was basically successful for me, and despite a few scary moments when the PC crashed as I was updating the filesystem on the iPod, it was functional in the end. Numerous people have written to me to confirm that it worked for them.

HOWEVER, the FAT conversion has not been without problems: I have noticed that the unit is often unresponsive, and this has been confirmed by at least one other person. Most commonly, the display stops responding for several seconds. If you happen to be turning up the volume at the time, this can be very unpleasant, as 5 seconds later it goes straight to top volume and destroys your eardrums. Sometimes it skips half a song (though not repeatably, so I don't believe it's an error in the file) or even switches itself off, even at full charge. Also, I've managed to get the 'hold' switch into a state where white is locked and red is unlocked! Please bear this in mind, and read the troubleshooting section below for further relevant information. You have been warned!

An alternative approach, suggested by Erik Steffl (steffl at bigfoot dot com), is not to convert the iPod to use FAT32, but to use Linux's HFS+ drivers to access the Apple filesystem that the iPod has when it leaves the factory. This approach sounds more straightforward, if your kernel has HFS+ support. PLEASE NOTE that this approach is not guaranteed to work either, and while many users report success, others have reported problems.

An even simpler workaround, and possibly the most reliable method, is to avoid doing the FAT conversion process from Linux, and do it from a Windows-based PC, using the Apple-sanctioned conversion tool. Once this is done, you can use the iPod from Linux in the usual way. Obviously, this way requires you to have temporary access to a machine running MS Windows.

Please read this document from beginning to end, to understand both the advantages and risks of the FAT and HFS+ approaches, before you attempt any writes to the disk of your iPod.


You will need:

  1. A Mac or Windows iPod (obviously).

    The iPod is basically just a FireWire hard-disc, with its own operating software stored in one partition. The "Mac"/"PC" variants of the iPod are formatted with different filesystems, HFS+ in the case of Mac, and FAT32 in the case of Windows. Indeed, this is the only difference.

    Later breeds of iPod (3G onwards) come in a single flavour called "for Windows and Mac"; however these are HFS+-formatted, but come with software for Windows that invisibly does the conversion the first time they are used. [Please note: this process really is almost invisible, and it really will happen the first time you connect your new Mac iPod to Windows; this has confused some users -- so beware!]. So these are really just Mac iPods. If you have access to a PC with MS Windows, you could use that to do the conversion. (Thanks to Zach Hobbs (zach at firstwavedesign dot com) for this information.)

    If you have a "Windows" iPod (i.e. one that has already been converted to FAT), the conversion steps below are not necessary: Linux has full support for the FAT filesystem. If you have a "Mac" iPod (e.g. straight from the factory) you have two choices:

    1. Convert the HFS+ filesystem to FAT32, erasing the disc in the process. The iPod firmware is identical, though, so we must save this before we begin.

      Historically, Linux has had very limited support for HFS+, so this was the most obvious option. However, problems have been observed with the conversion process -- see the warning at the top.

    2. Alternatively, if you have a newer kernel, you can try to mount the HFS+ filesystem directly. I have heard from a number of people that this approach works for them, and is more straightforward. See here.

    If you decide to do the conversion, don't mess around with Wine, or with WinniePod Updater, the Apple-sanctioned tool for HFS-to-FAT32 conversion. The GNU instructions for how to convert are sufficient and require only fdisk, dd and mkfs.vfat which are standard UNIX tools.

  2. A linux system with a recent, FireWire-capable kernel (2.4.12 or later -- now might be a good time to upgrade to RedHat 9.0 (Shrike) or similar).

    Note that the version of RPM that comes with RH 9.0 has an annoying bug: sometimes it will crash, and on subsequent executions, it will hang, waiting for a mutex (in the futex syscall, as can be observed using strace). If this happens, simply remove the /var/lib/rpm/__dbxxx temporary files from the RPM database and try again.

    (Another aside: disappointingly, the version of the xmms media player that comes with RH 9.0 doesn't include support for MP3 files, only Ogg, due to licensing restrictions. MP3 support must be installed separately from the xmms-mpg123 RPM, available at and

  3. A working FireWire interface; I use an Orange Micro PCMCIA card for a laptop, which works fine, although this card is oversize, i.e. it has such large physical dimensions that it coexist with other oversize cards in a pair of PCMCIA slots.

    It still seems that the kernel support for FireWire is a little flaky, so try to avoid issuing and/or interrupting unnecessary commands, or removing the interface while the drivers are doing something.

    (I've had problems using IEEE1394 that seemed to vary between computers, e.g. worked with a Toshiba, didn't work with an IBM (!). Perhaps an up-to-date kernel would help.)

  4. The GtkPod package; GtkPod is a free, graphical tool for transferring files to and from the iPod. It is the Linux equivalent of the iTunes software used for this purpose on the Mac.

    I used the gtkpod 0.50 RPM, which is available from This package requires the id3lib package.

    As James Blackwell (jblack at inframix dot com) points out, you must use a tool such as GtkPod, you cannot simply copy files onto the iPod's harddisk, as the pod's database must be updated for it to see the new tracks.

    James Krunk (krunkalot at hotpop dot com) points out that the first time you use GtkPod, you must select "Create Directories" from the "File" menu to set up the database on the iPod.

  5. The grip package; grip is a free, graphical tool for ripping CDs and encoding them as MP3s.

    Note that when ripping CDs to files, the actual filenames are not important to the iPod: its music database is populated from the ID3 tags embedded within the MP3 files, thus it is important that these are accurate.

    In particular, this means that (a) you should encode MP3 files from an album all together, or else you will lose the album track-numbering information; and (b) that you can use convenient filenames (such as track07.mp3) instead of naming the files after the tracks (e.g. "07. Voodoo Chile (Slight Return).mp3") as the shell metacharacters present in the latter make them a pain in the ass to work with.

Setting up:

Assuming you're using a PCMCIA FireWire card, once the card is inserted, the cardmgr daemon should take care of loading the ieee1394 and ohci1394 modules. If you have a PCI card, these should be loaded by system startup (/etc/rc.local).

When you attach the iPod to the FireWire interface, the sbp2 module is auto-loaded. (If it's not, load it with modprobe). You should see messages appears in dmesg indicating the device is recognised; additionally, /proc/bus/ieee1394/devices will contain information on each device, including the string [Apple Computer, Inc.] for the iPod.

ieee1394: Host added: Node[00:1023]  GUID[00d0f5cd4008049d]  [Linux OHCI-1394]
ieee1394: Device added: Node[00:1023]  GUID[000a2700020e545e]  [Apple Computer, Inc.]
ieee1394: Node 00:1023 changed to 01:1023
SCSI subsystem driver Revision: 1.00
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node[00:1023]: Max speed [S400] - Max payload [2048]
scsi0 : IEEE-1394 SBP-2 protocol driver (host: ohci1394)
$Rev: 707 $ James Goodwin 
SBP-2 module load options:
- Max speed supported: S400
- Max sectors per I/O supported: 255
- Max outstanding commands supported: 64
- Max outstanding commands per lun supported: 1
- Serialized I/O (debug): no
- Exclusive login: yes
  Vendor: Apple     Model: iPod              Rev: 1.40
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 58595040 512-byte hdwr sectors (30001 MB)
sda: test WP failed, assume Write Enabled
 sda: sda1 sda2

At this point, the iPod appears as a fake SCSI device (typically /dev/sda if you have no other SCSI devices) and can be accessed using the regular UNIX tools for block devices. However, if you are using a Mac iPod, fdisk will not recognise the partition map, and you will get a message resembling "Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel". In this case, it is time to follow the GNU instructions (see link above) for conversion. They are summarised below.

(Lachlan Gunn (lachlan76 at points out: [...] Linux is unable to read the partition table, however, in the kernel config under "File Systems/Partition Types" there is an option for reading Mac partition tables when "Advanced Partition Selection" is selected. [...] I don't actually own an iPod so I could be wrong about this.)

At this point the Linux IEEE1394 drivers (ieee1394, ohci1394) should have recognised the hardware:

% cat /proc/bus/ieee1394/devices
Node[00:1023]  GUID[001106000000649a]:
Vendor ID: `Linux OHCI-1394' [0x004063]
Capabilities: 0x0083c0
Bus Options:
IRMC(1) CMC(1) ISC(1) BMC(0) PMC(0) GEN(0)
Host Node Status:
Host Driver     : ohci1394
Nodes connected : 2
Nodes active    : 2
SelfIDs received: 2
Irm ID          : [00:1023]
BusMgr ID       : [00:1023]
In Bus Reset    : no
Root            : no
Cycle Master    : no
IRM             : yes
Bus Manager     : yes
Node[01:1023]  GUID[000a2700020ec65a]:
Vendor ID: `Apple Computer, Inc.' [0x000a27]
Capabilities: 0x0083c0
Bus Options:
IRMC(0) CMC(0) ISC(0) BMC(0) PMC(0) GEN(0)
LSPD(2) MAX_REC(2048) CYC_CLK_ACC(255)
Unit Directory 0:
Vendor/Model ID: Apple Computer, Inc. [000a27] / iPod [000000]
Software Specifier ID: 00609e
Software Version: 010483
Driver: SBP2 Driver
Length (in quads): 8

% cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: Apple    Model: iPod             Rev: 1.40
Type:   Direct-Access                    ANSI SCSI revision: 02

In summary, performing the HFS-to-FAT32 conversion involves:

  1. saving the first 32MB of the second partition, which contains the iPod firmware image. Keep this file safe somewhere on your PC. (During FAT conversion, this will be your only copy of the iPod firmware as it arrives from the factory; if for some reason you need to repeat the conversion process, do not overwrite this file!)
    % dd if=/dev/sda2 of=backup_firmware
  2. splatting zeros all over the partition map so that all disc data is effectively erased. We unload and reload the sbp2 driver to update its world-view.
    % dd if=/dev/zero of=/dev/sda bs=1M count=10
    % rmmod sbp2 && modprobe sbp2
  3. creating two partitions: the first, large enough to hold the 32MB file we saved earlier; the second, the remaining 30GB of the disc. We tag the two partitions as Empty, and FAT32, respectively.
    % fdisk /dev/sda
    n   [make new partition]
    p   [primary]
    1   [first partition]
    [just press enter -- default first sector is 1]
    5S  [5 sectors -- big enough to hold 32MB]
        [on 20GB models, Corrin Lakeland suggests using "+33MB" instead of 5S]
    n   [make new partition]
    p   [primary]
    2   [second partition]
    [just press enter -- default first sector is 6]
    [just press enter -- default size uses all remaining space]
    t   [modify type]
    1   [first partition]
    0   [first partition has no filesystem; ignore warning]
    t   [modify type]
    2   [second partition]
    b   [second partition is FAT32]
    p   [show partition map]
    Device Boot    Start       End    Blocks   Id  System
    /dev/sda1          1         5     40131    0  Empty
    /dev/sda2          6      3647  29254365    b  Win95 FAT32
    w   [commit changes to disk]
  4. copying the firmware back, to the small first partition.
    dd if=backup_firmware of=/dev/sda1
  5. making a FAT32 filesystem on the second large partition.
    mkfs.vfat -F 32 -n "My iPod" /dev/sda2
    [If this step fails, read K.R.Foley's workaround for a problem he encountered, below.]
If all goes well, resetting the iPod (by holding Menu and Play for 5 seconds) will cause it to reboot to the familiar menus. If not, go through the instructions again. Remember, the iPod is just a hard-disc, so as long as you have the original firmware backed-up correctly and safely on the PC, you can reformat it as many times as you like. (It worked for me first time.) [Be very wary about installing different firmware from the one it came with, however.]

Also, at this point, you should be able to mount the disc in the usual way. Once this works, setup is complete and you are through to the "normal use" instructions below.

Normal usage:

The drivers a still a little flakey; sometimes the sbp2 driver will get stuck in its (initializing) state indefinitely, and cannot be removed; other times the machine will hang.

Therefore I strongly advise that you follow a disciplined procedure for docking and undocking the iPod, to minimise the risk of such errors. The order of events I usually employ is: (1) insert the IEEE1394 PCMCIA card into my laptop. Check that this succeeded by running lsmod and looking for ieee1394 and ohci1394. (2) attach the iPod. This time the sbp2 driver should appear. If it does not, try detaching and re-attaching it. (3) mount the iPod as a disk, copy files across and then unmount it again. (4) rmmod the sbp2 driver. (5) detach the iPod. (6) remove the IEEE1394 card.

Note that these steps are perfectly symmetrical. This seems to achieve greater reliability than performing them in an arbitrary order.

I use two scripts, dock-ipod and undock-ipod, whenever I attach or detach the iPod to the interface card. They must both be run as root:

Here's dock-ipod:


modprobe sbp2
mount /dev/sda2 /mnt/ipod/
And undock-ipod:

umount /mnt/ipod
rmmod sbp2

Downloaded MP3 files and ID3 tags

The iPod does not care about the filenames of MP3 files; all its database information is supplied by ID3 tags within MP3 files. Therefore these must be present for transferred files even to appear on the iPod.

Often, you want to add MP3 files to the iPod that did not come from a CD (e.g. those downloaded from Napster, Kazaa, etc). The ID3 tags in such files are often inappropriate, e.g. because they feature the original artist/album name from the CD they came from, instead of the logical group to which they will belong on your iPod (e.g. "Misc/80's Synth Pop"). If you do nothing about this, you will find each song appearing in its own artist/album category, with no useful grouping. Other times when you need to tag manually are when CDDB lookup fails (e.g. for "non-industry" CDs) or for MP3 files that were hand-encoded from WAV.

Therefore you need to use a tool such as ID3ed to change the tags. The tool is pretty straightforward and comes with a manpage. Alternatively, you can use a graphical tool such as xid3, which has a Tcl/Tk-based front-end for ID3-tag editing, which makes it a lot easier to use. (Thanks to John Borwick (john_borwick at pobox dot com) for this information.) The most important ID3 tags for the iPod are Artist, Album, Title and Track Index (and additionally Genre, if you actually bother to use that).

You might also want to explore a related hack of mine, extractcd, which scrapes artist, track and cover art info from web pages. Combined, these two tools can (in theory) automatically tag a whole directory of MP3 files as a single logical album.

iPod special features:

Here are some iPod UI features that aren't so obvious.
  1. Reset: hold down Menu and Play buttons for 5 seconds.
  2. Backlight: hold down Menu button for 2 seconds.
  3. Go to sleep: hold down Play button for 5 seconds.
  4. Force firewire-disk mode: hold down Forward and Back buttons together for a few seconds after resetting. (more)
(There are more; I will add them as I find them.)

Alternative approach: using HFS+

Regarding using HFS+ drivers and not reformatting the iPod to FAT32, Erik Steffl (steffl at bigfoot dot com) says:

"I got a response from gnupod's Adrian Ulrich, the problem was that I was missing mac style partitions in my kernel (I had HFS+ but I wasn't aware of the need for the different partition style). In addition to that only the parted tool recognizes Mac-style partitions (fdisk, sfdisk, sfdisk don't).

"In the end I didn't convert my iPod to FAT32, I am using the HFS+ driver (kernel 2.4.21), and it seems to work (I used gtkpod to copy MP3s to the iPod)."

In order to do this, Erik mentions you need the HFS+ driver, Mac-style partition support, and the parted tool. He refers you to Adrian Ulrich's updated gnupod documents which describe this process. Please note, kernel support for Mac partitions, and and the parted tool, are both requirements; fdisk will not work.

Mattes K. (mattes at mykmk dot com) confirms that the HFS approach works with kernel 2.6.3- (Fedora Core release 1.91, FC2) and an off-the-shelf IEEE1394 PCI card. He was able to mount the pod simply by issuing: mount -t hfsplus /dev/sda3 /mnt/ipod.

"Good job with the info you put together there for the ipod. I got my ipod mounted in a snap. Thought I let you know how helpful your pointers are. [...] Started 'gtkpod' and click on 'read iTunesDB' and it works. I couldn't believe how easy that went. What I like about it most: "no iPod disk conversion necessary". Played existing content from the iPod and added some new MP3 to the iPod. Thought I let you know. thanx for putting all the info together. As well thanx to the folks who made 'gtkpod' available."

Corrin Lakeland (lakeland at reports that reading HFS+ works, but writing was problematic; also, he suggests that USB can be used as a more straightforward alternative to FireWire:

1) I got a USB cable with my iPod for about $25 extra. Since a PCI firewire card is about the same, this seemed a good idea and cuts out a lot of work. I would recommend anybody without firewire gets the cable instead of a PCI card.

2) Running kernel 2.6.7 I was able to mount the ipod right from when I got it by issuing the command: mount -t hfsplus /dev/sda3 /mnt/ipos.
However, write support seemed unreliable and despite using uid=1002 in /etc/fstab, I kept having all files owned by root (or some user 99 which doesn't exist on my system). Sometimes comamnds worked, frequently the failed. I spent quite a lot of hours before I finally gave up and swapped to vfat. I hope that in a few kernels, hfsplus will work for everyone.

Andy Goth (unununium at also reports problems using the HFS+ approach:

Everything was going fine with my iPod until my system halted in the middle of a sync. I guess I should have used a newer kernel (2.4.22).

Anyway, now the iPod's data partition (HFS+ format) is marked as not having been cleanly unmounted, therefore I cannot write to it. If that was the only problem, I could fix it with a little bit fiddling or commenting out checks in the kernel driver. But there's also some corruption. The iPod itself still runs fine, playing the [only] song that was on it prior to the failed sync.

Klaus Halfmann's hfsplus tools (hpls, etc.) report a filesystem state more-or-less consistent with the iPod's actual behavior (i.e. only that one song is listed). But hpfsck reports inconsistencies. At present there's no code to repair filesystem problems. (Klaus: "Please give me time :-)")

The Linux driver, on the other hand, shows all the new files I added in the sync (up to the point of failure, I imagine) and also indicates the removal of the original song (which is correct). I'm curious how different programs (iPod and hpls versus Linux hfsplus) can read the same directory differently.

The upshot is, I can't write anything more to the iPod until I do one of the following:
- Wait for hpfsck to grow some repair code
- Connect my iPod to a Mac OS X system and use DiskFirstAid
- (Maybe) Connect my iPod to a PC running MS-Windows and iTunes
- Reformat to use FAT32 (ick?)
I know of a Mac OS X system I could use, but there's a bit of a commute, I might need root access or something to do the repairs I need, and the machine is nominally reserved for graphics work. So it's chancy.

There's probably an iPod Restore tool on the iPod CD, but I need Mac OS X or MS-Windows to use it. I'll probably have an easier time finding a Windows PC than a Mac computer, so most likely this is what I'll do.

What does this mean for your guide? Post a warning against unplugging the iPod or rebooting (or crashing) the machine while it's mounted. And underline it. State that at present there are no Linux tools for creating or repairing HFS+ partitions.

One last thing. On my system with my iPod, /dev/sda1 appears to be an "Apple_partition_map", /dev/sda2 is the iPod program (starting with a hilarious ASCII stop sign), and /dev/sda3 is the data partition. This is contrary to your guide. Maybe my system's too old or misconfigured, or misread your guide. But I just thought I should point it out.

(Note that the partition map Andy refers to, shown in step 3 of the FAT conversion, is the state after FAT conversion, not the state as the unit arrives from the factory.)

Andy later followed up with the following information:

[Lacking a USB cable,] I plugged [in the iPod to an] iBook and connected the [iBook to the linux machine] with a crossed-over Ethernet cable.

I have done this in the past using NFS so GtkPod could work naturally, but NFS wasn't up to the load. (I forget precisely how it failed, but it did, repeatedly.) Now I just did the old tar-over-TCP trick:

desktop$ nc -l -p 9999 | tar xv
ibook  $ tar c /Volumes/iPod/subdir/ > /dev/tcp/desktop/9999

to transfer the entire contents. Works great, especially since I'm using the Apple HFS+ driver to access the disk. (Actually [it] may have [been] converted to FAT32, but [...] I didn't think to check [...])

More details:
- subdir is the path to the music, which I can't remember offhand.
- > /dev/tcp/desktop/9999 is a bashism meaning what you'd expect.
- nc -l -p 9999 is Netcat listening on TCP port 9999.

Last time when I had trouble with Linux futzing up the HFS+ partition, I borrowed an iBook from the local school district to run iTunes to restore the iPod, which means reformatting and regenerating the basic directory tree. Then I performed the same operation to install the music from my mirrored tree which I had assembled using GtkPod.

I've been working on some iPod software in Tcl for my brother to use. All he wants is a program to browse and copy tunes from an iPod, since he and his sailor buddies all share. The only code that's in a usable state is itunesdb. See the example.

Shields (shields at confirms Andy's observation of the factory-set HFS+ partition map:

I can confirm that this is the case for 4G (click wheel) iPods. Here is the factory partition map for a 40 GB iPod:
        #                 type name             length   base  (size)   system
/dev/sda1  Apple_partition_map partition map        62 @ 1     (31.0k)  Partition map
/dev/sda2           Apple_MDFW firmware          65536 @ 63    (32.0M)  Unknown
/dev/sda3            Apple_HFS disk           78060448 @ 65599 (37.2G)  HFS

Block size=512, Number of Blocks=78126048
DeviceType=0x0, DeviceId=0x0

Ericv (ericv at cruzio dot com) has helpfully provided information about the factory-set partition map of his HFS+ iPod Mini (December 2004):

(parted) print
Disk geometry for /dev/sde: 0.000-3906.000 megabytes
Disk label type: mac
Minor    Start       End     Filesystem  Name                  Flags
1          0.000      0.030              partition map
2          0.031     32.030              firmware
3         32.031   3905.999              disk
It is clear that /sde1 is the map, /sde2 is the firmware portion, and /sde3 is the "user data" area. Of course, I'm still being hosed by the filesystem only mounting read-only (perhaps because I'm trying to use USB1.1?).
Eric also provided the following tip for mounting his HFS+ iPod in read/write mode:

I had been having a hell of a time getting HFS+ to mount read/write. Mounting via "mount -t hfsplus " only let me mount read-only (useless for then attempting to place files on your iPod). After some thrashing about, and trying to deal with the spurious message that appeared in /var/log/kern.log about hfs+ not having been unmounted cleanly, I happened upon the command "hpmount" which works just like regular mount except it is for hfsplus filesystems.

Now I just use "hpmount /dev/sde3" (sde3 is my iPod) and I'm good to go.

Mind you I'm a Debian (Sarge) user. YMMV for other distros.

A note about iPod models

There are a number of different iPod models out there. The instructions on this page are intended to apply to all the hard-disc based ones. The iPod Shuffle is based on solid-state storage and I haven't yet heard any reports from people trying to use it with Linux. (If you've tried, let me know how you got on.)

The table below shows the model numbers of the various iPods, sorted by the major revisions (invariably but inexplicably referred to as "generations", even though they're usually less than a year apart.)

You can find out the model number of your iPod by looking at the "About" screen on the "Settings" menu. The first five letters/digits are the interesting part. (The remaining letters seem to denote the region and minor revision number, e.g. "M8948LL/A" refers to a 30GB 3G model in the US). There are many sites out there to help you identify which ipod you have:,

First "Generation" (1G)
[Mechanical buttons arranged around movable "scroll wheel".]
5 GB M8513 M8541 (Mac)
5 GB M8697 (PC)
10 GB M8709 (Mac)
Second "Generation" (2G)
[Same buttons as 1G around touch-sensitive "touch wheel".]
10 GB M8737 (Mac)
20 GB M8738 (Mac)
10 GB M8740 (PC)
20 GB M8741 (PC)
Third "Generation" (3G)
[Buttons are now touch sensitive and arranged in a line above "touch wheel". Docking.]
10 GB M8976
15 GB M9460, M8946
20 GB M9244
30 GB M8948
40 GB M9245
Fourth "Generation" (4G)
[Buttons integrated into "click wheel".]
20 GB M9282
40 GB M9268
20 GB M9787 (U2)
iPod Shuffle
512 MB M9724
1 GB M9725
iPod Mini
[in colours: Silver, Blue, Pink, Green, Gold]
First "Generation":
4GB M9160, M9436, M9435, M9434, M9437
Second "Generation":
4GB M9800, M9802, M9804, M9806, ?
6GB M9801, M9803, M9805, M9807, ?
iPod Photo
40 GB M9585
30 GB M9829
60 GB M9830, M9586

Currently, the techniques described on this page apply equally to almost all of the hard-disc-based (i.e. not the Shuffle) iPods. This includes the iPod Photo: Johannes Loxen (jl at sernet dot de) says: "It works. Most actual kernels need the attached patch [to the usb-storage module]. Apple changed the DBs a bit. So rsyncing my 40GB-iPod archive to the 60GB-iPod photo screws the big one up :-) MP3s have to re-imported..."

Troubleshooting ("what if I get stuck??")

Kostya Tomashevsky (withthemostya at yahoo dot com) wrote the following:

"First, thanks a lot for your detailed instructions on connecting and reformatting the iPod with linux. They worked fine for me in the end, but for a few minutes I thought I'd made a $400 dollar paper weight.

"I had accidentally disconnected the iPod without formatting my second partition with mkfs.dos so it froze on the Apple logo and wouldn't allow the sbp2 driver to attach. Normally the firmware automatically initiates firewire-disk mode, but in its non-functional state I found out that I had to do this manually. Holding the forward and back button for a few seconds after resetting forces it to connect. That would be a useful fact for anyone who botched the first conversion.

"Also, some linux kernels, including my own don't automatically attach the iPod to /dev/sda even after loading sbp2. You have to run a script that scans /proc/scsi and utilizes /dev/sda. You might want to include this link to the script."

Responding to my description of problems of iPod unresponsiveness after FAT32 conversion, michael_gk at gmx dot net wrote:

"The problem that it no longer responds annoyed me so terribly (often it didn't react for nearly a minute) that I called the tech-support.

"They said I should first reformat it. I did that using the Windows program. I put my songs on it using iTunes and now everything is working fine. No single "lag" since then. I used the iPod from time to time with iTunes on Windows but mainly with Ephpod (in wine) and gnutunes [AD: what is this?] on linux. Maybe that "mix" caused the problems? I don't know...

"If you have all your tracks on a harddisk an can easily transfer them again, you should try reformatting it."

Stefan Schmidt ( at reports success using HFS (this time with USB):

"I have a mini running over USB 1.1 (old mobo... haven't felt the pain of transfering 4 gigs yet) with debian testing, and a 2.6.7 kernel. Running "mount -t hfsplus /dev/sda /mnt/ipod" worked.

Thomas McMahon (thomas.mcmahon at confirmed the HFS+ method works on a PowerPC:

"I also had success with the HFS+ alternate method. I'm running Ubuntu 4.10 with Three easy steps (as root):
1. mkdir /mnt/ipod -- Need this directory for gtkpod to know where your iPod is.
2. mount -t hfsplus /dev/sda3 /mnt/ipod -- mounts the ipod to /mnt/ipod
3. gtkpod -- opens gtkpod, everything "just worked".

Colin Slater (kiltedtaco at gmail dot com) confirms that the FAT conversion approach works with the 4G iPods, using USB. However, he reported that the /dev/sda2 HFS+ partition did not appear, so he had to read the firmware directly from the correct part of the /dev/sda disk:

Due to some oddity of my kernel configuration or udev setup, when I plugged in my hfs+ formated ipod, I only saw one block device, which was the entire drive. The workaround for this was to use mac-fdisk to read the partition table off this block device. It shows quite clearly where the ipod firmware is on the drive, something like 63 blocks in and 65536 blocks long. [AD: see Shields' posting, above.] Dropping these parameters into dd extracts the software perfectly. The partition table can then be deleted and recreated as you describe. It's not any easier than dd'ing from sda2, but it was the only way it would work for me.

(Hmmm.. sounds like your kernel lacks full HFS+ partition support. Good to know it's not really necessary.)

Matthew Arcidy (marcidy at gmail dot com) reports an alternative (and simpler) method for rescanning the SCSI bus for new devices:

One thing is that when I moved to kernel 2.6.10, I couldn't use the rescan script that is linked from your site for whatever reason. I admit I don't necessarily know what I'm doing, but I solved the problem looking through /sys/bus/ieee1394 and found this file named "rescan". If you read it, it says "write 1 to this file to trigger a rescan". Which I did.
echo 1 >> rescan
worked and it triggers the scan of the bus, which then gives some more info. [...] I'm pretty sure it's because i have sysfs enabled in my kernel.

K.R. Foley (kr at cybsft dot com) reports a problem using HFS+, which caused him to switch to using FAT instead; however he encountered a different problem during the FAT conversion, and figured out a solution:

I had reasonably good luck with hpfsplus and gtkpod on my Fedora Core 3 system (with a recent kernel). However, the hpfs tools suck. So the first time you disconnect without unmounting or some such, you're looking at a hack job to fix it. Because since the second time that happened my space reporting has been hosed, I decided to change over to fat. Anyway, using your guide and someone else's as well, I ran into problems with mkfs.vfat.

[root@elmer ipod]# mkfs.vfat -F 32 -I -n "My iPod" /dev/sda2
mkfs.vfat 2.8 (28 Feb 2001)
mkfs.vfat: failed whilst writing reserved sector

Every combination I tried produced this result. Even tried ext2 which worked fine. This was a clue for me. What I did then was go back to fdisk and rather than create two partitions, I created three. The third just has one block in it like so:

Disk /dev/sda: 4095 MB, 4095737856 bytes
126 heads, 62 sectors/track, 1024 cylinders
Units = cylinders of 7812 * 512 = 3999744 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sda1            1           9       35123    0  Empty
/dev/sda2           10        1023     3960684   83  Linux
/dev/sda3         1024        1024        3906   83  Linux

This is before changing sda2 to be type b. This did the trick. I got no complaints from mkfs.vfat anymore. I am still in the process of putting everything back on the disk, but so far so good.

Links to other resources:

Many thanks to the authors of the following sites, which provided me with the information summarised on this page:

Thanks to:


Copyright (c) 2003—2005 Alan Donovan. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

Other licensing terms are available; please contact the author.

Material in this page is used under license in the book iPod & iTunes Hacks (0-59600-778-7), edited by Hadley Stern and published by O'Reilly.
Last updated: 19 February 2006