gpart on top of eli inside a slice is not working

[Bjoern A. Zeeb]

On Thu, 26 Mar 2009, Marcel Moolenaar wrote:

Hi,

>>> The bug is in the create method: GPT cannot be created inside a
>>> MBR slice (or any other partioning for that matter). I'll fix
>>> that shortly.
>> 
>> Well technically it is created inside some random garbage from eli and
>> not directly inside the MBR slice.
>
> When I refer to nesting, I mean the on-disk layout. It's almost
> meaningless to talk in terms of GEOM nesting, because you can't
> assume anything.
>
> Thus: the fact that geli is in between the two gpart instances is
> irrelevant.

ok.


>> So the only possible solutions for those would be:
>> 1) Somehow convert the entire disk to part and then exposing the 3
>>   freebsd-* partitions and have a dedicated eli inside each.
>
> I don't understand what you're trying to say. Can you
> elaborate?

Well if you convert the entire thing to GPT (not part; still wrongly
using it as a synonym 'cause of the old gpt(8) name and being
confuse;-) ) you'd have

 	md0p1	Compaq Recovery	(however this would work)
 	md0p2	NTFS	(however this would work)
 	md0p3	freebsd-ufs
 	md0p4	freebsd-swap
 	md0p5	freebsd-ufs

and then you would do
 	md0p3.eli
 	md0p4.eli
 	md0p5.eli

In this case the "freebsd-*" is publicly exposed in GPT.


But in contrast, with the fdisk version, where slice 3 is "DOS"

 	md0s1	"Compaq Recovery"
 	md0s2	"NTFS"
 	md0s3	"DOS"
 	md0s3.eli	random garbage
 	md0s3.elia	equivalent to md0p3
 	md0s3.elib	equivalent to md0p4
 	md0s3.elid	equivalent to md0p5

the freebsd parts are not publicly visible.


>> 2) try (and stick with) bsdlabel on top of the eli inside the mbr
>>   slice?
>
> A different scheme, one that is allowed to be nested (again, from
> an on-disk layout PoV), is the right thing to do.

I went with gpart + BSD for now.


>> So can you explain why there is the restriction that part cannot be
>> used inside a MBR slice or rather somewhere on top of such?
>
> There's no such restriction in gpart. If there was, then gpart
> would not be able to implement the BSD scheme or the EBR scheme.

So again here, s,part,GPT, ;-)  What is the EBR scheme? Are the
schemes somewhere documented in more detail?
Well they are someway but perhaps gpart(8)[?] could talk a bit more
what a "scheme" is and what the affiliation to the geom classes
and options.



So I have to say I much more liked gpart to create the traditional BSD
disklabels than the old bsdlabel. Things can be scripted more eassily
etc.

Two things would significantly improve usability though are
1 ability to give -s size in human readable way instead of having to
   do all the math.
2 be able to give -b start to just say "start at next free offset" w/o
   looking it up or doing the math.

Example: gpart add -b next -s 64G -t freebsd-ufs da3


/bz

-- 
Bjoern A. Zeeb                      The greatest risk is not taking one.