TUHS

tuhs@tuhs.org

25 participants
6495 discussions

by mxs46＠k2.scl.cwru.edu

Warren Toomey <wkt(a)henry.cs.adfa.oz.au> writes: > Over the summer break [...] I was first thrown off by this (yesterday was officially the first snow day here in Cleveland), but then I remembered that Australia is in the southern hemisphere, so your summer is our winter, right? > 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. OK, will change the HostName line in my .ssh/config. I'm already using the new domain name when posting. > P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's > back now. I hate PC hardware. Then why do you use it? Why not run the PUPS/TUHS server on a VAX running 4.3BSD-Quasijarus (or 4.3BSD or 4.3BSD-Reno if you can't wait), or maybe a PDP-11 running 2.11BSD? Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu P.S. Your Sendmail is still putting .oz.au in the outgoing mail headers. Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00720 for pups-liszt; Mon, 23 Nov 1998 10:40:08 +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> Mon Nov 23 09:31:04 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 KAA00713 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 23 Nov 1998 10:40: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 PAA18529 for pups(a)minnie.cs.adfa.edu.au; Sun, 22 Nov 1998 15:31:04 -0800 (PST) Date: Sun, 22 Nov 1998 15:31:04 -0800 (PST) From: "Steven M. Schultz" <sms(a)moe.2bsd.com> Message-Id: <199811222331.PAA18529(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 - > 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. UH, not quite so. Unless 4.3 and Tahoe used GCC (which they did not). I'd say that there is a big difference between the 4.3 C compiler (pcc or whatever it started out as) and GCC. Tahoe, while adding support for the CCI line of computers (tried to get folks to buy one but they wouldn't go for it) did NOT use GCC (which wasn't out yet or if it was had just started making an appearance). Reno came with GCC though. The older pre-Reno compilers (being straight K&R) didn't handle prototypes - that's what you had "lint" for. Steven Schultz sms(a)Moe.2bsd.com Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00729 for pups-liszt; Mon, 23 Nov 1998 10:41:02 +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, 5 months

Re: Minnie's new domain name

by norman＠nose.cita.utoronto.ca

Re Warren's postscript: P.S Minnie's 2nd hard disk wedged itself sometime over the weekend. It's back now. I hate PC hardware. Perhaps it's time to dig up an old PDP-11? Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA00626 for pups-liszt; Mon, 23 Nov 1998 10:31:02 +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, 5 months

booting 4.3-reno without a tape drive

by SHOPPA＠trailing-edge.com

Michael Sokolov wrote: > 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. For a quick work-around to make a bootable 4.3 miniroot without a tape drive, Michael, you might consider the following (similar tricks will work on NetBSD distributions too): Ingredients: Microvax II Honest-to-goodness DEC disk or *fully* compatible 3rd-party disk. *Fully* compatible means that it must have the same MSCP media ID code and same number of tracks, sectors, and cylinders as a drive already hardwired into vaxuba/uda.c. These are the ones hardwired in: { MSCP_MKDRIVE2('R', 'A', 60), "ra60", ra60_sizes, 42, 4, 2382 }, { MSCP_MKDRIVE2('R', 'A', 70), "ra70", ra70_sizes, 33, 11, 1507 }, { MSCP_MKDRIVE2('R', 'A', 80), "ra80", ra80_sizes, 31, 14, 559 }, { MSCP_MKDRIVE2('R', 'A', 81), "ra81", ra81_sizes, 51, 14, 1248 }, { MSCP_MKDRIVE2('R', 'A', 82), "ra82", ra82_sizes, 57, 14, 1423 }, { MSCP_MKDRIVE2('R', 'C', 25), "rc25-removable", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE3('R', 'C', 'F', 25), "rc25-fixed", rc25_sizes, 42, 4, 302 }, { MSCP_MKDRIVE2('R', 'D', 52), "rd52", rd52_sizes, 18, 7, 480 }, { MSCP_MKDRIVE2('R', 'D', 53), "rd53", rd53_sizes, 18, 8, 963 }, { MSCP_MKDRIVE2('R', 'X', 50), "rx50", rx50_sizes, 10, 1, 80 }, Note that "rd54" is conspicuously missing, and I think the tabulated rd52/53 sizes are as appropriate on a RQDX2, *not* a RQDX3. Some other operating system to write the disk from (for example, VMS, NetBSD, BSD2.11 and a PDP-11/73/83/93 CPU, RT-11 and any PDP-11 CPU, etc.) The tape distribution of 43reno_vax from the PUPS archive. Specifically, you need these files: miniroot mdec/rdboot, from usr.tar mdec/bootra, from usr.tar etc/etc.tahoe/disktab, from src.tar Cooking directions: The miniroot wants to live in the swap ("b") partition of the drive. So your first task is to find the starting block number of the swap partition from the extracted "disktab". For example, for an RA81, the offset ("ob=") for an RA81 is 16422 blocks. So copy the miniroot onto the target drive starting at block 16422 (i.e. if you're under 2.11 BSD and you've partitioned the target drive, ra0, so that partition a covers the entire disk, do a "dd if=miniroot of=/dev/rra0a seek=16422 bs=512") In the "a" partition of the output drive you need a copy of "boot". The miniroot already has a filesystem with this in it, so the lazy thing to do is to just plop another copy of the miniroot, starting at block 0 on the output disk (i.e. "dd if=miniroot of=/dev/rra0a") You need the secondary bootstrap in blocks 1-15 of the target disk. Put this down with "dd if=bootra of=/dev/rra0a seek=1 bs=512" You need a block-0 boot block on the output disk. For a Microvax, this is rdboot. (I believe raboot is appropriate on a Unibus or BI-bus VAX). Lay this down with "dd if=rdboot of=/dev/rra0a" Now move the output disk to your Microvax II configuration, and boot: >>> b dua0/r5:1 2..1..0.. loading boot ra0: unlabeled Boot : ra(0,0,1)vmunix ra0: unlabeled 338756+108644+131004 start 0x238c 4.3 BSD Reno UNIX #1: Sat Jul 28 15:19:06 1998 PDT trent@kerberos.berkeley.edu:/usr/src/sys/GENERIC.vaxminiroot REAL MEM=16773120 und so weiter. Now, one obvious improvement to this would be to lay down a fake 4.3-ish disk label at the start of the output disk as well. This way the reliance on a fully-geometry-compatible disk might be avoided. I'll work on this in my Copious Free Time (TM). -- 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 KAA00512 for pups-liszt; Mon, 23 Nov 1998 10:14: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, 5 months

Re: 4.3-VAX distributions

by mxs46＠k2.scl.cwru.edu

Steven M. Schultz <sms(a)moe.2bsd.com> writes: > All caps? Must be using a V(erbose)M(essage)S(system) confuser - didn't > know there were any left :-) :-) I'm sure you know that domain names are case-insensitive. Also note that in the InterNIC records everything is all uppercase. As far as the mail user names go, they CAN be case-sensitive, but most OSes, even UNIX (Sendmail), try to be on the safe side and ignore the case in this context. > 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. This change occurred in Tahoe, NOT in Reno. Trust me. If you don't, look at /usr/home/msokolov/43tahoe.cci/srcsys.tar.gz and see for yourself. > 4.3-Reno did have disklabels (the first 4.3BSD to do so) BUT the > standalone programs still had compiled in partitions. The disk label support first appears in Tahoe. Again, if you don't believe me, look at /usr/home/msokolov/43tahoe.cci. > At the time 4.3-Reno came out Ultrix was still a warmed over 4.2BSD [...] Ultrix v4.00, which I used to run on my main production VAX when my farm was on the net, has _ALL_ enhancements from 4.3BSD (including DNS and DBM passwd files) and most enhancements from Tahoe (including MX record support in Sendmail). Its disk label mechanism is rumored to be incompatible with Tahoe's, though (haven't had a chance to test this for myself). > [...] that DEC had corrupted > with System V(anilla) bolted on contamination. Here I agree wholeheartedly! But hey, just ignore all SysVile and DEC additions and pretend it's 4.3BSD! That's what I did. > 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. This pulled the thread that was holding everything together. Reno was the beginning of the destructive process that eventually and inevitably led to the disbanding of CSRG. Reno is the beginning of the end. One of the main reasons I don't do Reno. > Yep - you get NFS (which no 4BSD had prior to Reno). True. I will have to hack NFS into Quasijarus somehow at some point. This is not for Quasijarus1, though. 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 JAA00216 for pups-liszt; Mon, 23 Nov 1998 09:30:34 +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, 5 months

Re: 4.3-VAX distributions

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, 5 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, 5 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, 5 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, 5 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, 5 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, 5 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