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

[Chris Knadle]

On Monday 14 April 2008, Robert Millan wrote:
> Hi Chris,
>
> Initially, all partmaps were arch-specific, so that "pc" arch had msdos
> and gpt partmaps, etc.  This avoided the problem;  so maybe what we could
> do is probe for "native" partmaps first, and then for all the rest?  I can
> think of two ways of doing this:
>
>   - Explicitly probe for native partmaps for each arch (#ifdef
> MACHINE_BIOS, etc), then probe for all.  This is ugly and also inefficient
> (some partmaps are probed twice).
>   - Change the partmap order in partmap.lst (can be complicated because of
> the build system), and make the prober follow the order in that file.  But,
> uhm, how would we access the file in the first place, before partmaps are
> probed? How does it work _now_ actually?
>
> another way would be to add sanity checks in the prober, so that a partmap
> is never identified as "good" when one of its partitions are out of bounds
> or so. But then again:
>
>   - Failing completely for an otherwise perfectly-sane partmap just because
> one partition is out of bounds sounds like a bad idea.
>   - It doesn't completely fix the problem anyway.
>
> Comments?

   The thought I had on this is that the search order for particular partition
maps probably needs to be arbitrary; i.e. there probably isn't a particular
search order that would cover this type of situation for all architectures
that grub2 functions on.  And as you mentioned, there probably isn't a good
way of specifying that search order before grub2 is installed.

   Going back to probing for native partmaps first...  hmm.  Is there any case
where that may create the opposite problem?  i.e. would it be possible for a
disk in a portable drive that's been used for both an Apple and an IBM PC but
which is actually currently partitioned for an Apple may be falsely detected
as being set up for an IBM PC?  I don't know.
   If there was a design decision to move away from doing this then there was
likely a reason for doing so; perhaps there was a similar situation where a
more flexible design was required.  i.e. my first thought would be to look
into why the design decision was made because there may be use cases where the
current design is required.

   Instead of probing for partmaps in a particular order, it seems that
solving for this might best be done by probing for all of the possible
partmaps for the architecture and trying to figure out which one best fits. 
grub2's grub-probe is clearly already doing this; _however_, somehow the PC
partmap probe is subtly different depending on whether partmap/apple.c is
included in the search.

The debug output files --
with partmap/apple.c detection:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=grub-probe_0.97-36.txt;att=1;bug=475718
without partmap/apple.c detection:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=grub-probe_noapple.txt;att=1;bug=475718
       
Comparing between the two outputs:

with partmap/apple.c detection:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   partmap/pc.c:141: partition 0: flag 0x0, type 0x83, start 0x3f, len 
0x3a384c02
   partmap/pc.c:141: partition 1: flag 0x0, type 0x0, start 0x0, len 0x0
   partmap/pc.c:141: partition 2: flag 0x0, type 0x0, start 0x0, len 0x0
   partmap/pc.c:141: partition 3: flag 0x0, type 0x0, start 0x0, len 0x0

without partmap/apple.c detection:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   partmap/pc.c:141: partition 0: flag 0x0, type 0x7, start 0x3f, len 0x4c5fbfa
   partmap/pc.c:141: partition 1: flag 0x80, type 0x83, start 0x4c5fc39, len 
0x32fcd
   partmap/pc.c:141: partition 2: flag 0x0, type 0x83, start 0x4c92c06, len 
0x274c3c5
   partmap/pc.c:141: partition 3: flag 0x0, type 0x5, start 0x73defcb, len 
0xb639af6


Look at the detection of partition 0 between the two; both the type and the
len numbers are different.  So I'm wondering, why would pc partmap detection
be different if the apple partmap was searched first?

   -- Chris

-- 

Chris Knadle
address@hidden