>I was thinking about doing something like that.. (or just doing it all
>by hand, that's the way it Works).
>
>I fetched the install disk images of the 990131 snapshot.  Once again, I
>had to enter the partitions (argh ;) and after that:
>
>..Shall we continue?  (yes)
>
>uid 0 on /: file system full
>
>/: write failed, file system is full
>Segmentation fault
>
>
>I can imagine what a new NetBSD user does at this point.. becomes an ex-
>NetBSD user :-I

First, this is a problem with sysinst.  The best way to discuss such
problems is to send a PR in the `install' category.  Second best is
probably current-users, since this is a -current system.  The i386
isnt the only port using sysinst, and you're not guaranteed to find
people to fix the problem here.

My first guess is that the problem is that sysinst isnt successfully
writing the BSD disklabel. (if it was, you wouldn't have to recreate
the label).  That would also explain why the disk is reporting itself
as readonly.



>..Shall we continue?  (yes)
>
>uid 0 on /: file system full
>
>/: write failed, file system is full
>Segmentation fault

sysinst is coredumping. why, I dont know, but it is.  Possibly (again)
because the BSD label hasnt been properly written to disk _and_
updated in-core. Why that would be, i have no idea; possibly bugs in
sysinst, or possibly bugs in the disklabel-writing logic.

What happens if you suspend after sysinst says it's labelled the disk,
but before  it tries to create any filesystems?  can you suspend
sysinst and try doing

	disklabel /dev/rwd0d		# read incore label
	disklabel -r /dev/rwd0d		# bypass incore, read label
					#    read direct from disk


Could it be there's no space (or no prototype file) to set up the
`fake' /etc/disktab which sysinst uses to write the label?  Do you
have an /etc/disktab -- in the ramdisk /etc, not on disk -- after the
failure?

thanks
--Jonathan