After getting neofetch to run on 386 and 486 based computers, I wanted to try and use an even older machine. I have two older VAX computers in my collection. One is a heavily upgraded MicroVAX 3600 (that I use to print my calendar), the other a MicroVAX II. There is a significant speed difference between the two, and the MicroVAX II doesn't have a working HDD, so I thought I'd better start with the 3600. As result of its upgrades, it has 2 QBUS SCSI controllers. It also has 3 internal HDDs on one controller, while the other has an external standard SCSI connector. By the way, none of the controllers from the MicroVAX 3600 would fit the MicroVAX II, one for electrical reasons, the other for mechanical ones. Long story.
I don't want to erase the internal drives of the MicroVAX 3600 but I have a huge (in size; around 300MB capacity) external SCSI HDD, also from DIGITAL. That one can easily be imaged to a file using a modern computer (a crude but fast form of backup&restore). That leaves me with a free HDD on which to install NetBSD.
I know that this VAX is capable of booting from SCSI CD-ROM but it requires a particular type of drive that I don't have at hand. Another option - that doesn't seem very difficult - is netbooting. Yes, these old computers were capable of netbooting all by themselves. Of course, it's not PXE, but a proprietary protocol by DEC, called MOP (Maintenance Operations Protocol). This protocol would also allow for things like remote console over Ethernet, but I'm only interested in booting. mopd is not included in Slackware, nor is it available at SlackBuilds but there are sources at https://github.com/qu1j0t3/mopd.
Next hop: A small documentation error that took a while to untangle. Following the instructions at http://www.NetBSD.org/docs/network/netboot/mop.html:
Next, NetBSD boot expects to read the kernel from NFS, not from TFTP. Edit /etc/exports, add a directory for that purpose (/export/micro), copy install.ram.gz there (as netbsd.vax since that's what it was trying to read), then start nfsd (on Slackware /etc/rc.d/rc.nfsd needs to be chmod-ed +x). Once everything is in place NetBSD boots and not much later sysinst displays the first screen.
English, install NetBSD to a hard disk, continue, I looked carefully to make sure I will install to the right HDD (ra3, fourth one), Full installation, Set sizes of NetBSD partitions, 283MB for root partition, 32MB swap. Continue. Progress bar (recommended). Install from FTP, configure network, server (on local network) and let's proceed. Everything runs fine (at around 300KB/s transfer rate) until.. it no longer does. System seems to be hanged but it responds to ping (so kernel and network are still running). The external HDD LED remains lit (that seems to indicate a SCSI error). One more attempt offers a similar result, however it hangs at a different point in transfer.
Thinking a newer BSD might eventually help, I go for 7, but first attempt (using boot.mop from 1.5.3) quickly gets into a loop (I switched from the VT-220 terminal to my regular machine running screen in order to log what's happening):
>> NetBSD/vax boot [Jan 6 2002 22:13:30] << >> Press any key to abort autoboot 0 Trying BOOTP Using IP address: 192.168.13.171 myip: vaxnetbsd.local (192.168.13.171) root addr=192.168.13.1 path=/export/client/root 3733560stray interrupt: vector 0x18, ipl 31 stray interrupt: vector 0x18, ipl 31 stray interrupt: vector 0x18, ipl 31 stray interrupt: vector 0x18, ipl 31 ...ad infinitumThe same happens on SIMH. I fire up a NetBSD machine, mopcopy VAX boot and install.ram.gz from 8.0 (why not?), copy the result to my Linux machine and try again. This time it loads the kernel but then panics right after network card detection:
3840592+134052=0x3ca8e0 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 8.0 (INSTALL) #0: Tue Jul 17 14:59:51 UTC 2018 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/vax/compile/INSTALL MicroVAX 3500/3600 total memory = 32708 KB avail memory = 27328 KB mainbus0 (root) cpu0 at mainbus0: KA650, CVAX microcode rev 2 Firmware rev 83 lance at mainbus0 not configured uba0 at mainbus0: Q22 mtc0 at uba0 csr 174500 vec 774 ipl 17 mscpbus0 at mtc0: version 2 model 14 mscpbus0: DMA burst size set to 4 uda0 at uba0 csr 172150 vec 770 ipl 17 mscpbus1 at uda0: version 5 model 13 mscpbus1: DMA burst size set to 4 qt !Turbo qe0 at uba0 csr 174440 vec 764 ipl 17: delqa, hardware address 08:00:2b:0a:eb:3d machine check 10 vap 80 istate1 6c istate2 dbe0fc80 pc ffc07403 psl 80009c45 dmaser=0x88<QBNXM,LOSTERR> qbear=0x0 dmaear=0x0 parity error: cacheing disabled memory err! panic: mchk ?06 HLT INST PC = 8000C25BThis doesn't happen on SIMH. I don't think there is an actual defect with this machine (it runs fine and I tested it with both network and disk activity under VMS just to make sure) but its configuration might be too unusual for NetBSD. I suspect the disk issue to be with that secondary controller. These SCSI controllers are not like the PC ones, i.e. they are transparent as far as the OS is concerned. The OS doesn't know it's not using a typical MSCP (Mass Storage Control Protocol) unit. All the SCSI processing is done in the controller's firmware, however, the MSCP it implements might be subtly different from what NetBSD expects. After all, we're talking about a time when NetBSD was more than 10 years into the future. However, the two controllers are different, one is Emulex UC08, the other is CMD Technology CQD-223, the CQD-223 is the one I've tried. But for the moment I have another idea.
Why not try diskless NetBSD? Since I already know NFS works, how hard could it be? (Yes, I know it's not a good question to ask rhetorically). I started light, with the same NetBSD 3, but instead of following instructions carefully, I skipped some steps (crucially I set rc.configured=YES in /etc/rc.conf and forgot to MAKEDEV). And I also forgot to create dev/console beforehand. Oops! A "mknod /export/uvaxii/root/dev/console c 0 0" on the server and a reset (of the MicroVAX) solved this last one and after a while I got the login prompt. The only trouble was that, despite answering vt220 (or even vt100) at login, it didn't like my terminal and vi would not work. However, entering tset vt100 seems to solve the issue. Good enough for now.
Having the real thing up and running, I start another instance of NetBSD 3 on SIMH/VAX to compile bash (the emulated one, without NFS, is much faster). Transfer the binary to the exported filesystem and check that it's running, then...
While I'm rather pleased with the above, I really would like a full run with all the information. I try to mount /proc (and /kern) thinking that maybe it would help, but no. In fact /proc doesn't look to have anything in it besides process information.
Next attempt is NetBSD 7.1.1. Quite a huge leap, I know, but I have it available on a PC machine and I want to try cross-compiling a custom kernel - and in the process I discover that it's surprisingly easy to cross-compile NetBSD. I configure the kernel for this machine (I should have tried the same for the MicroVAX 3600 -- maybe later) and start the build. In the meantime I start the diskless install for 7.1.1, meaning:
# mkdir -p /export/uvaxii/root/dev # cd /export/uvaxii/ # mkdir usr # mkdir home # cd root/ # for i in ~hawk/netbsd7/sets/*.tgz ; do tar --numeric-owner -xvpzf $i ; done # mv usr/* ../usr/ # mknod dev/console c 0 0 # mkdir kern # mkdir home # mkdir swap # dd if=/dev/zero of=../swap bs=4k count=4k # chmod 0700 ../swap # cat - >etc/ifconfig.qe0 inet 192.168.13.36 netmask 255.255.255.0 broadcast 192.168.13.255 ^D # cat - >etc/fstab #/etc/fstab hgw:/export/uvaxii/swap none swap sw,nfsmntpt=/swap hgw:/export/uvaxii/root / nfs rw 0 0 hgw:/export/uvaxii/usr /usr nfs rw 0 0 hgw:/export/uvaxii/home /home nfs rw 0 0 ^D
I don't know if etc/ifconfig.qe0 is really needed but it can't hurt. Then add to etc/rc.conf:
# from NetBSD instructions hostname="uvaxii" defaultroute="192.168.13.1" nfs_client=YES auto_ifconfig=NO net_interfaces="" # more defaults that I want to override raidframe=NO cgd=NO quota=NO ntpdate=YES postfix=NO fccache=NO
and to etc/hosts:
192.168.13.1 hgw.local hgw 192.168.13.36 uvaxii.local uvaxii
On the server side, add to /etc/exports:
# for diskless MicroVAX II /export/uvaxii/root 192.168.13.36(rw,no_root_squash,no_subtree_check) /export/uvaxii/swap 192.168.13.36(rw,no_root_squash,no_subtree_check) /export/uvaxii/usr 192.168.13.36(rw,no_root_squash,no_subtree_check) /export/uvaxii/home 192.168.13.36(rw,no_root_squash,no_subtree_check)
In fact usr and home should not need "no_root_squash" except that I need to install a binary package (bash) and after that, add a regular user and configure its home directory. Next is /etc/dhcpd.conf on the server:
host uvaxii.local { hardware ethernet 08:00:2b:06:17:c2; fixed-address 192.168.13.36; always-reply-rfc1048 true; always-broadcast true; option root-path "/export/uvaxii/root"; }
Restart nfsd and dhcpd. I then configure SIMH to use the same hardware address as the MicroVAX II in order to finish the installation quicker (MAKEDEV, install bash) then boot it. Oops, wrong kernel (I really meant it when compiling just for the MicroVAX II, SIMH emulating a Microvax 3900 halts). Try again with generic kernel. This time... no
>>>b xqa0 (BOOT/R5:0 XQA0 2.. -XQA0 1..0.. >> NetBSD/vax boot [1.12 (Tue Jul 17 14:59:51 UTC 2018)] << >> Press any key to abort autoboot 4 Press '?' for help > boot netbsd.generic Trying BOOTP Using IP address: 192.168.13.36 myip: uvaxii.local (192.168.13.36) root addr=192.168.13.1 path=/export/uvaxii/root 3101284+172988 [230096+220228]=0x38d948 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.1.1 (GENERIC.201712222334Z) MicroVAX 3800/3900 total memory = 65468 KB avail memory = 59216 KB kern.module.path=/stand/vax/7.1/modules mainbus0 (root) cpu0 at mainbus0: KA655, CVAX microcode rev 6 Firmware rev 83 lance at mainbus0 not configured uba0 at mainbus0: Q22 dz1 at uba0 csr 160100 vec 304 ipl 17 mtc0 at uba0 csr 174500 vec 774 ipl 17 mscpbus0 at mtc0: version 5 model 3 mscpbus0: DMA burst size set to 4 uda0 at uba0 csr 172150 vec 770 ipl 17 mscpbus1 at uda0: version 3 model 3 mscpbus1: DMA burst size set to 4 qt0 at uba0 csr 174440 vec 764 ipl 17 qt0: delqa-plus in Turbo mode, hardware address 08:00:2b:06:17:c2 mt0 at mscpbus0 drive 0: TK50 mt1 at mscpbus0 drive 1: TK50 mt2 at mscpbus0 drive 2: TK50 mt3 at mscpbus0 drive 3: TK50 ra0 at mscpbus1 drive 0: RA92 ra1 at mscpbus1 drive 1: RA92 ra2 at mscpbus1 drive 2: RA92 ra3 at mscpbus1 drive 3: RA92 ra0: size 2940951 sectors ra1label: 70fc : no disk label: size 2940951 sectors ra2: attempt to bring on line failed: unit offline (not mounted) (code 3, subcode 1) ra3: attempt to bring on line failed: unit offline (not mounted) (code 3, subcode 1) boot device: qt0 root on qt0 nfs_boot: trying DHCP/BOOTP nfs_boot: timeout... nfs_boot: timeout... nfs_boot: timeout... nfs_boot: trying RARP (and RPC/bootparam) revarp failed, error=51 Supported file systems: union umap tmpfs ptyfs procfs overlay null nfs mfs lfs kernfs ffs fdesc cd9660 no file system for qt0 cannot mount root, error = 79 root device (default qt0):
Right, SIMH is emulating a different network card and that gets a different device name. Maybe copying etc/ifconfig.qe0 to etc/ifconfig.qt0 would help? No. tcpdump reveals that the DHCP server responds but for some reason NetBSD doesn't get the answer. After much head-scratching and experiments I notice that the real MicroVAX 3600 (with a regular DELQA card, qe0) works (to be investigated, why doesn't it panic?).
Fortunately, I also realize that SIMH supports setting the network card as DELQA (set xq mac=08-00-2b-06-17-c2 type=delqa in vax.ini) and with this, it boots:
... boot device: qe0 root on qe0 nfs_boot: trying DHCP/BOOTP nfs_boot: DHCP next-server: 192.168.13.1 nfs_boot: my_name=uvaxii.local nfs_boot: my_domain=local nfs_boot: my_addr=192.168.13.36 nfs_boot: my_mask=255.255.255.0 nfs_boot: gateway=192.168.13.1 root on 192.168.13.1:/export/uvaxii/root root file system type: nfs /etc/rc.conf is not configured. Multiuser boot aborted. Enter pathname of shell or RETURN for /bin/sh: We recommend that you create a non-root account and use su(1) for root access. uvaxii# mount /usr uvaxii# cd /dev uvaxii# /bin/sh MAKEDEV all uvaxii# cd / uvaxii# swapctl -A swapctl: adding hgw:/export/uvaxii/swap as swap device at priority 0
MAKEDEV took a while even on the faster SIMH. exit in order to get a new sh that would ask for a terminal, edit /etc/rc.conf and set rc.configured=YES then proceed with multiuser. Download bash binary package from pkgsrc and copy it to the exported filesystem, then
pkg_add bash-4.3.039.tgzThis is when I realized the problem with root_squash for usr. Make the appropriate changes to exports, restart and finally install bash.
useradd -m -s /usr/pkg/bin/bash hawkThen I make a mistake. I add a password to user hawk. The reason is that I want to be able to telnet into this machine (by enabling telnet in /etc/intetd.conf, with -a off for "insecure" access). However, telnet doesn't work. Everything else works though - on SIMH. A test run of logging in as hawk followed by running neofetch succeeds. Time to move on to real hardware.
Some minutes after power-on I get a login prompt. Enter hawk, wait, wait some more, a password prompt appears, enter the password and then... nothing. Oops. login timed out after 300 seconds. Maybe I didn't press ENTER? Try again. Same. I assume it has something to do with newer password encryption (that is taking too long on a 5MHz CPU). Luckily root is passwordless. Indeed, login as root works, su - hawk, ./neofetch
neofetch done, I'm going back to NetBSD 3 for a little slacking. Not in the Slackware sense, true, but nevertheless...