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 [EMAIL PROTECTED] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
