roy@phri.UUCP (Roy Smith) (01/24/87)
Did you ever do something that you thought was really clever and just couldn't wait to tell the world about it. Well, if you have, you'll know why I'm writing this. Maybe I'm not the first person to think of this, maybe it's even obvious, but I thought it was pretty neat. Anyway... We're currently running 4.2BSD on a Vax with a single RA-81 disk. When I got the 4.3 tapes, I started to realize it might not be so trivial to get it running. How to change to a new version of the OS while minimizing downtime on a production machine? The installation guide mentions some of what you have to do, but it's not that easy if you only have a single disk; you can't just load up 4.3 on ra1a while keeping a working copy of 4.2 on ra0a. It's easy to have kernels for both systems on your root partition so you can boot one or the other, but you'll have the wrong /etc and /bin directories if you just do it that way. Things are complicated because the disk partitions we use match neither those distributed on the 4.2 or 4.3 tapes. This means, for example, that the stand-alone boot and copy programs won't work with anything other than ra(0,0). We've got a 200 Mbyte user partition (ra0h), 2 100 Mbyte partitions (ra0d is /usr, ra0f is random overflow), 2 8 Mbyte partitions (ra0a is root and ra0e is /tmp) and a 16 Mbyte swap partition (ra0b) (all sizes approximate). First, I punted on having lots of /tmp space and made ra0e into /4.3root. /4.3usr got put on ra0f. Then I followed the directions and merged our 4.2 setup and configuration files in the 4.3 file systems. At this point, I still couldn't easily boot 4.3 because its root is not on an "a" partition. To switch back and forth between 4.2 and 4.3 would have been a commotion because you have to get the standalone copy program up, then get the mini-root up, and use that to copy the system you want to boot to ra0a, making a level 0 dump of what's there now so you can go back to it if there is trouble. The trick is that the root file system resides on partition "a", aka minor device 0. Nobody says, however, that minor device 0 has to start at cylinder 0. So, I built two versions of 4.3, one with the partition table in the uda driver matching the one we use for 4.2, and the other with the entries for the "a" and "e" partitions switched around (this was done while 4.2 is still running, after some minor problems with the make file). I put a copy of each kernel in both ra0a and ra0e, using the same names on both file systems. In the /etc/fstab in the 4.2 root partition, I mount ra0d as /usr, ra0f as /4.3usr, and ra0e as /4.3root. In the /etc/fstab on the 4.3 root partition, I mount ra0f as /usr, ra0d as /4.2usr, and ra0e as /4.2root. There are various symlinks in ra0f pointing places in ra0d; for example, /4.3usr/local is a symlink to /4.2usr/local. The end result is as follows. If you boot ra(0,0)vmunix, you get the 4.2 kernel with the normal 4.2 root and /usr file systems mounted where they should be, and /4.3root and /4.3usr available on-line for easy access. If you boot ra(0,0)/4.3vmunix.swapped, you get the 4.3 kernel running with the 4.3 root and /usr partitions, with the 4.2 counterparts on-line and ounted in convenient places. In this latter case, the file you booted and the file known as "/4.3vmunix.swapped" are two distinct, but identical, files. If you boot ra(0,0)4.3vmunix.normal, you get the 4.3 kernel with the 4.2 root and /usr partitions mounted; I'm not at all sure why you would want to do this, but you can if you want. Of course, this is far too confusing for normal use. Once we are sure we have 4.3 running the way we want it, I can just copy ra0a to ra0e (which as far as a normal partition table is concerned means copying ra0e to ra0a) and reboot ra(0,0)4.3vmunix.normal. At my leisure, I can delete the redundant stuff from /4.2usr and mount that file system as /usr/local, and we're all done. The bottom line is that with a single disk drive, I'm able to flip back and forth between the 4.2 and 4.3 in literally just as long as it takes to do a normal reboot. Just one more reason why "if I can't get source, I don't want it". Unfortunately, if Berkeley ever gets around to writing the partition tables on the disks "like it should be", this scheme will break, but you can't have everything, can you? -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016 "you can't spell deoxyribonucleic without unix!"
muller@sdcc7.UUCP (01/24/87)
One trick I tired and it worked was I used 4.3 rdist to upgrade 4.2 machines. I moved rdist to the 4.2 machine, made a kernel for the 4.2 machine on the 4.3 machine moved the kernel to the 4.2 machine and let rdist fix the binaries for the 4.2 machine. I updated the boot blocks, and rebooted to the 4.3 kernel. fsck complained a bit (minor things) and I was up. This took a few hours wall time, but very little work on my part. Things were real funky while the rdist was running, but that was expected. (I just made sure that /etc was the LAST thing rdist updated). Keith Muller University of California, San Diego
jordan@ucbarpa.Berkeley.EDU.UUCP (01/27/87)
Keith Muller <muller@sdcc7.ucsd.EDU> writes:
One trick I tired and it worked was I used 4.3 rdist to upgrade
4.2 machines. I moved rdist to the 4.2 machine, made a kernel
for the 4.2 machine on the 4.3 machine moved the kernel to the
4.2 machine and let rdist fix the binaries for the 4.2
machine. (I just made sure that /etc was the LAST thing rdist
updated).
Two things:
1) The original poster was working from *no* 4.3 machines, so
although this is nice for propagating 4.3 around the net, it
doesn't solve his problem of getting it up from the tape.
2) I have had no problems with rdist'ing /etc first, rebooting
and then bringing over the rest ... my big problem (the first
time ... *sigh*) was that I rdist'ed /bin/csh which doesn't
run too well under 4.2 which rdist needed ... luckilly, the
4.2 csh works under 4.3, so do /etc first (so the network will
come up correctly after the reboot, and then get the rest.
/jordan