TUHS

tuhs@tuhs.org

6 participants
6421 discussions

by mxs46＠k2.scl.cwru.edu

Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" > prompt, from which you can execute the standalone images. I know this. > "format" seems to crash badly [...] Of course! The documentation says clearly that it's for hp (780/750/8600 MASSBUS and clones) and up (RH-11 and clones) disks. > [...] but one probably doesn't need that on a Q-bus > machine :-). Has nothing to do with Q-bus, it's the distinction between SMDish disks and MSCP. But yes, for MSCP you are supposed to use the controller-specific diagnostics for formatting. For DEC ones it's a pain, but most (all?) third-party MSCP controllers have formatting utilities in their ROMs. > There are other ways to start it up. For example, using an already- > running OS (some other Unix or VMS) and copying the miniroot from tape > to the swap area of an unused disk. Here is my preferred way. It requires at least two disks. First boot from an Ultrix tape. That's the easiest thing in the world probably (assuming working hardware, of course, which I don't have right now). When you get a choice between quick installation, custom installation, and maintenance, choose the last one. This will drop you into the shell. Now you have Ultrix running in a RAM disk, you can do anything you want with your disks, and you can pull the Ultrix tape out and do anything you want with the tape drive. Then you put the BSD tape in, advance to the second file (the miniroot) with mt fsf, and dd it to partition c on one of the disks. Why partition c and not partition b? Why need two disks in the first place? Because I can bet that Ultrix and BSD will have different ideas about the default location of partition b. Then extract mdec/rdboot and mdec/bootra from the /usr tar image on the tape, cat them together, and dd them to the beginning of partition c (the miniroot as shipped doesn't have a bootblock). Then reboot from that disk. Now you have BSD running! Disklabel the other disk the way you want. This will put the bootblocks on it automatically. Then create the root and /usr filesystems on it and restore them from the tape. You are all set! True, this method imposes additional requirements (two disks and an Ultrix tape). It's also a little cumbersome (the part about the miniroot bootblocks). However, it has two advantages over the method with the tmscpboot tape. First, you can use the stock BSD tape, not a hacked one. Second, even in Reno tmscpboot supports only KA630 and not KA650. If you know VAX assembly language (I don't yet) and have a machine where you can rebuild it, you can fix this, but again you have extra requirements. Of course, the proper solution is to significantly redesign BSD's installation mechanism and make it a little more like Ultrix's. That's my plan for Quasijarus2, although Quasijarus1 will still be like Tahoe/Reno. > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) I agree wholeheartedly! A standalone disklabel program is part of my plan for Quasijarus2. Again, Quasijarus1 will still be like Tahoe/Reno. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled > code. The lifting of the filesystem limits is in Tahoe, not in Reno. When you talk about the speed of Reno's binaries, what are you comparing it to? I know for sure that there are no significant changes in the C compiler between plain 4.3, Tahoe, and Reno. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00292 for pups-liszt; Mon, 23 Nov 1998 09:40:18 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f >From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Mon Nov 23 08:41:31 1998 Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id JAA00282 for <pups(a)minnie.cs.adfa.oz.au>; Mon, 23 Nov 1998 09:40:08 +1100 (EST) (envelope-from wkt(a)henry.cs.adfa.oz.au) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA29811; Mon, 23 Nov 1998 09:41:31 +1100 (EST) From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Message-Id: <199811222241.JAA29811(a)henry.cs.adfa.oz.au> Subject: Re: Minnie's new domain name To: mxs46(a)k2.scl.cwru.edu (Michael Sokolov) Date: Mon, 23 Nov 1998 09:41:31 +1100 (EST) Cc: pups(a)minnie.cs.adfa.oz.au (PDP Unix Preservation) In-Reply-To: <199811220300.WAA16161(a)skybridge.scl.cwru.edu> from Michael Sokolov at "Nov 21, 98 10:00:59 pm" Reply-To: wkt(a)cs.adfa.oz.au X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk In article by Michael Sokolov: > Dear Warren, > > I see you started changing *.adfa.oz.au to *.adfa.edu.au. Should we all > start changing this in our notes, aliases, links, etc? And just out of > curiosity, what's changing? What did OZ.AU mean? Did it mean Australian > universities or what? Are you changing to EDU because that's what everyone > else uses? > > And while we are at it, what's ADFA? I thought the school's name is > UNSW, isn't it? Hi Michael, yes I should put some email out. History lesson following.... Before the Internet reached Australia, the universities had a UUCP-based mail/news system called ACSnet, where addresses were not bang-paths but @-based. The ACSnet software did the route lookups. Anyway, all ACSnet computers had a `domain' name ending in .oz, e.g kre(a)munnari.oz was a valid email address. When we finally got Internet-connected, our country suffix was .au. To make the transition easier, we just tacked it on to the end of the existing domain names, thus kre(a)munnari.oz became kre(a)munnari.oz.au More recently, to bring Australia in line with Internet conventions, .oz.au became .edu.au. Unfortunately, ADFA never bothered to do this switch until mid-way through this year. Over the summer break, I'll add some smarts to minnie's web server and other services to remind people to make the switch in their bookmarks, hotlinks etc. I'll keep it running indefinitely. ADFA is the Australian Defense Force Academy: it has military cadets as undergrads and civilians as postgrads. One half is run by the University of New South Wales and teaches normal civilian university stuff. I belong to this half. The other half is run by Defence, and teaches military history, how to shoot with guns etc. I'm not involved with that side at all :-) Cheers all, Warren P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA00331 for pups-liszt; Mon, 23 Nov 1998 09:49:26 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

