[parted-devel] [PATCH] GPT -> MBR synchronization

[H. Peter Anvin]

Alexander Graf wrote:
>>
>> I really don't want to see us hard-wire the first four, however; 
>> that's worse than anything.  I guess you end up wanting a virtual flag 
>> of some sort.
> 
> By then you'd be back at Olaf Hering's patch. I don't really like the 
> manual attachment of GPT to MBR partitions, because that'd require a lot 
> of effort in all the tools actually working with the partition table, 
> including consistency throughout them.
> 
> If you like Olaf's approach though, feel free to take his old patch, 
> help him get it upstream and try to convince everyone to use it :-). I'm 
> the last person against that - I only wanted to have something that 
> "just works" without the user having to deal with it.
> 
> For now it's the only solution that came to my mind that didn't require 
> anyone to change existing toolchains or behavior. As soon as you use a 
> GPT you'd get the MBR entries "for free". And the "the active partition 
> is within the first four partitions" restriction was there with MBR 
> already, so I believe it's acceptable for most users - at least until 
> we  go all EFI.

Actually, no.  I for one publish an MBR which lets any partition be 
active, and a lot of users use logical boot partitions.

Needing to map data partitions really suck, because it cannot be done 
reliably.  However, we can do somewhat of a priority-based scheme:

1. The bootable partition;
2. Data partitions manually (or by installer) marked such;
3. Data partitions from known problematic systems;
4. Other data partitions.

We never sync extended partitions, of course.

Syncing data partitions is fundamentally broken, but we can at least try 
to make it work in a few situations.

	-hpa