Subject: Re: make release failure with vn/disklabel
To: None <netbsd@mrynet.com>
From: None <Havard.Eidnes@runit.sintef.no>
List: port-sparc
Date: 01/01/2000 20:53:04
> Since I'm in the middle of a release build, I haven't been able to
> sup for two days.  Nonetheless, the following has just occured at
> end of a LONG release build (slow machine):
>
> dd if=3D/dev/zero of=3Dramdisk.fs count=3D4096
> 4096+0 records in
> 4096+0 records out
> 2097152 bytes transferred in 4 secs (524288 bytes/sec)
> vnconfig -v -c /dev/vnd0c ramdisk.fs
> /dev/vnd0c: 2097152 bytes on ramdisk.fs
> newfs -B le -m 0 -o space -i 5120 /dev/rvnd0a
> /dev/rvnd0a:    4096 sectors in 2 cylinders of 64 tracks, 32 sectors
>         2.0MB in 1 cyl groups (16 c/g, 16.00MB/g, 448 i/g)
> super-block backups (for fsck -b #) at:
>  32,
> newfs: ioctl (WDINFO): No such process
> newfs: /dev/rvnd0a: can't rewrite disk label
> *** Error code 1
>
> If someone knows about this, please let me know.  Otherwise, I can
> investigate with some direction given if anyone has any ideas for
> me.

Some platforms apparently prevent you from touching the disk label
area of any device if you are running in a "secure" mode (i.e.
kern.securelevel is 1 or higher).  I suspect you are running with
kern.securelevel set to 1 (I seem to recall that being the default)?

The man page init(8) has this to say on level 1:

     1     Secure mode - system immutable and system append-only
           flags may not be turned off; disks for mounted
           filesystems, /dev/mem, and /dev/kmem are read-only.

It doesn't say anything architecture-specific on disk label areas,
and the file system being created above obviously isn't mounted...

I can't remember seeing this problem on i386, but my recent
1.4.2_ALPHA snapshot build on the sparc platform bumped into this
problem there as well.  (There are probably some architecture
differences in how installboot does its thing (?), which may explain
parts of this (?), or my memory as to the kern.securelevel I use on
my i386 may also be playing tricks on me...)

The cure is to boot with kern.securelevel set to a lower value, 0
should be sufficient to let the build proceed.  See init(8) for
further information on the kernel security level.


- H=E5vard