What *was* the Tahoe?

by SHOPPA＠trailing-edge.com

I've been looking over the 4.3BSD Tahoe and Reno distributions available in the PUPS archive, and have (what I hope) is a rather simple question: What is the "Tahoe"? It seems - based on the documentation supplied in the Tahoe-specific installation docs - that "Tahoe" generically refers to any of several VERSAbus machines in the Berkeley EECS department. The CCI (Computer Consoles Inc.) Power 6/32 is frequently mentioned as the CPU, but the Harris HCX-7, the Unisys 7000/40, and ICL Clan 7 are also mentioned. Are these all the same architecture and instruction set, or are they different? How was the CPU implemented - on a chip? On a chipset? On a board? On multiple boards? The information regarding peripherals is a bit clearer. There appear to be many different supported VERSABus SMD-drive controllers and at least one supported VERSABus 9-track controller. Are any of the Berkeley EECS Tahoe machines still up and running? How many were there? How many were outside Berkeley? Tim. (shoppa(a)trailing-edge.com) Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA01013 for pups-liszt; Mon, 23 Nov 1998 12:01:32 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

Re: 4.3-VAX distributions

by mxs46＠k2.scl.cwru.edu

Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > That would explain why I couldn't boot it, yep. Partially. You wouldn't be able to boot it on a MicroVAX by typing "B MUA0" even if it were complete. The reason is that the standard tape-making script writes the VAX-11 bootstraps on the tape, not the MicroVAX ones. The two are completely different. The big VAXen with front-end processors, microcode consoles and such can't boot from a tape by themselves. The bootstraps that appear on standard BSD distributions are designed to be loaded by manually typing in a little program from the console in hex and manually transferring control to it. The hex codes for 4 such programs (for different tape drives and controllers) appear in the installation docs. They cannot be ported to MicroVAXen, however, because they use some features that exist only on big VAXen. MicroVAXen, however, have tape boot capabilities built right into their ROMs. Much easier for the installer, needless to say. Also needless to say, the protocol the ROM tape boot code uses is completely different from the one the BSD developers have crafted for their very special purpose. Therefore, a tape needs a completely different bootstrap in order to be directly bootable on a MicroVAX. One was written for 4.3BSD-Tahoe, and it appears in the distributed /usr/mdec. There are two problems, however. First, the standard tape-making scripts don't put it on the tape. Second, it only supports KA630. When KA650 support was added, everything else was updated accordingly, but this one was apparently forgotten. In theory, the code looks generic enough to run on KA650 out of the box, but in practice it has a check for SID and refuses to run if it's not 08 (MicroVAX ii). Right now I don't know enough VAX assembly language to remove this check or extend to accept 0A (CVAX) as well. > In any event, I am now very happy to now have a bootable copy of > 4.3-Reno. (Installing as I type, AAMAF.) Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball and make a MicroVAX boot tape? > We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be > completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? > It's the most reasonable approach I can think of at the moment. That's close to what I'm doing. There are two differences, though. First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than between Tahoe and Reno. The latter is really huge, it's a gap between True UNIX(R) and a bloated and POSIXized fallen one.) Second, what I will be building won't be plain Tahoe, it will be Quasijarus1, i.e., Tahoe plus KA650 support and shadow passwords from Reno and other improvements from both later CSRG code and my own brain. SCCS will be the #1 tool in the process. > And what stands in the way of reading around the bad blocks on Kirk > McKusick's 43tahoe_cci distribution? Even though I know that Rick > Copeland doesn't have all the fancy tape recovery equipment I have in my > lab, is there some fundamental problem preventing the use of "mt fsr" > commands to skip the bad block(s) and recover the rest of the "src" and > "usr" tree? If you do this you will still miss something. OTOH, if you go to the 4.3tahoe directory on Kirk's 2nd CD-ROM, you won't miss anything, since all of /usr and /usr/src is there. I can bet that the files on that CD-ROM match the ones on the tape byte for byte. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA14402 for pups-liszt; Sun, 22 Nov 1998 17:04:17 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

