Before I think about filing a bug I'd though I would start a discussion on this. EFI GUID Partition support is currently only supported on IA-64. Intel is eventually supposed to support this on future platforms. But today it is causing havoc, and I would very much like this off in FC3. The Apple Ipod (4th Generation) , Ipod Mini, as well as some USB and Firewire drives are no longer mountable under Linux with this option on. The 37th post at this link gives a good explination. http://www.linuxquestions.org/questions/showthread.php?s=&threadid=213012&perpage=15&highlight=ipod&pagenumber=3 Seeing how nothing today or foreseeable in the next year is using this, I don't see why this cannot be cut off for both the X86, X86_64, and PPC kernels. Just in case the link breaks here is cut and paste job of the post below: Okay, I've been following this thread and I've been having the same problem. I have a mini iPod. It works really well with my desktop maching running redhat-9 (2.4 kernel). I recently got a new laptop running SUSE 9.1 (2.6 kernel) and on the laptop I have the problem described by others in the thread: when plugged-in the kernel will find the device but quickly have an I/O error and the device is unreadable at that point: code: Sep 24 21:14:26 t42p kernel: usb 4-3: new high speed USB device using address 4 Sep 24 21:14:26 t42p kernel: usb 4-3: Product: iPod mini Sep 24 21:14:26 t42p kernel: usb 4-3: Manufacturer: Apple Sep 24 21:14:26 t42p kernel: usb 4-3: SerialNumber: 0000008638BA Sep 24 21:14:26 t42p kernel: scsi2 : SCSI emulation for USB Mass Storage devices Sep 24 21:14:26 t42p kernel: Vendor: Apple Model: iPod Rev: 1.61 Sep 24 21:14:26 t42p kernel: Type: Direct-Access ANSI SCSI revision: 02 Sep 24 21:14:27 t42p kernel: SCSI device sda: 7999488 512-byte hdwr sectors (4096 MB) Sep 24 21:14:27 t42p kernel: sda: assuming Write Enabled Sep 24 21:14:27 t42p kernel: sda: assuming drive cache: write through Sep 24 21:14:27 t42p kernel: sda:end_request: I/O error, dev sda, sector 7999480 Sep 24 21:14:27 t42p kernel: Buffer I/O error on device sda, logical block 999935 Sep 24 21:14:27 t42p kernel: end_request: I/O error, dev sda, sector 7999480 Sep 24 21:14:27 t42p kernel: Buffer I/O error on device sda, logical block 999935 Sep 24 21:14:27 t42p kernel: sda1 sda2 Sep 24 21:14:27 t42p kernel: Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 0 Sep 24 21:14:27 t42p kernel: USB Mass Storage device found at 4 In my case I'm using a mini iPod with USB2, but the same problem (and solution) probably applies to the firewire interface or newer generation large iPods, but I don't have either of these to test. To make a long story short, you can solve the problem by disabling the feature CONFIG_EFI_PARTITION in your kernel and rebuilding the kernel. This problem could potentially happen with both 2.4 and 2.6 kernels. A longer story follows and perhaps someone can come up with a more sensible solution for the long run. The iPod looks like a removable disk drive to the host computer. When it is attached to the computer, the mini iPod reports a capacity of 7999488 512-byte sectors (or about 4GB). This turns out to be wrong for whatever reason. The mini iPod only really has 7999376 sectors and it exaggerates by 112 sectors. The other quality of the iPod is that if the computer attempts to read a sector greater than the actual capacity but less than the reported capacity, the iPod will dutifully report an I/O error, but it won't respond to any future requests until you unplug/plug the iPod. This creates a fragile situation where the host computer can croak the iPod by reading one of these 112 tacitly illegal sectors. If you ask me, this is an Apple bug (or maybe a bug of their disk supplier or firewire/USB interface supplier), but a bug nonetheless. So, when a new disk is presented to the linux kernel, linux first goes out and tries to find the partition table for the disk. Usually this is the first sectors of the disk (traditional microsoft partition table we've been using for 20 years), but there are also a number of other types of partition tables. The kernel uses a heuristic to look for different types of partition tables and the kernel configuration specifies which partition types are attempted. The "EFI" partition table is a new type of partition table that is part of the "extensible firmware initiative", this is a good thing for the future. I don't know anything about EFI partition tables, except that as part of looking for an EFI table linux goes out and reads the last few sectors of the disk (sector 7999480 in the case of a mini iPod). The kernel looks for an EFI partition before looking for an old fashioned MSDOS partition table and this croaks the iPod. If you disable support for EFI partition tables (CONFIG_EFI_PARTITION) the mini iPod will work fine. I don't know of a quick fix short of rebuilding the kernel. Of course, once it's working, previous advice about setting up hotplug correctly and having the right /etc/fstab entries and such apply, but the iPod is just great under linux and gtkpod is a fantastic program for managing the iPod.
