cdob, on 07 Aug 2015 - 05:46 AM, said:
Well, it's a bug or feature currently.
Grub4dos does map the GPT partition (hd0,0) to a MBR parition entry (hd0,0).
Bootmgr does find \boot\bcd at virtually MBR disk.
This works well at current grub4dos.
The readme describes
map --in-situ (hd0,4)+1 (hd0)
In my experience this dosn't map to (hd0), but to (hd0,0) always. That's fine for the documented win9x example.
I wonder can --in-situ be expanded?:
given a GPT disk with four partitions.
Request: map the GPT partition to a MBR partition entry.
map --read-only --in-situ (hd0,0)+1 (hd0,0)
map --read-only --in-situ (hd0,1)+1 (hd0,1)
map --read-only --in-situ (hd0,2)+1 (hd0,2)
map --read-only --in-situ (hd0,3)+1 (hd0,3)
As known, the --in-situ switch only virtualize the partition table(and some BPB fields of PBR). It is possible to modify the code and support partition numbers 1, 2, and 3.
EDIT: Just took a look at this code:
else if (grub_memcmp (arg, "--in-situ=", 10) == 0)
{ unsigned long long tmp; p = arg + 10;
if (! safe_parse_maxint (&p, &tmp))
return 0;
in_situ_flags = (unsigned char)tmp;
in_situ = 1;
}
and see there is an undocumented --in-situ=FLAG usage. Although it was designed by me, sorry, I simply cannot remember what it really does. I will try and find it out again.
EDIT 2: Just find out the flag is used to empty the other 3 partition entries, which is of no use.
EDIT 3: Mappings always create virtual drives, not virtual partitions. BIOS (int13)knows drive numbers, but it does not know of partitions on a drive, and it has no interface/API for the user to access partitions on a drive. So "virtual partitions" is meaningless (at this moment); and we always create virtual drives, possibly with a virtual partition table(in the case of --in-situ). Consequently, if we try to map two or more partitions/files to the same drive number, like this:
map --in-situ (hd0,4)+1 (hd0)
map --in-situ (hd0,5)+1 (hd0)
map --in-situ (hd0,6)+1 (hd0)
then only the last one will work.
Finally, look at this:
map --in-situ (hd0,0)+1 (hd0,0)
map --in-situ (hd0,1)+1 (hd0,1)
map --in-situ (hd0,2)+1 (hd0,2)
map --in-situ (hd0,3)+1 (hd0,3)
It is acceptable, but the "virtual partition number" is discarded, thus it is equivalent to this:
map --in-situ (hd0,0)+1 (hd0)
map --in-situ (hd0,1)+1 (hd0)
map --in-situ (hd0,2)+1 (hd0)
map --in-situ (hd0,3)+1 (hd0)
And so only the last one (of the 4 maps) will take effect.
EDIT 4: It is possible to improve the mappings to support a user-defined (virtual)MBR, conceptually like this:
map --in-situ --customized-mbr (hd0,0)/somewhere/a-512-byte-sector-file (hd0)
But this needs further development. (Anyone really needs this?)