meo@gatech.edu (Miles O'Neal) (01/16/89)
mit-amt!geek%media-lab.media.mit.edu@eddie.mit.edu (Chris Schmandt) writes: >The installation instructions for 4.0.1 call for a complete file system >dump, rebuild the disk, and then restore the rest of the file system. >Pretty boring, since the options are dumping to floppy (NO!) or over the >net to a cartridge tape (slow....). If you are using YP (maybe even just NFS???) Sun says you cannnot mix and match 4.0 and 4.0.1 on the same network. So that makes the over-the-net dump tricky... >I was wondering if anyone has dealt with this and whether there may in >fact be some subset of files (vmunix, what else??) that I'd need to >install and leave the rest intact. As I have a running 4.0.1, that might >give some flexibility. If no one has done it but has some tips, I'll post >a method if I figure it out. Since 4.0.0 is so flawed, I suspect there's >a lot of us upgrading our roadrunners this week... We are writing Sun's marketing people over this - it was annoying but acceptable going from Beta to 4.0, but is NOT acceptable in regular release upgrades. I have no suggestions; we bit the bullet, backed up all 3 systems, upgraded, and then, because we don't use YP, fought the stupid installation procedures for several days to get the systems talking to each other. We almost had it working, when we found out that the memory leakage problems that manifest themselves in X11 were MUCH WORSE in 4.0.1; we had to reboot once a day (or more) instead of once a week. We are now backing down to 4.0, despite the speed, bug fixes, etc of 4.0.1. The final network problem we hadn't solved *appears* to be an automounter bug. By the way, the makefs is, at least in part, done to "optimize" the / and /usr partitions. The difference in size did not appear to be a big deal. Look at the disks and see if they are just bar format (other than the bootable, of course, on the 1st 2 disks). If so, you might be able to pull it off. We just decided it would take longer than playing by the rules. Now we wish we had waited altogether!!! DOSclaimer: These are my *personal* observations on the above situation. I was tempted not to post until we have been in contact more with Sun, but since someone else might be getting into this stuff too, I felt obligated. -Miles (gatech!stiatl!meo)
tbm@att.att.com (01/18/89)
In article <3445@mit-amt> you write: >We currently have some 386i's running 4.0.0 and just got an upgrade to >4.0.1. I also have a brand new 386i with 4.0.1 on the disk alreay (all >machines have the 300 odd Mbyte drives). We had a heck of a time upgrading to 4.0.1 on our two 386i - one 3/280 network. Turns out the 3/280 became its own master on reboot and we had trouble with it untill we shut off ypserv on it entirely. My advice is to do completely what SUN says. We backup our user files on the 90 meg 386is by rcp to the 3/280 and that is only 3 minutes each. Thus we did not have to use the floppy backup for them. Good luck Tom Merrick
jim@eda.com (Jim Budler) (01/19/89)
mit-amt!geek%media-lab.media.mit.edu@eddie.mit.edu (Chris Schmandt) writes: >... > The installation instructions for 4.0.1 call for a complete file system > dump, rebuild the disk, and then restore the rest of the file system. > I was wondering if anyone has dealt with this and whether there may in > fact be some subset of files (vmunix, what else??) that I'd need to > install and leave the rest intact... I suspect this is too late, but: 1. Boot the upgrade tape 2. Select "Restore individual partitions" 3. Restore / and /usr; Don't restore /files. 4. exit to single user shell 5. mount your old /files somehere. * go look at it * several places ( cluster, spool, var?) will be directories named sun386.sunos4.0.0 (approx., obvious) * delete them ( rm -rf ...) * umount the disk 6. Somewhere on the ramdisk you are working from is the script that does the work. Maybe /usr/etc. The script is in all uppercase, some name like UPGRADE, or INSTALL. [ I'm sorry, I've DONE this, it works, but to find the actual name I'd have to shut down my node, boot the installation tape, and check. I can't do that.] 7. edit the script. Look for the case where it does the /files system. Delete the line where it does a 'newfs' on the /file disk. 8. Make sure the application tape is in the tape drive. Execute the script you modified in (7). Say n to / and /usr, Say y to the /files prompt. Variations on this are possible, but I haven't tried them. 1. Unloadc all 'clusters' before starting the procedure. They are deleted in step 5, above. If you 'unloadc' them first you can probably skip step 5, a small tree of links will be left behind. [ I did it the way I described, I'm sure this variation would work, but I haven't done it] Hope this helps. jim -- Jim Budler address = uucp: ...!{decwrl,uunet}!eda!jim domain: jim@eda.com