github.com/dreamlayers.netbsd-mopd
1
0
Fork 0
mirror of https://github.com/dreamlayers/netbsd-mopd.git synced 2026-01-11 23:43:12 +00:00
Code Issues Projects Releases Wiki Activity

Update documentation, with info on netbooting ULTRIX.

Browse Source
This commit is contained in:
Boris Gjenero 2020-10-26 11:56:43 -04:00
parent 0e5c61da60
commit c4ebe27a95
2 changed files with 104 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
README.md
View File

@ -10,6 +10,12 @@ You can restrict the programs to a specific Ethernet interface by using the inte
## Notes
#### 802.3 transport issues
I need to disable 802.3 transport using the `-4` switch. Otherwise, KA650
and VAXstation 3100 m38 start 802.3 transfers which fail. Both also make
ordinary Ethernet transport requests, and those work.
#### Conversion of files
MOP loads files via packets which copy blocks of data to specific locations in memory, and then tells the system to start execution at a particular location. The clients know nothing about a.out or ELF, so the server needs to know how to load those files into client memory.
@ -22,9 +28,17 @@ You can use mopcopy to convert ELF and a.out files to MOP format, but you don't
The way mopd uses the Ethernet device requires root access. Without root access, you get "Operation not permitted" errors, which you won't see if you run mopd as a daemon.
#### The server only supports the first stage of MOP booting
#### Partial MOP implementations
With NetBSD/VAX, you only need the first stage. Afterwards it will use RARP and bootparams, or BOOTP, and then NFS. For Ultrix you can successfully send ultrixload using this program, but then it will perform another load via MOP, which isn't supported by this program yet.
Both this code and the code running on the other end is a partial and possibly
quirky implementation of the MOP protocol. Making things work is not simply a
matter of following the specification. You need to send what the other side
can deal with.
#### Booting ULTRIX
This code can now boot ULTRIX 4.00. See the
[README.md in the ultrix folder](ultrix/README.md) for more information.
## Links

88
ultrix/README.md Normal file
View File

@ -0,0 +1,88 @@
# Netbooting ULTRIX
ULTRIX is a Unix operating system released by DEC (Digital Equipment
Corporation) for PDP-11, VAX, MicroVAX and DECstation. This file explains
how to boot ULTRIX over the network on a VAX.
The ULTRIX boot procedure starts with 3 file loads via MOP (Maintennance
Operations Protocol). First, the VAX firmware requests a program, an operating
system. This needs to load `/usr/mdec/netload` from ULTRIX. Then netload makes
two more MOP program requests. Its first request (the second MOP request) asks
for a secondary bootstrap, which needs to be a C struct with configuration
information. This tells the kernel what IP address to use and where to find
root and swap. The last request asks for a tertiary bootstrap, which is the
ULTRIX kernel. It then passes control to the kernel. Once the kernel is
running, it uses the information from the secondary bootstrap to mount root
and swap, and begins the usual startup.
Modifications were made to mopd to make this work. The first stage is just
like loading a NetBSD 1k page size a.out binary, except the machine ID is zero.
The second and third requests send 0xFF as the length of the SOFTID field,
and expect transfers to finish with Memory Load with Transfer Address, with
the load address being required but data being optional. (The first stage won't
work with that, and continues to use Parameter Load with Transfer Address, like
before.)
## Quick instructions
If you don't know the VAX MAC address, as root run `moptrace -a` and attempt a
netboot via the VAX console. Names for boot files are based on that MAC address.
The hex digits must be in lowercase, without colons. The first stage is the
MAC address followed `.SYS` in uppercase, such as `08002b90649f.SYS`. The
second stage has `.2` between the MAC address and `.SYS`, like
`08002b90649f.2.SYS`. The third stage has `.3` between the MAC address and
`.SYS`, like `08002b90649f.2.SYS`. Symbolic links can be used.
Obtain `/usr/mdec/netboot` from ULTRIX and use it as the first stage.
Set up NFS server with ULTRIX root directory and create a swap file there.
Build `mkultconf` here and run `mkultconf -t > template` to create a template
file for configuration. Fill out the template. More information is available
via `mkultconf -h`. Create the stage 2 MOP file using
`mkultconf config.txt stage2.mop` and make it accessible at the stage 2 file
name.
Obtain ULTRIX kernel and make it accessible at the third stage file name. The
kernel must support netbooting. In ULTRIX 4.00, `/genvmunix` does not but
`/usr/diskless/vmunix` does. This kernel must have the same symbol table as
`/vmunix` in the root file system exported via NFS, because `ps` and other
tools read kernel memory using those symbols.
## NFS problems
#### ULTRIX tries to truncate device files
Attempts to write to devices mounted from a Linux NFS server, like
`echo > /dev/console`, will fail. Though, it is possible to append, such as
`echo >> /dev/console`. This is because ULTRIX sends an NFS V2 SETATTR, setting
the length of `/dev/console` to zero. Linux rejects this. ULTRIX even sends this
on a read only mounted NFS file system. Clearly ULTRIX has a bug. Because of it,
you can't see `/etc/rc` output which is written to the console this way.
In Linux, functions implementing `open()` cause `O_TRUNC` to be ignored in
such cases. ULTRIX can be patched, so that `copen()` in `gfs_syscalls` acts
similarly. For ULTRIX 4.00 and maybe other versions, Change
`ca8fff0fffff50d1508f001000001207` to `d38f0070000050d38f00700000501307`.
#### ULTRIX only sees 22 bits of disk usage
If you look at `du` output in the NFS mount on ULTRIX, you'll see only the
low order 22 bits of the numbers you see for that file system in Linux. The
ignoring of higher bits can cause ULTRIX to decide the file system is full.
## Other notes
* To run X at startup, take a look at `man dxsession` and add that line to
`/etc/ttys`, commenting out the console `getty` line.
* `/usr/var` needs to be writable. If mounting `/usr` read only, symlink it
elsewhere.
* `/etc/rc` assumes the system is diskless if `/etc/netblk.o` exists. At least
`touch` the file so the test passes and other NFS file systems get mounted.
* `/etc/fstab` uses `:` instead of whitespace for field separators. For an
NFS filesystem you need to use `/path@server` instead of the usual
`server:/path`. NFS servers need to be in `/etc/hosts`.
* Familiar X programs like `xterm` are on the unsupported tape.