Re: grub-probe fails to find PC partition due to Apple disklabel

[Chris Knadle]

On Friday 25 July 2008, Robert Millan wrote:
> On Wed, Jul 23, 2008 at 04:47:42PM -0400, Chris Knadle wrote:
> > On Wednesday 23 July 2008, Chris Knadle wrote:
> > > Right now part_map_iterate() detects an Apple partition based on Sector
> > > 0 [which is unavoidable, since Sector 0 is not going to have an HFS+
> > > magic number]
> >
> >    Sorry, I meant *partition 0*, not Sector 0...
>
> Assuming the problem is the missing check for the other magic number in
> sector 0 (of the whole disk), I just sent a patch in:
>
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475718#70
>
> which supposedly fixes this problem.  Please test!

   Just tested -- nope, grub-probe still can't find the device.  Have a look 
at the following snippit of a 'grub-probe -vv /dev/hde3' output to see the 
interesting behavior this generates -- note that the first two bytes on this 
disk /dev/hde (i.e. the first two bytes on the disk, which should be part of 
the JUMP VECTOR to Grub) are 0xFC31.  So this:

   kern/partition.c:106: Detecting apple_partition_map...
   kern/disk.c:368: Reading `hd0'...
   partmap/apple.c:129: bad magic (found 0xfc31; wanted 0x4552
   kern/partition.c:112: apple_partition_map detection failed.

means that this patch is trying to match the HFS magic number on the first 
sector of the drive, when that doesn't have a filesystem magic number at 
all.  :-(  Do you see the problem -- or am I wrong about this?  If I'm 
correct (and I really hope I'm not), it means that there's no good way of 
discarding Apple partition detection based solely on Sector 0 of the drive -- 
which was already suspected anyway, since Apple and PC partition maps can 
coexist.

I'm going to attach the full 'grub-probe' output and a dd of the first 1024 
bytes of /dev/hde to the Debian bug report.

  -- Chris

-- 

Chris Knadle
address@hidden