said:
>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. :-)
>I zeroed out the contents of
>the partition first,
Using what? Fast format or dfsee? Fast format should have been
sufficient.
>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?
>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.
>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?
We need more info, but error 3 is usually path not found. We need to
figure out which path.
>The installer did nothing beyond this point.
This is working as implemented. An error of this nature stops the
install.
>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. Also, as you might
suspect, the error you encountered is not supposed to occur.
>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.
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.
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.
>I note that this partial install laid down about 277M worth of files. The
>surviving 1.1 boot partition has 487M.
This does not mean very much since the install did not yet copy all the
files you selected.
>Is this entirely fixable, from where it stands ?
Without seeing the logs, I can only guess.
>Starting over from
>scratch will most likely yield very similar results.
Perhaps.
>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.
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.
HTH,
Steven
--
----------------------------------------------------------------------
"Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.100c_W4
www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST)
----------------------------------------------------------------------
=====================================================
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".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 02 |
January |
2005 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.