Re: 4.3-VAX distributions

by SHOPPA＠trailing-edge.com

>> In any event, I am now very happy to now have a bootable copy of >> 4.3-Reno. (Installing as I type, AAMAF.) > Do you mean the one in /usr/home/msokolov/43reno.vax? How did you get it >to boot on a MicroVAX? Did you pull /usr/mdec/tmscpboot out of the tarball >and make a MicroVAX boot tape? Exactly. The details are all in tmscpboot.c. Prepend this to the "tape directory", write it to TK50, B MUA0, and you're at the "=" prompt, from which you can execute the standalone images. "format" seems to crash badly, but one probably doesn't need that on a Q-bus machine :-). There are other ways to start it up. For example, using an already- running OS (some other Unix or VMS) and copying the miniroot from tape to the swap area of an unused disk. The compiled-in partition tables used during an install are a real pain compared to, say, a 2.11BSD installation, where disklabel is a standalone utility! (That's a real win, Steven!) >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than >between Tahoe and Reno. The latter is really huge, it's a gap between True >UNIX(R) and a bloated and POSIXized fallen one.) Gees, looking at the install docs there are some very real improvements in Reno, especially in the filesystem and the speed of recompiled code. I'm willing to live with a bit more disk space usage, especially for the promised speed benefits. It's not like KA630's or KA650's are speed demons, and big cheap disks are readily available these days. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA14819 for pups-liszt; Sun, 22 Nov 1998 20:10:10 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f >From "Steven M. Schultz" <sms(a)moe.2bsd.com> Sun Nov 22 19:00:06 1998 Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id UAA14808 for <PUPS(a)MINNIE.CS.ADFA.EDU.AU>; Sun, 22 Nov 1998 20:10:00 +1100 (EST) (envelope-from sms(a)moe.2bsd.com) Received: (from sms@localhost) by moe.2bsd.com (8.9.0/8.9.0) id BAA06484 for PUPS(a)MINNIE.CS.ADFA.EDU.AU; Sun, 22 Nov 1998 01:00:06 -0800 (PST) Date: Sun, 22 Nov 1998 01:00:06 -0800 (PST) From: "Steven M. Schultz" <sms(a)moe.2bsd.com> Message-Id: <199811220900.BAA06484(a)moe.2bsd.com> To: PUPS(a)MINNIE.CS.ADFA.EDU.AU Subject: Re: 4.3-VAX distributions Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk Hi - > From: SHOPPA(a)trailing-edge.com > To: PUPS(a)MINNIE.CS.ADFA.EDU.AU All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't know there were any left :-) :-) > Exactly. The details are all in tmscpboot.c. Prepend this to the > "tape directory", write it to TK50, B MUA0, and you're at the "=" Since PUPS is on a uVax kick at the moment I'll chime in with my (not so fond) memories of trying to jack 4.3-Reno onto a uVax-II. It was a perverse sort of fun but not something I'd willingly do again. Burnout? Perhaps. the base 4.3 system up to and including Tahoe couldn't be cold started on a KA630 (much less a 650 since that didn't exist yet ;)). You _had_ to have the Ultrix 'boot' bits&pieces to work with. The 4.3 kernel had uVax support in it but the boot stuff did not. With 4.3-Reno that changed but... As others have noticed the cold start kit didn't create tapes suitable for a uVax. > prompt, from which you can execute the standalone images. "format" > seems to crash badly, but one probably doesn't need that on a Q-bus > machine :-). What I ended up doing was using my 2.11BSD 11/73 to create a bootable 4.3-Reno tape for the uVax - all the pieces are there, just need a system to 'dd' the files out with the right blocking factors, usw. Then the fun really began. The SPL "probing" logic in the kernel had a small problem when probing for MSCP controllers. As I recall (and this is going back quite a few years) some 3rd party adaptors ran at a different (lower) SPL than the probing logic expected - thus the autoconfig routines raised the SPL higher than the interrupt of the (Dilog I think) controller and the whole system hung. So, to install the system you HAD to use DEC controllers - ok, I had a RQDX3 and a couple RD53 drives present (the Dilog had a 319mb Miniscribe disk). BUT 4.3-Reno had a bug in the MSCP driver and would not recognize an honest to DEC RD53 drive! This was rapidly getting to be unfun. I think the workaround (it's been a __long__ time so memory is fuzzy) was to lie and call the drive an RA60 and then correct the problem later. But to get the lie thru to the kernel I had to use the standalone 'copy' program to copy a file (created on a PDP-11) to the first couple sectors of the uVax's RD53. Sheesh! > The compiled-in partition tables used during an install are a real > pain compared to, say, a 2.11BSD installation, where disklabel is > a standalone utility! (That's a real win, Steven!) You're quite welcome. Actually 4.3-Reno served as inspiration and reminder of pain to avoid when it came time to implement 2.11BSD's disklabel capabilities. I swore I'd never go thru the pain of the kernel having labels but the standalone utilities lacking them 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the standalone programs still had compiled in partitions. > >First, I'm using Ultrix as my cross-compilation base, not 4.3BSD-Reno. (I > >would say there is less of a gap between 4.3BSD-Tahoe and Ultrix than > >between Tahoe and Reno. The latter is really huge, it's a gap between True Can't be any version of Ultrix I ever used. At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD that DEC had corrupted with System V(anilla) bolted on contamination. Affectionately known as Buglix ;-) That was the same era that DEC had Ultrix-11 and that was a mucked up 2.9BSD. Of course you have to realize DEC had "Mr. Ken (Unix is Snake Oil) Olsen" around at the time 8-) UNIX is still around - but DEC? No, I don't like Compaq confusers thank you ;) 4.3-Reno was a transitional experiment that happened just as the CSRG and DEC had a serious falling out - and DEC support (Vaxen) vanished at that point. Any further work (4.4BSD) totally and completely ignored all DEC machines. > Gees, looking at the install docs there are some very real improvements > in Reno, especially in the filesystem and the speed of recompiled Yep - you get NFS (which no 4BSD had prior to Reno). NFS doubles the size of the kernel though (at least) so there's a memory penalty to pay. It also brought many of the POSIX features (termios for example). > code. I'm willing to live with a bit more disk space usage, especially > for the promised speed benefits. It's not like KA630's or KA650's are speed > demons, and big cheap disks are readily available these days. Disk is cheap. Especially for older drives (but you run the risk that an old drive will die soon ;-(). Best to invest in a modern SCSI<->MSCP adaptor and use current drives (that's what I did for my 11/73 - adaptor is $$$ but the drives are cheap). Boy, you're not just whistling Dixie (apologies to those outside the US for which the reference is obscure). "Not a speed demon" doesn't begin to describe it. I went, believe it or not, thru the work of getting a newer GCC-2 (at the time I think 2.3.x was "new") to build and run on a uVax-II under 4.3-Reno. The biggest problem was that 4.3-Reno was neither "old" (V7ish) Unix or "POSIX" (just getting off the standard's writers desks). Getting GCC to build was a stop/go effort for several days but in the end the build would work: about 23 hours (or so)!! Sheesh - a 11/73 can *completely* regenerate itself from sources (all programs, manpages, etc) in about 28 hours. It was an interesting experiment but the uVax-II has sat here for 2+ years without being powered up. At one time the thought was to port 4.4BSD over but everyone that _could_ do the work lost interest - I've my PDP-11s and PPro systems to keep me busy so I haven't the time or inclination to do much with a KA630 system. For "slow" I have a PDP-11 (lots of fun, keeps you humble with the address space limits ;)). For 'fast' I have a couple dual cpu PPro systems (running BSD/OS) that can give a quad processor SUN Enterprise Server-4500 a run for their money. I have no need of a "slow" computer that attempts to run current day (bloated) software. I've toyed with the idea of swapping the innards of the 11/93 and the uVax. The KDJ11E would be a lot happier in a BA-123 than a BA-23;) But that's as far as it's gone (thinking about it). So - if anyone out there wants a uVax-II (9mb of memory but lots of disks and a 9-track tape drive to go with) drop by my place (shipping's out of the question). If you're more hardware capable than I perhaps we could swap the stuff into a BA23 (smaller enclosure to drive home, ...). Yikes and gadzooks - I was a bit verbose tonight (but my typing skills are much improved! ;-)). Steven Schultz sms(a)moe.2bsd.com Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id UAA14865 for pups-liszt; Sun, 22 Nov 1998 20:31:53 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

