Re: missing ad0p2 device while GEOM sees GPT

On Oct 11, 2004, at 2:10 PM, Emanuel Strobl wrote:

> Am Montag, 11. Oktober 2004 19:03 schrieb Marcel Moolenaar:
> [...]
>>> But when I try it fails becaus there also is no /dev/ad0p at all.
>>
>> Odd. I'll see if I can reproduce this. In the mean time, see if md(4)
>> exhibits the same behaviour.
>>
>>> Btw, it's a i386 box, not ia64.
>>
>> I know. :-)
>
> Nice :) I have news, please let me know if I'm doing things the right 
> way. Now
> I set up a standard MBR with one standard slice and standard labels 
> inside.
> Then I issued 'gpt migrate -k -s ad0' and now I have a booting box and 
> could
> add ('gpt add -b ??????? -s 2000000 -i 3 -t ufs ad0') a third GPT part 
> of
> type ufs.

Ok. No obvious bogons here.

> After a reboot I also have the device ad0p3, but why do I need to 
> reboot?

Dunno. AFAICT you don't have to reboot at all because if GEOM allows 
you to
create a new partition/slice, it'll create the device nodes right away. 
You
might want to sync(8) and see if the device node shows up then. We've 
had
some latency/synchronisation issues in the past with mdconfig(8)...

> And why doesn't 'gpt show ad0' work without setting 
> kern.geom.debugflags to
> 16?

Because gpt(8) opens the device RW by default and this is not allowed by
GEOM (by default) when partitions are mounted. You can either give 
gpt(8)
the -r option for opening the disk RO, or tell GEOM to loosen up (which
is what the debugflags value does).

> And like I posted in another mail, as soon as there is a GPT on the 
> disk
> sysinstall panickes (BARF <171>, panic: Going nowhere without my 
> init!).

I saw the mail, but did not answer. The problem is libdisk. When it
encounters something in the GEOM conftxt sysctl that it doesn't expect 
it
simply barfs (<171> in this case) and bails out. Since sysinstall(8) is
the only consumer of this library, sysinstall is the only one affected.
There are a lot of bugs in libdisk like that. My advice: don't do it...

> And while I'm at sysinstall I'd liek to repeat another posting: 
> Sysinstall
> always sets the boot flag to any slice, so if you add (or define two 
> at once)
> a slice you have a invalid partition tabel (in the MBR) with two active
> flags.

File a PR?

-- 
  Marcel Moolenaar         USPA: A-39004          marcel_at_xcllnt.net