Suggestion to cutoff "EFI GUID Partion Support" in the kernel so that Ipod & others will be mountable

Jerone Young jerone at gmail.com
Mon Sep 27 03:36:13 UTC 2004


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.





More information about the fedora-devel-list mailing list