4.3-VAX distributions (was Re: The files Tim Shoppa has just uploaded)

by SHOPPA＠trailing-edge.com

> I have just logged into minnie and diffed the files Tim Shoppa has just >uploaded against the 43reno.vax distribution in my home directory. They are >identical byte for byte, Darn. And the label said it was a Tahoe distribution :-). You'll also remember that I'm the one who found the V6 RL02 packs at UBC which, despite all indications, are actually some sort of V7 system that has all the internal labels reading "V6"! > except that Tim's first file is severely >truncated. That would explain why I couldn't boot it, yep. In any event, I am now very happy to now have a bootable copy of 4.3-Reno. (Installing as I type, AAMAF.) We all know now that Michael's on a crusade for 4.3-Tahoe, so would it be completely unreasonable to build 4.3-Tahoe from sources under 4.3-Reno? It's the most reasonable approach I can think of at the moment. And what stands in the way of reading around the bad blocks on Kirk McKusick's 43tahoe_cci distribution? Even though I know that Rick Copeland doesn't have all the fancy tape recovery equipment I have in my lab, is there some fundamental problem preventing the use of "mt fsr" commands to skip the bad block(s) and recover the rest of the "src" and "usr" tree? -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA14239 for pups-liszt; Sun, 22 Nov 1998 15:57:23 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

