TUHS October 2005

tuhs@tuhs.org

21 participants
15 discussions

by norman＠nose.cita.utoronto.ca

I've assembled some notes from old manuals and other sources on the formats used for on-disk file systems through the Seventh Edition: http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html 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.)

2 years, 6 months

[pups] Can't get a second DZQ11 to configure?!

by Robert Armstrong

Hi Guys, 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, .... Disappointment! 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 second DZQ11. 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 boot it. 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. Bob Armstrong

19 years

Bringing up any 4.3BSD on a MicroVAX without tape....

by Jose R Valverde

>It is in the same boat as the one Robert is writing >about. I know I can install NetBSD/vax on it using the >net boot concept. But I'd like to run one of the >appropriate distributions from "our" collection. Any >suggestions? The most obivous ones are - Quasijarus - Ultrix-32M -- ultrix 1.2 is in the archives -- from ifctvax.harhan.org you can get sources for ultrix 2.0.0 ultrix 4.2.0 (see previous posts in the list) - 32V j ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es

19 years

Re: [TUHS] Bringing up any 4.3BSD on a MicroVAX without tape....

by Aharon Robbins

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. Arnold > 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). > > MS

19 years

Re: [TUHS] Bringing up any 4.3BSD on a MicroVAX without tape....

by msokolov＠ivan.Harhan.ORG

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. MS

19 years

Re: [TUHS] Bringing up any 4.3BSD on a MicroVAX without tape....

by msokolov＠ivan.Harhan.ORG

robertdkeys(a)aol.com wrote: > 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). MS

19 years

Re: [TUHS] Ancient unixes

by Brantley Coile

oops. sorry. it is http://cm.bell-labs.com/cm/cs/who/dmr/spe.html

19 years

Re: [TUHS] Ancient unixes

by Brantley Coile

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. http://cm.bell-labs.com/cm/who/dmr/spe.html http://cm.bell-labs.com/sys/doc/net/net.html remember. seventh edition was relase in 1977. Jimmy Carter was president, ``Anne Hall'' won best picture, and the Chevy Nova was a big hit.

19 years, 1 month

Status of "32i"

by Paul Duffy

Hi, 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. -Paul "There is no greater sorrow then to remember times of happiness when miserable" -- Dante "The Inferno"

19 years, 1 month

Re: [TUHS] Legality of porting ancient UNIX

by Jose R Valverde

Well, if I remember well, there was this little nifty legal argument between ATT USL and UCB BSDI in the early '90s that was settled out of court. One of the factors that helped settle (again if I remember well) was that ATT had failed to adequately state its Copyright on UNIX version 32V (may be more, my memory's weak) that had been distributed in source code, and hence those sources by the then current Copyright law, had fallen in the Public Domain. Then, if my recollection is right (better look at the documents on the case available on dmr's web page), you could do as you well damn please with those sources. http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/bsdisuit.html >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 relief." 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). j ______________________________________________ Renovamos el Correo Yahoo! Nuevos servicios, más seguridad http://correo.yahoo.es

19 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS October 2005