> > Has anyone done a from scratch install of 1.3_ALPHA to a
> > MicroVAX II yet?  I plan on doing one myself, unless others
> > have run into problems.
>
> My office mate and me just tried and failed doing an install from
> scratch on a MicroVAX/III (3500) from RX50 diskettes.  A PR is
> forthcoming about that.

Well, the PR went in and Anders Magnusson kindly made a fixed set of
RX50s available to us, and the version of standalone copy on that
diskette worked Just Fine.  The fix for this problem has been
committed to the main source tree and a pull-up to the 1.3 release
branch has been requested, but I have so far not seen it being
pulled up yet (I try to follow what goes on on the source-changes
mailing list).

There was another problem with /dev not being populated in the
diskette miniroot (not sure what caused that, as the build tools
apparently do call MAKEDEV).  Here we also got new versions of the
miniroot RX50 images from Anders Magnusson -- thanks!

BTW, we wrote our RX50 diskettes on a PC using the PUTR.COM program
mentioned earlier on this list, the resulting diskettes worked just
fine on our system.


Our 3500 which in its former life used to run VMS now runs NetBSD
1.3_ALPHA, and the recent slaughtering of a 3900 system in the
neighbourhood brought our 3500's memory configuration up from 16M to
32M.  (Unfortunately, the 3900 CPU module was broken, otherwise we
would have had one more VUP on our system by now...)


There were apparently a couple of minor glitches in the currently
available 1.3_ALPHA snapshot, but they seemed to go away once we
recompiled the offending programs.  The ones we found which were of
this nature were:

 o sed didn't want to read files,
	% sed -e '$r /etc/myname' </dev/null
   emitted nothing.  Recompilation of sed fixed it.

 o g++ didn't want to compile libg++, recompiling g++ fixed it
   (actually we rebuilt all of gcc).

The recompiles were done after we uploaded source code with SUP,
so these buglets may have been fixed between Anders starting
compiling the snapshot and when we updated our sources.

There are a couple of other problems in the sources we have, e.g.
lint didn't want to build the lint library corresponding to the C
library, but I think that's an architecture-independent problem, and
there seems to have been some work done on that front recently.

One other oddity we've noticed is that the "make" process grows
really huge when compiling the C library; we've seen it grow to
something like 18MB (!) on the VAX, whilc on our i386 systems it
"only" grows to 9MB or thereabout.  This is probably also an
architecture-independent problem, but I would guess it impacts the
typical NetBSD/VAX installation more than the typical modern
i386-type PC...

> I also have a nagging but unconfirmed suspicion that the problem
> documented in PR port-hp300/4071 is also affecting the VAX port.

This, luckily, turned out to be false.  I admit I don't fully
understand why, but apparently there are machine-dependent
differences in how e.g. the disk labels are handled.


- H=E5vard