SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

SCOUG-HELP Mailing List Archives

Return to [ 02 | January | 2005 ]

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


Date: Sun, 2 Jan 2005 15:05:58 PST8
From: < "jr_fox@pacbell.net" > 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.
=====================================================

>Contrary to the "It's really a breeze now" demos we've had at meetings, m=
y
>attempts to install eCS 1=2E2 on a partition of the Shuttle box yesterday=

>were a resounding failure=2E

Steven replied to me:

> Consider yourself special=2E :-)

Thanks much for your prompt reply=2E

Well, you know, if there is *any* way to find a non-standard or _original_=

result, I'm your guy !=20

>> I zeroed out the contents of the partition first,

> Using what? Fast format or dfsee? Fast format should have been
sufficient=2E

DFSEE=2E Wasn't leaving it to chance=2E O=2EK=2E, so now I know it's ove=
rkill=2E

> >presence of the JFS line in Config=2ESys (which had been fatal on some
>> hardware, apparently including the Shuttle), meaning that this problem
>> never did get fixed from the 1=2E1 installer=2E

> I suspect what you mean is some partition layouts=2E Jfs=2Eifs can not =
see
> the hardware directly=2E Did you restore the jfs=2Eifs statement after =
you
> discovered that this was not the problem?

In the course of doing this -- trying to run through all the possibilities=

-- and before I threw in the towell, I undid any changes I had made, incl=2E=

the JFS line=2E

>> It turned out >that the choke point was "Autocheck:*" on the HPFS line=2E=
=20
>> Must be the existing NTFS partitions causing indigestion=2E

> This is possible=2E Hpfs=2Eifs really should be smart enough to skip th=
e
> partition, but one never knows=2E If you can replicate this, please rep=
ort
> it to the bugtracker, unless it is already there=2E

I probably will have a chance to replicate the whole procedure, and may
have to attempt it more than once=2E In that case, once I get the bugtrac=
ker
URL, I can follow up on that=2E

>> The next roadblock seemed to be that Peer install failed=2E "The secon=
d
>> phase of installation aborted with error code 21=2E" The log says "Pro=
duct
>> returned 0x003, unexpected condition=2E"

> Which log?

I'll have to check=2E It was one of the last time/dated logs that seemed
related to Peer in some way=2E

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

O=2EK=2E 'Path Not Found' seems so fundamental=2E I'm wondering how that=

happens=2E

>> The installer did nothing beyond this point=2E

> This is working as implemented=2E An error of this nature stops the
> install=2E

I'll buy that=2E

>> This leaves a bare, minimalist, VGA desktop that looks to be not very =
=20
>> useful=2E

>> It is sufficient for the installer, which is why it exists=2E It's not=

>> intended to ready for production use by end users=2E =20

This seems to imply that it *could* be a sufficient launching pad for
successfully completing the install =2E =2E =2E though that sounds like i=
t might
require the sort of hands-on, command line type stuff you needed to
intervene with to finesse the 1=2E1 installs for this box (?)

> Also, as you might suspect, the error you encountered is not supposed to=
=20
> occur=2E

I'll buy that too=2E

>> I tried RESUME=2ECMD as the install booklet suggests=2E The MPTS setup=

opening >> screen flashes on for a split second, and then disappears=2E=20=

(There seems to >> be at least one additional log associated with this, an=
d
I could quote from >> it, if I knew what to look for=2E) =20

>> The best way to use the logs is to sort them in date descending order=2E=
=20
>> The "newest" log usually does no more that indentify the install
>> component that failed=2E The next newest log is usally the detail log =
for
>> the failing install component=2E

I'll try to keep that in mind for the next go-'round=2E

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

Thanks=2E They'll be coming down the pipeline shortly=2E

> As you might expect, resume=2Ecmd has not been tested in all possible
> failure scenarios=2E The logs may provide some details as to why it see=
ms
> to be confused=2E

Hope so=2E

> If you want to invest the time, you might try another install, leaving o=
ut
> Peer=2E This will tell us if the failure is really the Peer install or
> something else=2E

Sure=2E I've got little to lose at this point, and with 1/9 looking iffy =
for
me, I might as well give it a shot, or two=2E

>> Perhaps I would have done better migrating over top of the prior 1=2E1,=

vs=2E >> the clean install ?=20

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

My thinking there was that the 1=2E1 *had* a _working_ TCP/IP, MPTS, Peer,=

whatever=2E If those setups remained intact, although with various update=
d
files, maybe the particular problems seen here do not arise ? If the
_regular_ re-install attempt(s) should also fail, maybe a Migration run
would then be worth a try ?

Jordan

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web=2Ecom/ =2E

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

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.