Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!comp.vuw.ac.nz!beta.isor.vuw.ac.nz!jonathan
From: jonathan@beta.isor.vuw.ac.nz (Jonathan Stone)
Newsgroups: comp.bugs.4bsd
Subject: Problems in from-scratch install of 4.3BSD-Reno on Microvax
Message-ID: <1991Jun18.011643.13473@comp.vuw.ac.nz>
Date: 18 Jun 91 01:16:43 GMT
Sender: news@comp.vuw.ac.nz (News Admin)
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.
Lines: 136
Nntp-Posting-Host: beta.isor.vuw.ac.nz


Subject: Problems in from-scratch install of 4.3BSD-Reno on Microvax
Index:	/sys/vaxdist/get

Summary:
	Earlier this year I installed 4.3BSD-Reno on a Microvax-II/RC
        (rqdx3, rd53, qvss, delqa, tk50).   The rd53 was newly formatted.
	Having neither	4.3BSD-Tahoe, nor a bootable 4.3-BSD with
        patches for Microvax support, I opted to attempt installing 4.3-Reno
	from scratch, rather than upgrading a running 4.3 or 4.3-Tahoe
	system. This was, um, challenging.   I encountered five distinct
	problems, which are detailed below, with workarounds.
	Briefly, the problems are:

	* The standalone software and kernel do not agree about
	  what the console tty is. They use both the QVSS and the
	  console serial port as the console at various times.
	  This is most confusing for the installer.

	* The 4.3-Reno vax miniroot kernel and generic vax kernel
	  panic when booted from an unlabelled rd53 disk.
	  There is no standalone disk labeller.

	*  There is no special device file on the miniroot for a
	   tmscp tape. Making one is hard, since the miniroot is read-only.


Repeat-By:
	Build a bootable tk50 by dd'ing /sys/mdec/tmscpboot and
	a tp archive of standalone programs onto a tk50.
	Write the 4.3BSD-Reno miniroot image to the end of the tk50.
	Write the 4.3BSD-Reno root filesystem and /usr dump onto the tk50.
	Attempt to install 4.3BSD-Reno from scratch using this tk50,
	the installation documents for 4.3-Reno and 4.3-Tahoe.

	(If this isn't clear, see Rick Lindsley's March 1988 message
	 "4.3 does not run on a uVax +FIX" to comp.bugs.4bsd)

Problem #1:
        When initialising the KA630 (e.g., after pressing the Restart
	button, or cycling power) the boot ROM performs console tty
	i/o to the qvss in `glass tty ' mode.
	The tape monitor can  be booted using the command
		>>> BOOT MUA0
	(again, using the lk201/qvss console).
 	The tape monitor (which load standalone boot, copy, restore)
	is loaded by tmscpboot, and proceeds to send console I/O
	to the serial port.  That is, one sees a "=" prompt on the
	serial console.  The commands to load standalone programs
	must be given through the serial console.
	Once loaded, the standalone boot programs themselves do
	console I/O to the graphics screen in glass-tty mode.

	This behaviour may be normal for BSD systems, but is
	confusing for naive system administrators used to the VMS
	convention of using the graphics console even when standalone.

Workaround:
	Be sure to attach a serial console close to the qvss screen.
	Look there for the "=" prompt. Type the boot and copy commands there.

	-------

Problem #2:
	The 4.3-Reno generic miniroot _prompts_ for the location of
	the root filesystem on the graphics console, but _reads_ the
	location from the serial console. This is most confusing;
        it is easy to conclude that the kernel has hung.


Workaround:
	Remember to type the location of the miniroot to the serial
	console port, despite the prompt being written on the qvss!

	-------

Problem #3:
	Both the miniroot and generic root panic when loaded off an
    	unlabelled rd53 disk. (Since a panic  clears the  qvss
	console, it is hard to determine where this panic occurs.
	It seems to be within swfree(), attempting to free a free block.)

Workaround:
	Use dd on a running 4.3-Reno system to copy a label from a suitably
	labelled disk onto tk50.  (I used "dd bs=16b count=1 conv=sync").
	On the target system, use standalone copy to copy the label from tape
	onto the unlabelled disk that will hold the miniroot.
	Install the miniroot again.

	-------

Problem #4:
	There is no special device file for tmscp tapes, though the
	miniroot does include a TMSCP driver.  Extracting the root
	filesystem is therefore challenging.

Workaround:
	newfs a spare partition (e.g, the eventual home of /usr; see below),
	mount it read-write (e.g., on /tmp), and make a special node there.
		newfs /dev/rra0g
		mount /dev/rra0g /a
		mknod c 38 0 /a/tmscp
Fix:
	Patch /sys/vaxdist/get to make a special file on the miniroot,
	and re-build the miniroot.  The following is untested, but
	should work for a tk50.  Additional minor devices may be appropriate
	for a tk70.

*** /sys/vaxdist/get	Fri Jul  6 06:57:23 1990
--- /tmp/get	Mon Jun 17 09:36:32 1991
***************
*** 130,135 ****
--- 130,136 ----
  ./MAKEDEV tm0; mv rmt12 tm0; rm *mt*;
  ./MAKEDEV ht0; mv rmt12 ht0; rm *mt*;
  ./MAKEDEV ut0; mv rmt12 ut0; rm *mt*;
+ ./MAKEDEV tms0; mv rmt12 tms0; rm *mt*;
  ./MAKEDEV mt0; mv rmt12 xt0; rm *mt*; mv xt0 mt0
  cd ..
  sync

	-------

Problem #5:
	(Old news.)  The script to extract the root filesystem won't work
	 on the read-only miniroot filesystem.   It needs to create files
	in /tmp.

Workaround:
	newfs a spare partition and mount the filesystem read-write
	on /tmp. (if using a tmscp tape, it may be convenient to
	mknod the special device on the /tmp filesystem).

Fix:
	Apply the CSRG patch (comp.sys.bugs.4bsd V1.94) to /sys/vaxdist,
	and build a new miniroot.