> After verifying the label had been written I tried the next reboot to
> get the miniroot written. The 1.2C told me that my mt device (that I'd
> booted from) wasn't there. I got fed up after a few attempts and moved
> on to 1.2G. Repeated all steps above for new TK's. The 1.2G allowed me to
> read and then appeared to write to ra(0,1,1) from mt(0,1) which 
> corresponds to MUA0:==>DUA1: if I'm not totally confused yet.  
> 
> On a reboot to execute boot from the miniroot I kept getting the message
> that the directory couldn't be found. I used all the combinations of
> netbsd, gennetbsd, /netbsd, /gennetbsd, with mt(0,1) and ra(0,1,1) in an
> attempt to boot from either the miniroot on partition b or the tape
> miniroot. Nothing but the "can't find" message. I rewrote the tape on a
> different tape using the process as above but still the same result. 

Your difficulties sound strangely similar to the problems that Kevin
McQuiggin and I had when we tried to install 1.2G onto his system
(KA630+13 Mbytes+QD21+2 ESDI drives).

We booted a working pre-1.2G system that Kevin had installed on ra0
sometime in the past.  From this system, we used "disklabel" to
create partitions ra1a, ra1b, and ra1c.  Restarting the system and
reading the disklabel on ra1, we were confident that the disklabel
had indeed been written to ra1, and that it was set up like we wanted
for the install.

We then used 'dd' to move the 1.2G miniroot onto ra1b.  We shut down,
did a B/1 DUA0:, and then told it to load the minikernel from
'ra(0,1,1)netbsd'.  This worked quite nicely, and we succesfully
started up the 1.2G miniroot.

Now the problems began.  If, while running the 1.2G miniroot from
ra1, we attempt to read the disklabels on "ra0" and "ra1", we
discover that the disklabel on ra0 looks fine, but the disklabel from
ra1 does not correspond to what we put on it.  "disklabel -r" (telling
it to read the label directly from the disk instead of using the
in-core copy) doesn't help either.  What "disklabel" reports as being
on ra1 isn't pure nonsense - it appears that at some point the MSCP
device size was correctly autoprobed, but there are only two partitions,
"a" and "c", neither of which correspond to what we labeled ra1 with.

We tried swapping ra1 and ra0, thinking that perhaps the miniroot
was too stupid to deal with more than one disk device, but this didn't
help.  Now, while running 1.2G from ra0, the ra0 disklabel is scrambled,
but the ra1 disklabel looks fine.

Booting up Kevin's old version of NetBSD and running "disklabel -r" from
it, we see that the disk labels on the two disks are both what we wanted
them to be, and they had not gotten physically mangled while trying to
run 1.2G.

The lack of proper labeling on the system disk while running 1.2G prevented
us from doing anything meaningful to the "a" or "c" partitions.  In
particular, we were absolutely unable to write a filesystem on either
partition from 1.2G.

Is there something we were doing wrong?  Or is there a known problem
with the disklabeling on a 1.2G system disk?

Tim. (shoppa@triumf.ca)