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