SCOUG-HELP Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Sun, 2 Jan 2005 16:17:02 PST8
From:	"J. R. Fox" <jr_fox@pacbell.net >
Reply-To:	scoug-help@scoug.com
To:	scoug-help@scoug.com
Subject:	SCOUG-Help: eCS 1.2 install failure

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

Steven Levine wrote:

> >Contrary to the "It's really a breeze now" demos we've had at meetings, my attempts
> to install eCS 1.2 on a partition of the Shuttle box yesterday were a resounding
> failure.
>
> Consider yourself special. :-)

Well, you know, if there is *any* way to find a non-standard or _original_ result, I'm
your guy !

> >I zeroed out the contents of the partition first,
>
> Using what? Fast format or dfsee? Fast format should have been sufficient.

DFSEE. Wasn't leaving it to chance. Now I know this is overkill.

> > presence of the JFS line in Config.Sys (which had been fatal on some hardware,
> apparently including the Shuttle), meaning that this > problem never did get fixed
> from the 1.1 installer.
>
> I suspect what you mean is some partition layouts. Jfs.ifs can not see the hardware
> directly. Did you restore the jfs.ifs statement after you
> discovered that this was not the problem?

I tried out quite a few permutations, but tried to restore (nearly) everything to the
way it had been, before I threw in the towell. That included the JFS line. Near the
end, I'm pretty sure it booted with that line active. I REMmed it out again after
that, as I don't use JFS.

> >It turned out that the choke point was "Autocheck:*" on the HPFS line. Must be the
> existing NTFS partitions causing indigestion.
>
> This is possible. Hpfs.ifs really should be smart enough to skip the partition, but
> one never knows. If you can replicate this, please report
> it to the bugtracker, unless it is already there.

There likely will be a couple more install attempts, so if it does recur, I'll get the
bugtracker URL and follow up on that.

> >The next roadblock seemed to be that Peer install failed. "The second phase of
> installation aborted with error code 21." The log says "Product returned 0x003,
> unexpected condition."

> Which log?

Not sure at this point, but it would have been one of the last time/date-stamped logs,
and one that mentioned Peer.

> We need more info, but error 3 is usually path not found. We need to figure out
> which path.

'Path Not Found' sounds like something terribly fundamental, so I wonder how this
happens.

> >The installer did nothing beyond this point.
>
> This is working as implemented. An error of this nature stops the install.

Makes sense.

> >This leaves a bare, minimalist, VGA desktop that looks to be not very useful.
>
> It is sufficient for the installer, which is why it exists. It's not intended to
> ready for production use by end users.

Does this imply that what's left can be an effective launching pad for successfully
completing the install ? If so, I'm thinking it might require the sort of hands-on,
command line type intervention you had to use to finesse the 1.1 installs on this box
. . . .

> Also, as you might suspect, the error you encountered is not supposed to occur.

I'll buy that.

> >I tried RESUME.CMD as the install booklet suggests. The MPTS setup opening screen
> flashes on for a split second, and
> >then disappears. (There seems to be at least one additional log associated with
> this, and I could quote from it, if I knew what to look for.)
>
> The best way to use the logs is to sort them in date descending order. The "newest"
> log usually does not more that indentify the install
> component that failed. The next newest log is usally the detail log for the failing
> install component.

I'll keep that in mind, for next time.

> Appendix F lists the files you need to collect for support. If the logs did not get
> zipped, you need to do this yourself. If you want me to
> review them, e-mail them to me.

Much appreciated. They're on the way.

> As you might expect, resume.cmd has not been tested in all possible failure
> scenarios. The logs may provide some details as to why it seems
> to be confused.

Hope so.

> If you want to invest the time, you might try another install, leaving out Peer.
> This will tell us if the failure is really the Peer install or
> something else.

Sure, might as well, what with the 1/9 session looking iffy for me. There doesn't seem
to be much to lose at this point.

>> Perhaps I would have done better migrating over top of the prior 1.1, vs. the clean
install ?

> Perhaps, although common sense sense says a migrate is always more complex and thus
more prone to failure than a standard install.

My thinking there was that the prior 1.1 *had* a working TCP/IP, MPTS, Peer --
whatever. Assuming those setups remained intact -- albeit with various updated files
-- maybe the problems seen here would not arise. Should the _regular_ re-install
attempt(s) fail, I suppose I could restore that DFSEE image and try a Migration run.

Jordan

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 02 | January | 2005 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.