The files Tim Shoppa has just uploaded

by mxs46＠k2.scl.cwru.edu

Dear PUPS/TUHS members, I have just logged into minnie and diffed the files Tim Shoppa has just uploaded against the 43reno.vax distribution in my home directory. They are identical byte for byte, except that Tim's first file is severely truncated. The first file contains the bootstraps and the standalone programs, and for Reno it's about 140 KB. Tim's first file is only 512 bytes, although these bytes exactly match the first 512 bytes in the correct first file. Resolution: the files Tim has uploaded are completely superseded by the authentic 4.3BSD-Reno/VAX distribution in /usr/home/msokolov/43reno.vax and /usr/PUPS/Distributions/4bsd/43reno.vax. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA13933 for pups-liszt; Sun, 22 Nov 1998 14:04:29 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

Re: 4.3BSD Tahoe binaries for uVax

by mxs46＠k2.scl.cwru.edu

Tim Shoppa <SHOPPA(a)trailing-edge.com> writes: > Some further clues, for anyone who's following this bit or > archeology: This is clearly a 4.3BSD-Reno tape (for VAX). I'll look at it when it's fully uploaded (you're saying it won't be until 19:00 EST, so it'll be after the X-Files I guess), but I can bet that it's identical to the one in /usr/home/msokolov/43reno.vax on minnie (read by Rick Copeland from the CSRG master provided by Marshall Kirk McKusick). > The second file on the tape has the following string in it: > > 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990 > trent@kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot The second file is the dd image of the miniroot filesystem. This string appears in the /vmunix file inside (the kernel). kerberos.berkeley.edu was a VAX. The tape in /usr/home/msokolov/43reno.vax has also been pressed from kerberos.berkeley.edu. > The third file has this string in it: > > 4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990 > trent@kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax. The third file is the dump of the full root filesystem. Again, this string appears in the /vmunix file inside. > Additionally, in the third file, there appears to be some printf-type > strigns for configuring in the different possible CPU's supported: > > VAX 8600, serial# %d(%d), hardware level %d(%d) > VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d > VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d) > VAX 11/750, hardware rev %d, ucode rev %d > VAX 11/730, ucode rev %d > MicroVAX-II-MicroVAX 3000, ucode rev %d This is also obviously inside /vmunix. The set of supported CPUs is the one for Reno. > So the tape sticker says "Tahoe", the miniroot and Generic root claim > to be Reno, and the fourth file (the tar archive) has the following > mentions of Tahoe and Reno: > > [names on manpage directories mentioning tahoe] It is Reno. Trust me. "tahoe" appears in the names of some manpage directories because some manpages are architecture-specific (tahoe is the name of a computer architecture, just like vax, hp300, i386, etc.). The tape is mislabeled, that's all. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA13713 for pups-liszt; Sun, 22 Nov 1998 12:47:28 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

