I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
I've got a 11/73 with 2.11BSD. The hardware configuration is pretty
typical - RQDX3, DEQNA, TK50, and one DZQ11. Everything runs fine, but now
I need to install a second DZQ. The first DZQ has csr 160100 and vector
300, so according to my calculations the second should be at 160110 and
vector 310. I set the switches, install the card, and then edit my system
configuration to change NDZ to be 2, rebuild the kernel, reboot, and, ....
When it gets up to init, it says:
init: configure system
dz 0 csr 160100 vector 300 attached
ra 0 .... 172150 .... 154
tms 0 .... 174500 ... 260
... etc ...
nothing about the second DZQ. Everything else still works, including the
original DZQ11, and it boots up just fine except that there's no sign of the
I figured I made a mistake building the kernel, so I double check my
kernel configuration and yes, the file dz.h contains "#define NDZ 2". Just
to be safe I delete all the objects from my machine's configuration
directory and rebuild the entire kernel from sources (takes a couple of
hours on a 11/73!). Still no joy - init only finds one DZ... And I'm sure
I'm booting the new kernel because of the timestamp it prints out when you
At this point I figured it's a hardware problem. Just to be sure, I
pulled out both DZQs and swapped the switch settings on the two cards. This
makes the original DZQ card now the "second" one at 160110/310 and the new
card the "first" DZQ at 160100/300. Put it all back together and boot it up
again - same results! Init finds the first DZ but not the second!
Moreover, all the serial ports on the back that are now connected to dz0
(which is the card that used to be the second dz) still work! Of course,
the ports on dz 1 (which is the card that used to work) are now dead. It
seems like the two DZQ11 cards must be OK.
Oh, and BTW, I even used the 11/73's console ODT to verify that all
addresses from 17760100 to 17760117 respond.
The only explanation I'm left with is a configuration problem. Is there
something I don't know about rebuilding the 2.11bsd kernel? Is 160110/310
the wrong location for the second DZQ11?
Thanks much, any suggestions are appreciated.
>It is in the same boat as the one Robert is writing
>about. I know I can install NetBSD/vax on it using
>net boot concept. But I'd like to run one of the
>appropriate distributions from "our" collection. Any
The most obivous ones are
-- ultrix 1.2 is in the archives
-- from ifctvax.harhan.org you can get sources for
(see previous posts in the list)
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
Wasn't there an "installboot" program that told the bootblock where
to find the /boot file?
Boy was it a lllloooonnnngggg time ago that I dealt with this stuff.
> Date: Wed, 19 Oct 2005 13:28:31 -0400
> From: robertdkeys(a)aol.com
> Subject: Re: [TUHS] Bringing up any 4.3BSD on a MicroVAX without tape....
> To: msokolov(a)ivan.Harhan.ORG, tuhs(a)minnie.tuhs.org
> The /boot is there, so it is somewhere between the bootblocks
> and /boot that the connection is lost. The /boot is apparently
> not correctly found. But, it is there......
> Bob Keys
> -----Original Message-----
> > The problem is that it won't install boot blocks that work.
> > None of the raboot/rdboot/bootra/bootrd combos get
> > any farther than the cryptic "loading boot" message.
> The "loading boot" message comes from the bootblock code and indicates
> that the bootblocks are good and working. If it stops there, it means
> that you are missing the /boot file in the root filesystem (that's what
> it's loading).
Aharon Robbins <arnold(a)skeeve.com> wrote:
> Wasn't there an "installboot" program that told the bootblock where
> to find the /boot file?
The installboot program in the original 4.3BSD, whose function has been
incorporated into disklabel(8) in 4.3-Tahoe/Quasijarus, writes the boot
blocks to the disk, but it does not patch them with the location of
/boot, the bootblock code is smart enough to understand the filesystem.
As for Robert's problem, I don't know where he got screwed - but man,
use your head, what do you think your god-given brain is for? You can
single-step through the code with the MicroVAX ROM monitor's N command,
you can put some printf's in the code to see where it dies, etc, the
possibilities are limitless. Just debug it the same way you would debug
any other problem. What do you think I do when I get a similar
mysterious snafu? I debug it like a real programmer, don't go crying to
a mailing list.
> The problem is that it won't install boot blocks that work.
> None of the raboot/rdboot/bootra/bootrd combos get
> any farther than the cryptic "loading boot" message.
The "loading boot" message comes from the bootblock code and indicates
that the bootblocks are good and working. If it stops there, it means
that you are missing the /boot file in the root filesystem (that's what
this name `internet' name space was considered and rejected. it's
harder than one would think to get details right for all networks, the
addess is only a small part of the information needed for the
connection, and keeping a name space for all the internet updated
would be very hard. instead they use a network!machine!port syntax
with the dial command.
you can follow the full development of those ideas in the following papers.
remember. seventh edition was relase in 1977.
Jimmy Carter was president, ``Anne Hall'' won best
picture, and the Chevy Nova was a big hit.
Been reading through the list, just wondering did anything further come of
the whole 32V/i project? Last mail about it i see was back in April 2004.
"There is no greater sorrow then to remember times of happiness when
miserable" -- Dante "The Inferno"
Well, if I remember well, there was this little nifty
legal argument between ATT USL and UCB BSDI in the
that was settled out of court.
One of the factors that helped settle (again if I
was that ATT had failed to adequately state its
on UNIX version 32V (may be more, my memory's weak)
had been distributed in source code, and hence those
sources by the then current Copyright law, had fallen
the Public Domain.
Then, if my recollection is right (better look at the
documents on the case available on dmr's web page),
could do as you well damn please with those sources.
>From one of the rulings:
"Consequently, I find that Plaintiff has failed to
demonstrate a likelihood that it can successfully
defend its copyright in 32V. Plaintiff's claims of
copyright violations are not a basis for injunctive
For others, the license otorgued by Caldera when they
released the source (a BSD look-alike) would allow you
to as well to a large extent.
No need to go to the Open Group. Besides, they own the
trademark (i.e. you could not call the product UNIX
without their permission) but not the code (besides
their own microkernel developments).
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad