🚀 go-pugleaf

In article <1992Nov1.052415.16271@afit.af.mil> johair@afit.af.mil (John R. O'hair) writes:
>I recently installed the upgrade prep software that comes with the 
>3.0 so I could see what was on the CD-ROM. After looking and reading
>what is going on with 3.0 from a users perspective, I decided not to
>install 3.0 at this time, but apparently the 3.0 prep installation
>altered something in my system's configuration.
>
>I used Microphone II as my communications software, and after installing
>upgrade prep Microphone will "loose" the connection during a long
>download. For example, if I'm reading a long text document off the net
>at some point the program apparently hangs, but if I reconnect to the
>comm port, it starts to work again. Its very irritating, and I can't
>locate what is causing this problem. Since it worked before I installed
>3.0 upgrade prep, I assume that did something to my system. Does 
>anyone know what is going on and how do I correct it?
>

I have a different problem after running UpgradePrep: the system "beep"
has disappeared!

Dave Griffiths

In article <1992Nov1.052415.16271@afit.af.mil> johair@afit.af.mil (John R. O'hair) writes:
| 
| I used Microphone II as my communications software, and after installing
| upgrade prep Microphone will "loose" the connection during a long
| download. For example, if I'm reading a long text document off the net
| 

	I've noticed this problem in 3.0 also, but not using Microphone.
It's very random, but it happens quite often.  It usually happens when
the system is performing some heavy disk io or graphics intensive operation.

	I'm using a ZyXEL U1496 at 38400 bps.  This same setup worked without
a glitch for several months under 2.1

BTW, I built my 3.0 from scratch.

--Felix

In article <1992Nov1.052415.16271@afit.af.mil> johair@afit.af.mil (John R. O'hair) writes:
>I recently installed the upgrade prep software that comes with the 
>3.0 so I could see what was on the CD-ROM. After looking and reading
>what is going on with 3.0 from a users perspective, I decided not to
>install 3.0 at this time, but apparently the 3.0 prep installation
>altered something in my system's configuration.

I am not surprised that it broke serial port driver.  It has been
known that running UpgradePrep and not completing 3.0 installation
breaks DSP driver (all accesses to DSP will fail).

This is supposed to be a temporary configuration just for getting
3.0 installed, and not meant to be used every day.
I guess you either have to go all the way to 3.0, or stay with 2.1/2.2
without doing UpgradePrep. 

UpgradePrep for 3.0 replaces the following:

/sdmach                        (kernel)
/usr/standalone/boot           (boot block)
/usr/lib/NextStep/WindowServer (window server)
/usr/lib/NextStep/PS.VM        (window server image)


--
Izumi Ohzawa             [          ]
USMail: University of California, 360 Minor Hall, Berkeley, CA 94720
Telephone: (510) 642-6440     Fax:  (510) 642-6341
Internet: izumi@pinoko.berkeley.edu (NeXT Mail OK)

In article <1d1pc7INN440@agate.berkeley.edu> izumi@pinoko.berkeley.edu writes:
>
>I am not surprised that it broke serial port driver.  It has been
>known that running UpgradePrep and not completing 3.0 installation
>breaks DSP driver (all accesses to DSP will fail).
>
>This is supposed to be a temporary configuration just for getting
>3.0 installed, and not meant to be used every day.
>I guess you either have to go all the way to 3.0, or stay with 2.1/2.2
>without doing UpgradePrep. 
>

But what if you just want to install 3.0 on one disk while keeping 2.0
intact on another disk? Considering the reports of Icon, WriteNow etc
breaking under 3.0, it's quite useful to still have 2.x around. The
installation procedure shouldn't be so slanted towards _replacing_ 2.x.

Ideally what I'd like is to have as many files as possible shared by
symbolic links between my 2.0 and 3.0 disks.

Having said that, I must congratulate NeXT on a beautifully simple
upgrade procedure. Swings and roundabouts I guess.

Dave Griffiths

Three times in the last few days we've had a NeXT get into an odd state.
Any user who logs in from the console gets root's environment:
Terminal creates superuser shells, the dock is that of root, $HOME = /, etc.

rlogin from elsewhere, or "su username", gives a shell with the proper
owner, so the machine hasn't completely forgotten about that user.
Only valid account/passwords are accepted; you can't type just *anything*
and be logged in as root.

/usr/lib/NextStep/Loginwindow.app doesn't appear to have been modified.

---> Rebooting the machine restores normality. <---

We have lots of NeXTs, and most of them don't do this.

Other details:
    - We use YP for user accounts (+:::::: at end of /etc/passwd).
    - We have no netinfo server: each machine has only its local netinfo db.
    - Killing and restarting lookupd and nibindd doesn't help.
    - "nidump passwd ." looks normal.
    - A toy program which calls getpwnam() gives normal results.
    - No suspicious messages appear in /usr/adm/messages or /tmp/console.log.
    - Loginwindow.app leaves the correct user name in /etc/utmp,
	so "who" says "slevy   console ..." when slevy logs in,
	even though the logged-in stuff sees root's environment.

*Suspicious item:*  I think that netinfo is misbehaving somehow.
	When in this state, we found that, even though "nidump printcap ."
	showed the correct stuff and "lpr" was willing to queue requests,
	and deposit them in the local spool directory, it couldn't deliver
	them to the (remote) print hosts.

	Any attempt to e.g. "lpc restart printername" yielded an
	error in /usr/adm/messages:  "lpd[nnnn]: unknown printer: printername".

Anyone seen anything like this?  Any ideas of things to look for?

    Stuart Levy, Geometry Center, University of Minnesota
    slevy@geom.umn.edu