Re: 4.3BSD Tahoe binaries for uVax

by SHOPPA＠trailing-edge.com

Some further clues, for anyone who's following this bit or archeology: The second file on the tape has the following string in it: 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 PDT 1990 trent@kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot The third file has this string in it: 4.3 BSD Reno UNIX #4 Sat Jul 28 13:24:08 PDT 1990 trent@kerberos.berkeley.edu:/nbsd/usr/src/sys/GENERIC.allvax. Additionally, in the third file, there appears to be some printf-type strigns for configuring in the different possible CPU's supported: VAX 8600, serial# %d(%d), hardware level %d(%d) VAX 82%c0, hardware rev %d, ucode patch rev %d, sec patch %d, ucode rev %d VAX 11/78%c, serial# %d(%d), hardware ECO level %d(%d) VAX 11/750, hardware rev %d, ucode rev %d VAX 11/730, ucode rev %d MicroVAX-II-MicroVAX 3000, ucode rev %d So the tape sticker says "Tahoe", the miniroot and Generic root claim to be Reno, and the fourth file (the tar archive) has the following mentions of Tahoe and Reno: $ sear file4.tar_list tahoe 755 0 Jul 29 06:26:47 1990 share/man/cat4/tahoe/ 444 2488 Jul 29 06:26:43 1990 share/man/cat4/tahoe/ace.0 444 3563 Jul 29 06:26:44 1990 share/man/cat4/tahoe/autoconf.0 444 1321 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cons.0 444 6446 Jul 29 06:26:44 1990 share/man/cat4/tahoe/cy.0 444 4074 Jul 29 06:26:44 1990 share/man/cat4/tahoe/dr.0 444 2331 Jul 29 06:26:44 1990 share/man/cat4/tahoe/enp.0 444 4121 Jul 29 06:26:44 1990 share/man/cat4/tahoe/ik.0 444 2498 Jul 29 06:26:45 1990 share/man/cat4/tahoe/intro.0 444 386 Jul 29 06:26:45 1990 share/man/cat4/tahoe/lp.0 444 4427 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mtio.0 444 9321 Jul 29 06:26:45 1990 share/man/cat4/tahoe/vd.0 444 3816 Jul 29 06:26:46 1990 share/man/cat4/tahoe/vx.0 444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/mem.0 444 2271 Jul 29 06:26:45 1990 share/man/cat4/tahoe/kmem.0 ---> share/man/cat4/tahoe/mem.0 755 0 Jul 4 18:49:29 1990 share/man/cat6/tahoe/ $ sear file4.tar_list reno %SEARCH-I-NOMATCHES, no strings matched If someone who is more aware of the 4.3BSD histories than I am (and I'm certain that I'm one of the least-aware folks around!) can pinpoint where in the hierarchy this tape belongs, it'd help settle a lot of my confusion! In the meantime, the FTP connection to minnie seems to be holding up admirably, and folks will be able to inspect the files for themselves sometime around 7 PM EST tonight (Saturday here - that's either tomorrow or yesterday in Australia, I can never remember which) in the directory /usr/home/shoppa/43bsd_tahoe on minnie. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA13145 for pups-liszt; Sun, 22 Nov 1998 10:13:57 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

