lau@kings.wharton.upenn.edu (Yan K. Lau) (04/10/90)
Does anyone have any experiences going from OS 10.1 to 10.2? Are they any "gotchas" I should be aware of? I don't want our main machine not working for any significant time because I messed up the install. Also, do I really need an additional 135 megs on my authorized area node to load the 10.2 software? The way I read the doc, I have to first load it like any other software and then install. I certainly don't have enough space for both 10.1 and 10.2 on at the same time. Also, when I choose aa.large, will I be able to select aegis and bsd4.3 as the unix default rather than sys5? I remember having a problem with this when we first install 10.1. Am I starting to sound paranoid? Yan. )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School ~/~ -Sheenaphile- 128.91.11.233 University of Pennsylvania /\ Darker grows the moon And shadows steal across the prison of my room
krowitz%richter@UMIX.CC.UMICH.EDU (David Krowitz) (04/10/90)
You can never be too paranoid when it comes to software installs. Backup *everything*! Twice! There are very few gotchas going from 10.1 to 10.2. Our installation went quite smoothly. You do need over 100MB of disk space, as the 10.2 tapes must be read onto the authorized area prior to being installed. If your current 10.2 AA is *not* installed with hard links, then you can save space by deleting the current AA before starting to load the 10.2 tapes. Be certain to back it up to tape before you delete it! If the current 10.1 AA was installed with hard links, then deleting it will not save you any disk space. You'll either have to temporarily move your user files off the disk while the 10.2 install occurs, or you'll need to backup everything to tape, invol the disk with the -f option to clean it off, and boot the machine from cartridge tape. The 10.2 minst program is much cleaner than the 10.1 version, so it will go easier than last time -- but it still takes about 4 hours to read through all the tapes. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
petersn@physics.utoronto.ca (Mike Peterson) (04/14/90)
In article <23005@netnews.upenn.edu> lau@kings.wharton.upenn.edu (Yan K. Lau) writes: > >Does anyone have any experiences going from OS 10.1 to 10.2? >Are they any "gotchas" I should be aware of? I don't want >our main machine not working for any significant time because >I messed up the install. When I installed SR10.2 on both a DN2500 and a DN4000, there were/are bad problems with the /dev/pty's being corrupted at regular intervals by either telnet/rlogin into the system, or by using any command on the display that implicitly or explicitly invokes the "vt100" emulator. The latter problem is so bad that after exitting the first vt100 use on the display, all further uses of vt100 hang (so you 1 try at 'vi', 'more', 'telnet', etc.) - the workaround is too rebuild the pseudo-devices with 'mkdev /dev pty' after EACH vt100 invokation (and it must be done by root!). Apollo claims this has not affected many other sites, but we batted 2 for 2. There is also an unofficial patch which is supposed to correct this problem - more on that coming right up! As a result of this, since ALL our logins are telnet/rlogin from a terminal server, and no one uses anything but 'vi' and 'more'/'less' on the display, we have not and will not convert any more systems to SR10.2 (we are a BSD Unix only operation), despite the fact that many problems of SR10.1 appear to be corrected. Of course, the DN2500 has to run SR10.2, but it is my system, so I login as root all the time so I can rebuild the pty's at will. Now, for you 10000 users, when I upgraded our DSP10000 from SR10.1.p to SR10.2.p, the initial installation went well once the "install checking os sr10.2.p none" option to either config or install++ was used (an "update" install will fail miserably without that option, and will not install all the files nor run any of the scripts at the end of install++). Since it is a DSP, all logins are telnet/rlogin (although the console terminal now appears to work with SR10.2.p; it never has with SR10.0.p or SR10.1.p), and the pseudo-ports were corrupted within 1/2 hour of use. So, I applied the above-mentioned patch to replace /etc/telnetd and /lib/streams, and rebooted - the reboot hung for 10-15 MINUTES trying to start "syslogd" (which eventually died with a "udp: unknown service" error), then 10-15 minutes on each daemon after that, and finally booted after 1 1/2 HOURS. TCP/IP was dead to the world, but crp still worked, so many attempts were made with HOTLINE and local SE help but TCP/IP could not be made to function. Eventually, our fiddling around starting the daemons (manually) destroyed something somewhere, and the next reboot just hung for good at the 'hostid' command in /etc/rc.local. The system was invol'ed and reloaded as a new installation from the SR10.2.p c-tapes, the patches re-applied, and rebooted - this time it hung starting syslogd, then crashed without intervention (we had more than a dozen no-status-code crashes while booting SR10.2.p, or logged in to the Phase II, or logged in at the console after a "full" boot). This time upon the first reboot the DSP10000 hung forever at the 'hostid' command, and was inaccessible by any means. We then invol'ed the disk again, and put back SR10.1.p - total lost time was 8 days - needless to say we are not at all impressed!!!! >Also, do I really need an additional 135 megs on my authorized >area node to load the 10.2 software? The way I read the doc, >I have to first load it like any other software and then install. >I certainly don't have enough space for both 10.1 and 10.2 on at >the same time. Can't help you there - I keep our AA for all systems on our 10000, since using small disked systems (i.e. less that 760 MB) for an AA doesn't leave enough space left over for useful work in our experience. I also 'rm -r ....' the "ri.apollo...." files for old products before loading new ones. >Also, when I choose aa.large, will I be able to select aegis and >bsd4.3 as the unix default rather than sys5? I remember having >a problem with this when we first install 10.1. Am I starting >to sound paranoid? Can't help here either - we are a BSD UNIX operation, but can't you just edit /etc/environ if it isn't set up properly? >Yan. > )~ Yan K. Lau lau@kings.wharton.upenn.edu The Wharton School > ~/~ -Sheenaphile- 128.91.11.233 University of Pennsylvania > /\ Darker grows the moon And shadows steal across the prison of my room Mike Peterson, system@alchemy.chem.utoronto.ca Dept. of Chemistry, University of Toronto. (416) 978-7094
csfst1@unix.cis.pitt.edu (Charles S. Fuller) (04/14/90)
In article <1990Apr13.135346.2452@helios.physics.utoronto.ca>, petersn@physics.utoronto.ca (Mike Peterson) writes: > > When I installed SR10.2 on both a DN2500 and a DN4000, there were/are > bad problems with the /dev/pty's being corrupted at regular intervals > by either telnet/rlogin into the system ... > ... the workaround is to rebuild the pseudo-devices > with 'mkdev /dev pty' We've run into that on a DN10000 running sys5 as well, and currently have an APR opened (along with a few other sites, I understand). There IS good news regarding one manifestation of the problem, though. Users at our site telnet into the machine via terminal server, and were being prevented from logging in due to the tty corruption problem. They would be presented with the "login:" prompt, but after supplying their username, they were being given no opportunity to respond to the "Password:" prompt before the system responded with an "Improper login" message. Recently, we received a "patched" telnetd which seems to correct that problem. I quoted "patched", above, because the "new" telnetd actually has an older timestamp than the "old" one. If you're still seeing this problem, I'd recommend calling Apollo ASAP. They may have "patches" for other machines, as well. One other apparent manifestation of the tty corruption problem still has us stumped, though. At apparently random times/tty's, the system arbitrarily chooses 24, 30, or 40 lines as the size of the terminal being driven. 24 is not bad on a 30-line screen, but 40 ... well, you get the picture. We have found that by logging-in on top of your current shell, you can get back to the proper number of lines. If anyone has any other hints for getting around the various manifestations of this problem, please post them. Although I am told that Apollo is feverishly working to find a fix for this, my own feeling is that it may be a while before a real fix is available, due to the complexity of the problem. Indeed, I hope that before a fix IS released, it is QA'd to a much greater degree than the original. Chuck Fuller Westinghouse Electric Corporation