Hi,

> > 
> > I have built a root fs and kernel from NetBSD-current of about two weeks
> > ago and have it booting single user on a uvaxii, but have run into the
> > following problems:
> > 
> > - It accesses the file system read-only fine, but trashes any new files it
> >   creates. Fsck finds the inode type bad after you reboot and fsck the file
> >   system.
> Strange... that's a new problem... did you build with -O flag?
> I'm myself are only using old-fashioned filesystem type so far
> to be able to use Reno sometimes... (But probably not needed anymore)
Well, the file system is a Reno type one (although I tried "fsck -c 4" on
one of them with a NetBSD-current fsck and it didn't fix the problem). I
rebuilt the entire kernel without -O and it didn't seem to make any difference
either. (btw, I have found that the mid-winter kernels have the same
property.)

For example, boot single user and then..
# mount -u /dev/ra0a /
# cat /etc/ttys > xx	(which doesn't exist)
# cat /etc/ttys > xx
ra0a: hard error reading fsbn NNNN (..) controller error (unknown subcode)..

where the fsbn varies and sometimes it is a data error but always
(unknown subcode). Other command sequences may result in

free inode //NNN had X blocks

errors before the read errors. The same disk (RD53/RQDX3) reads fine under
Reno.
> > 
> > - Disklabel always seems to complain that the "c" partition is the wrong
> >   size (either to big or too small/offset) no matter what size you make
> >   it, including the size reported by the driver for the drive. (It currently
> >   talks to the disk, reporting it's unlabelled, but I can't seem to come
> >   up with a way to get the dang label on it.:-)
> What disk type are you using? 
I have made some progress here. With a NetBSD-current disklabel linked to
an older libc.a (see below) I can now label the disk. Once labelled, the
secondary bootstrap /boot and kernel find the label fine and are happy with
it. However, the primary boot xxboot (sectors 0-15) complains about
"corrupted disk label" unless you replace dkcksum() with one that always
returns 0 (ok). Since /boot, which uses exactly the same routine to check
the label says it is ok, it seems that xxboot must somehow corrupt it after
being read into memory?
> > 
> > - Assorted utilities segentation fault. (Since ones I had built from
> >   NetBSD-1.0 sources with vax libc support merged in from 4.4BSD-Lite are ok,
> >   I've got a hunch this one is a libc problem, but...) Since the kernel
> >   doesn't write a core dump, it's a little hard to tell what is causing them
> >   to grap out.
> This may depends on: 
> 1) Your GCC doesn't define _NetBSD_ while compiling. Some programs
> breaks then.
> 2) Your programs uses regex from libc which didn't work until a 
> couple of days ago when I found what caused the problem.
It isn't regex (cat and cp are two of the example programs). When I link to
an older libc.a (built from NetBSD-1.0 and 4.4BSD-Lite) the problem goes
away. I haven't had a chance to try and isolate what went wrong in the libc
build.

I'll keep at it, rick