Scott,

After looking at the sources I can now see what is going wrong.   Sorry -
I missed the part where it also occurs on physical disks when I read your
message earlier.

The disklabel code has 2 difference behavours depending on the use of the
-r flag...

With -r (Use raw device behavour):

  1)  Kernel disk label is updated using DIOCSDINFO ioctl "Set Disklabel"
  1a) Kernel disklabel updated and setdisklabel() is called

  2)  NetBSD Disk label is written by the disklabel application  using
      write() system call to the label sector (Sector 1 for sgimips) only.

  3)  Mips Volume Header sector (Sector 0) is not touched.
      - vgivol fails as a result

Without -r (Use block device behavour):

  1)  Kernel disk label is updated using DIOCWDINFO ioctl "Set+Update
      Disklabel"
  1a) Kernel disklabel updated and setdisklabel() is called
  1b) Kernel as an extra step to DIOCWDINFO ioctl calls writedisklabel()
  1c)   NetBSD disklabel is converted
  1d    Mips Volume Header is created and written to sector 0

  2)  Mips Volume header was updated
      - vgivol works as expected

On other platforms the installboot utility will perform the platform
specific label writing as part of installing the bootstrap.
However, refering to the disklabel source, the sparc architecture has
an exception in the disklabel utility that disables the "raw" access
method - hence it causes the kernel to write both the Solaris and NetBSD
disklabels.

After doing some tests it seems you need a "sgivol -i" step in addition to
the disklabel to make the volume header consistant.   The folowing steps
are required:

  disklabel -wr -f /root/disktab.ramdisk vnd0  install-ramdisk
  sgivol -i vnd0
  sgivol -wf boot /usr/mdec/boot vnd0

The interactive nature of sgivol is counter-productive when building a
mini-root using the automated process - no doubt you have disabled that
feature in your locally mod'ed version you refer to.

Hope this explains what is happening under-the-hood.

Wayne



On Mon, 12 Nov 2001, Scott G. Akmentins-Taylor wrote:

> Wayne Knowles <wdk@netbsd.org> wrote:
>
> > Is the problem specific to vnode disk devices??  If so what type of
> > filsystem holds the vnd image (ufs/nfs)??
> > You could try swapping between NFS and UFS to see if it isolates the
> > problem.
> >
>
> As mentioned in the original email, real disk devices also exhibit
> the same problem.
>
> Thanks and regards,
> -scott
>
> >
> > On Mon, 12 Nov 2001, sgimips NetBSD list wrote:
> >
> > > Hi,
> > > I've been noticing that "disklabel -rw" does not create the
> > > SGI VH label, whereas "disklabel -w" does.
> > >
> > > Is this an error or a feature?
> > >
> > > For my work on the sysinst, ramdisk, miniroot, bootable CD, etc,
> > > for the sgimips platform, I've been relying on disklabel's
> > > apparent functionality of generating the SGI vh label record,
> > > however when the "-r" flag is utilised, it is apparently not
> > > generating it.  This seems inconsistant with the "-r" intent.
> > >
> > > The example below is operating upon a vnd device, but the results
> > > are the same for real disk devices.
> > >
> > > NetBSD sources were cvs'd and built on 2001/11/11.
> >
> > --
> > Wayne Knowles			NetBSD/mipsco port maintainer
> > wdk@netbsd.org			http://www.netbsd.org
> >
> >
>

-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org