Re: 4.3BSD Tahoe binaries for uVax

by SHOPPA＠trailing-edge.com

> The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe >tape with VAX binaries. I think I *might* be able to provide part of the solution to this. I have in my posession here a TK50 tape hand-labeled "4.3 Tahoe BSD". Let me upload it to my directory on Minnie, and maybe with some help from you guys we'll figure out what's in it. It has been at least a year since I've looked at the contents of this tape, but I was under the impression that it consisted mainly of binaries, and had very little in the way of sources on it. I'll put images of the tape files on Minnie (hmm - a full TK50 will probably be an overnight job) and with a little luck we'll figure out how to make the next step. (I didn't know that this was a sought-after tape in the first place!) I honestly don't know if this is a VAX Tahoe distribution or for something else (MIPS, maybe?). It did fail to boot on my KA650 when I tried it, but your notes indicate that this was to be expected because it wasn't a KA630. And browsing through the contents of the tape does seem to indicate that it might be for the VAX. The tape has 4 files on it, about 50 Megabytes uncompressed, organized as follows: File 1: 1 record, 512 bytes. File 2: 205 records, 10240 bytes each. File 3: 320 records, 10240 bytes each. File 4: 2135 records, 20480 bytes each. The first block has no obvious text in it. Obvious guess is a boot block :-) The second file appears to be an executable of some sort. Running "strings" against it turns up evidence that this is some sort of standalone utility that knows how to write to devices with names like "ra1", "hp3", etc. The third file is, I would guess, the dump of a root file system. The string "/dev/ra1a" and machine name "kerberos.berkeley.edu" turn up near the beginning, and the dump of what appears to be the "/dev" directory has names such as tu0, tu1, hp0a-hp0g, rhp0a-rhp0g, etc. The fourth file is a tar archive, and appears to contain mainly binaries, with little in the way of sources. The are links in the tar archive to things like "/sys/vaxuba", "/sys/vax", etc., but the /sys directory itself isn't in the tar archive. (Would this possibly be in the third file, which I guessed is a dump of the root filesystem? The other BSD- derived distributions that I'm familiar with do not have "/sys" or "/usr/src/sys" in the root filesystem!) -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA12866 for pups-liszt; Sun, 22 Nov 1998 08:41:48 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

Re: 4.3BSD Installation (probably off-topic)

by mxs46＠k2.scl.cwru.edu

