HOLLINGE@SASK.BITNET.UUCP (02/21/87)
In article <8702171856.aa15847@noao.ARPA> bob@cald80.UUCP (bob) writes: >In article <8702181410.AA09488@csv.rpi.edu> yerazuws@CSV.RPI.EDU (Crah) writes: >>If you're willing to physically move disks, the solution is known (and simple) >>VMS can be booted from any device in the system, but Unix/Ultrix always >>wants to see itself on the 0'th device. So, put Ultrix on DUA0 and >>VMS anywhere else. > >WRONGO! > >I have personally run UNIX (4.2BSD) on a 780 on hp1 (DRA1). In >fact, I used that method to bring the run the system when hp0 (DRA0) >crashed violently (head crash, tire tracks on disk, not a pretty >sight). > >The problem is that DEC butchered UNIX when they started >distributing it. In 4.2BSD, you can put a line in your config file >which goes something like: > > root on hp0 or hp1 or hp2 > >which will tell the system that it can run on any of those three >disks. > >I don't think that Ultrix will allow you to do that. The thing >about Ultrix is that it's close enough to BSD to get you into >trouble. > We at The University of Saskatchewan have had hands-on experience with this situation. Situation 1: One of our (many :-() microvax IIs was configured to run both microVMS and Ultrix 1.2. We simply installed VMS in dua2 (of a 3 rd53 disk system) and Ultrix on dua0 both using the standard DEC installation procedures. This worked extremely well for the 4 months we ran it that way. We changed to running only VMS only because the Ultrix disk moved to another machine, not because of any software problems. Situation 2: Another microvax II was running Ultrix booted off dua1. As the original problem statement said, Ultrix will not (currently) let you install or upgrade on any disk other than dua0. But Ultrix will boot and run from dua1 if it is built there without using the installation procedure supplied by DEC. We had the situation of a 2 rd53 disk microvax II with both disks dedicated to Ultrix. The root filesystem was on dua0 with user files on the second filesystem of dua0 (not B partition, G I think) and both A and G partitions of dua1. The drive dua0 started to fail with many bad blocks in the G partition. So, we archived the A partition of dua1 and used dump to move a copy of the root file system to A partition of dua1. We also had to change the swapon and root commands in the config file to point to dua1 and rebuild the kernel on this new root file system. With the appropriate bootstrap command, this root on dua1 booted and ran fine while we had dua0 looked at. As I said before, this is not speculation, we have actually done this.