At 17:40 Uhr +0100 24.01.1999, Bob Nestor wrote:
>Frederick Bruckman <fb@enteract.com> wrote:
>
>>On Mon, 25 Jan 1999, Guy Santiglia wrote:
>>
>>> I want to try and add
>>> a /var file system on my internal 258 meg drive.
>>:
>>:
>>> 7 partitions:
>>> #        size   offset    fstype   [fsize bsize   cpg]
>>>   a:       32      144     unknown                        # (Cyl.
>>>0*- 0*)
>>>   b:   268630   260176         HFS                        # (Cyl. 1355*-
>>2754*)
>>>   c:   528808        0      unused        0     0         # (Cyl.    0 -
>>2754*)
>>>   d:        2   528806     unknown                        # (Cyl. 2754*-
>>2754*)
>>>   g:   260000      176      4.2BSD        1024     4096     16   #
>>>(Cyl.
>>0*- 1355*)
>>>
>>> Here is the disklabel when I get this "no disklabel-- NetBSD or Macintosh"
>>> message on the screen.
>>
>I think this is where the problem lies.  This is the message you get when
>you try to write a disklabel in the mac68k port since disklabels aren't
>fully supported.

This is the message you get when you touch a disk for the forst time and it
does neither contain a valid MacOS partition table nor a valid BSD
disklabel (a rather academic case for MacBSD). I see those with floppy disk
accesses all the time.

-- Guy , what formatter did you use for formatting & partitioning the disk?
The funny thing is: The NetBSD partition table looks sane.

>So I suspect what is displayed is just the incore
>version of the disklabel, not the one created by scanning the Disk
>Partition Map when the system was booted.

Those two are the same.  =8)
If you have an in-core disklabel, it is created from the MacOS partition
table, and only from it, on MacBSD - at least until we have genuine BSD
disklabel support.

The interesting question is: Why does the kernel claim the lack of a
"Macintosh" disklabel (i.e. an invalid MacOS partition table!) and _still_
proceed to set up an in-core disklabel from it?!

>Also if the proper partition
>flags are not written in the Disk Map Entry, NetBSD won't see the
>partition as a BSD type when it builds the incore disklabel.

Quite so, but a look at the listed disklabel will tell you that the kernel
has identified partition "g" as a valid BSD filesystem.

>>> And the "newfs /dev/sd0g" command gives ne this message:
>>> " device not configured.

Did it proceed, i.e. list a number of alternate superblocks, or did it stop
there?

	hauke


--
"It's never straight up and down"     (DEVO)