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
_______________________________________________
parted-devel mailing list
parted-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
