On Mon, 29 Nov 2004, Marcel Moolenaar wrote: > On Mon, Nov 29, 2004 at 02:38:25PM +0100, Pawel Jakub Dawidek wrote: >> >> It is because GEOM_GPT class only allow to create GPT labels on rank#1 >> providers (i.e. disks). I'm not sure why we have this hack, maybe marcel_at_ >> knows something more (cc'ed). > > It's there, because it was there for the MBR class when I used that > class as a blueprint for implementing GPT support. Since GPT is not > allowed within an MBR slice, or within a GPT partition (no nesting), > not to mention all the non-native partitioning schemes that GEOM > supports, that test made sure we only tasted GPT partitions on the > one kind of providers that existed besides slicers: disks. > > I guess a change like geom_mbr.c:1.57 is in order, or a more to-the- > point test for rejecting GPT on MBR or GPT on GPT. Thanks for the quick responses, guys. While the great and good are considering it, I may in the meantime throw caution to the wind and see if I can make some appropriately ad hoc changes to my own system. Any suggestions before I start butchering the file in question? Maybe since I no longer need more than 7 partitions per logical volume I should go back to using bsdlabel for the time being, although that feels too much like taking the easy way out. :) Chris.Received on Tue Nov 30 2004 - 14:37:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:23 UTC