SHOPPA(a)trailing-edge.com writes: > I've been looking over the recent 4.3-ish BSD distributions > now available from the PUPS archive. Thought I'd spin off > a copy for booting on one of my spare uVax II's [...] The most important thing here is to choose the right version of BSD. Plain 4.3 CANNOT boot on a MicroVAX II. Later versions, starting with Tahoe, can. The patches provided in 4.3_on_uVax_instructions are nothing more than pieces taken out of Tahoe. If you are going to use those, you might want to use the whole Tahoe system just as well, it has some very nice improvements, such as disk labels, better man mechanism, and MX record support in sendmail. The problem is that we (PUPS/TUHS) haven't been able to find a Tahoe tape with VAX binaries. I'm not sure if CSRG ever bothered to even make one, although it's as simple as executing one script on a running system (which they obviously had). Thus in order to run Tahoe, one would have to cross-compile it first. It's a pain and takes a lot of expertise, so I would strongly advise you to avoid effort duplication and wait until I do it and put the product up in my home directory on minnie.cs.adfa.edu.au. Actually since KA650 is all I have right now and Tahoe doesn't support it (but the support code appears later in the SCCS tree), I'll go directly from Ultrix (my cross-compilation base) to Quasijarus1, my first release, and won't bother with Tahoe. But for all practical purposes Quasijarus1 will be Tahoe plus KA650 support, shadow passwords, and bugfixes. Hmm, maybe your have never heard of Quasijarus Project, so I'll explain briefly what it is. I'm taking over UCB CSRG in terms of shepherding and maintaining pure Berkeley UNIX(R). I will first re-create it by taking their final SCCS tree and building my initial one, deciding piece by piece what belongs to pure Berkeley UNIX(R) and should be kept, and what is POSIX evil spirit or bloat and should be tossed. In general I draw the line right around the Tahoe release (summer of 1988), but I'll include anything from Reno and later code that's worth having, such as KA650 support and Reno's DBM-based shadow password model. Basically, I want to create a system with a classical (pre-Reno) look and feel which at the same time has all the quality improvements and bugfixes ever made by Berkeley, even if they are as late as 4.4BSD. The last classical release is Tahoe, so that's my base. I will be using Tahoe to decide what should be included and what should the look and feel be. Once I know from Tahoe that a given piece should be included, I'll go to the SCCS file(s) for that piece and decide which post- Tahoe deltas should be kept (because they are bugfixes or quality improvements) and which deltas should be tossed (because they introduce the evil spirit of POSIX or bloat). How soon will this happen? I'm all ready to go, but unfortunately hardware problems are holding me back. I have solved the KA650 problem I was having, but now I'm stuck because neither of the two TQK50 boards I have works. (The drive SEEMS to work, though.) Thus the sooner I find a working TQK50 board (or, alternatively, a working TK70/TQK70 pair), the sooner will I make 4.3BSD-Quasijarus1. > If there's a more appropriate forum for these questions, I'd > appreciate being redirected to them! Right now there isn't, because my main VAX farm is currently off the net. When I get it back on the net (no time estimate, at least several more months), I'll set up a set of mailing lists for Quasijarus Project and Berkeley VAX UNIX in general. > OK, Before Step I, as doucmented in 4.3_on_uVax_instructions, is: Totally disregard these instructions, they are for plain 4.3 ONLY. If you are using Tahoe or Quasijarus1, the distribution already supports MicroVAXen as shipped. If you don't want to use Tahoe or Quasijarus1 and want to use plain 4.3, you are on your own. > Is this an actual limitation on the 43reno.vax distribution currently > in the archive, or not? Reno doesn't have any limitations, it already supports KA630 and KA650, just like Quasijarus1. I personally don't use it, though, because it is not really True UNIX any more. With the evil spirit of POSIX and a bloat by a factor of 2 in both binaries and sources, Reno is the beginning of the destructive process that eventually (and necessarily) culminated with the disbanding of CSRG. > what non- > microvax machines will the 43reno.vax distribution boot on? 11/750? > 11/730? Of the big VAXen, plain 4.3 supports 11/780, 11/750, 11/730, and Venus (should have been called 11/790, but was unfortunately named 8600). Tahoe adds, and Quasijarus1 and Reno retain, the support for 8200. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id HAA12654 for pups-liszt; Sun, 22 Nov 1998 07:42:18 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au) X-Authentication-Warning: minnie.cs.adfa.edu.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f

26 years, 2 months

Jump to page:

2025

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