I've got one remote sysstem which shares an OS/2 BBS operation with HyperHost for OS/2. On infrequent occaisions, this system gets sticky with Hyperhost and
doesn't let me work accurately with the remote desktop for some reason I've never been able to trace. If I can physically be at the site, shutting down HyperHost and re-starting it will fix this. But that doesn't do much good from
miles and mile away from it.

HyperHost and access from it from HyperAccess Pro do have an option to Reboot the remote PC. However, if I use it, this particular Warp4 FixPack 17 system with all the latest goodies traps on reboot with an OS/2 insufficient memory error I've not been able to trace. It has plenty of memory, but something isn't right during the reboot.

I've not tried a crude <CTRL ALT DEL> to see what that would do while at the site.

The important thing is that any reboot has the whole CONFIG.SYS and Desktop set
to automatically bring back up the Bink/Max BBS as well as the HyperHost application. Which works perfectly well from any normal shutdown.

What is a good command line program which could be run from the BBS which would
properly shut down both the BBS and the HyperHost applications, then automatically get a 'normal' OS/2 boot run started?

Inquiring mind wants to know.

Thanks!

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Am 18.11.07 22:33 schrieb Mike Luther

What is a good command line program which could be run from the
BBS which would properly shut down both the BBS and the HyperHost applications, then automatically get a 'normal' OS/2 boot run
started?

\ecs\bin\shutdown.exe

shutdown ?
tells more about its options.

--- Sqed/32 1.15/development 729:
* Origin: Sei sparsam, koste es was es wolle. (2:2476/493)

Replying to a message from Mike Luther 1:117/3001 to All,

About Remote safe reboot, On Sun Nov 18 2007

What is a good command line program which could be run from the BBS
which would properly shut down both the BBS and the HyperHost
applications, then automatically get a 'normal' OS/2 boot run
started?

I dont know if this will help Mike, maybe worth checking out:

Shutdown v1.6 for OS/2 2.x
--------------------------

Shutdown is a utility to schedule a system shutdown. This can be done in several ways. The exact commandline is as follows:

SHUTDOWN.EXE [[/axxxx] | [[/dyyyymmdd] [/thhmm]] [/b]]

where:
/a - shutdown after xxxx seconds
/d - shutdown on YYYYMMDD (Year, Month, Day)
/t - shutdown on HHMM (24 hour format)
/b - reboot after shutdown has completed
/? - show a help screen

SHUTDOWN without options will shutdown the system immediately

You cannot use the /a option in combination with /d and/or /t. Command line parsing is case sensitive so you should use /a instead of /A.


I can send it to you via email if you wish or maybe hobbes has it I got it via Fernwood.

Hope this helps. Keep us posted.

We are a fine board trying to make it better.
http://www.pris.bc.ca/ghannah
ghannah@pris.bc.ca
Cheers! Gord
-=Team OS/2=-
--- timEd/2 1.10.y2k+
* Origin: Marsh BBS (c), Dawson Creek, BC Canada (1:17/23)

Thanks Herbert!

Am 18.11.07 22:33 schrieb Mike Luther

What is a good command line program which could be run from the
BBS which would properly shut down both the BBS and the HyperHost applications, then automatically get a 'normal' OS/2 boot run
started?

\ecs\bin\shutdown.exe

shutdown ?
tells more about its options.

You suggestion prompted me toward what I'm now about to try! See thanks message also to Gord ..

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Thanks Gord! (And Herbert as well!)

Replying to a message from Mike Luther 1:117/3001 to All,

I dont know if this will help Mike, maybe worth checking out:

Shutdown v1.6 for OS/2 2.x
--------------------------

Shutdown is a utility to schedule a system shutdown.
This can be done in several ways. The exact
commandline is as follows:

SHUTDOWN.EXE [[/axxxx] | [[/dyyyymmdd] [/thhmm]] [/b]]

where:
/a - shutdown after xxxx seconds
/d - shutdown on YYYYMMDD (Year, Month, Day)
/t - shutdown on HHMM (24 hour format)
/b - reboot after shutdown has completed
/? - show a help screen

SHUTDOWN without options will shutdown the system immediately

You cannot use the /a option in combination with /d
and/or /t. Command line parsing is case sensitive so
you should use /a instead of /A.

I sniffed it out and picked it up off OS2site.

In raw form it works on this box from which I'm posting these replies which is MCP2 XRC05 level. And Herbert, yes I do have a paid for eCs 1.2r here, but not
installed as there are serious reasons I haven't been able to move to eCs with hundreds of thousands of files and stuff on all the machines which absolutely create a ZOO with any form of migration from Warp4 in eCS.

So what I did was pick off SHTDWN16.ZIP off the site above. Then after verifying that it does work and doesn't seem to trash any open applications on this system I write a REXX script file. Put a complete ID and password setup into that REXX script file. That gives me something from which I can call into
the somewhat jammed HyperHost at this remote site, pop this from the still totally working Bink/MAX system there. I can thence, from a secured standpoint, in theory, force this remote reboot there. That site, already set up to come back up fully fuctional with the exact desired applications running from a cold boot, should be stable this way.

Now all I've got to do is wait until I get back out there miles and miles from here to test it, see if it will work without this crazy not enough memory error
from a jam-me deal. The UPS system has enough to hold if up over 36 hours without any power if needed. But a power off failure does this same thing that
the Remote Reboot does from HyperHost. So maybe I now have a way to avoid ride time!

We'll see. Thank you both.

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

In a message dated 11-19-07, Herbert Rosenau said to Mike Luther:

Hi Mike,

What is a good command line program which could be run from the
BBS which would properly shut down both the BBS and the HyperHost applications, then automatically get a 'normal' OS/2 boot run
started?

\ecs\bin\shutdown.exe

I have it also in the \os2\install\ directory

Have a nice day,

Holger

___
* MR/2 2.30 * This OS/2 system uptime is 321 days 16:52 hours (en).


--- PCBoard (R) v15.22 (OS/2) 2
* Origin: Coming to you from the Sunny Aland Islands. (2:20/228)

Yes, Holger..

\ecs\bin\shutdown.exe

I have it also in the \os2\install\ directory

Spot on correct.

But the question of focus on at the start of this romp was how do we get whatever shutdown.exe to automagically do a reboot .. as well as close down all
running objects without intervention on the path through the code forest to properly do that!

My guess is that however IBM originally created this escapade was to use the <CTRL ALT DEL>, if smashed from the keyboard on the original keyboard IRQ ring level priority, to accomplish this task. Which, if I was trained well enough to know how this works, exactly, I could have impersonated in the REXX file written. But as un-informed as I am on this problem, that is sort of how I got
toward making my original post here!

I'd thought about starting the reading project to go through all the <CTRL ALT

blocking stuff that is out there to see what could be done here, but

figured it would be likely better and less time spent to just ask for the help the way I did.

As well, the shutdown.exe file in the OS/2\INSTALL directory is different as to
size and release date for a Warp4 vs. MCP2 installation from what I've seen here.

Warp4 FP17 --------- 19,010 bytes 08-09-96 1:01am
MCP2 XRC05 -------- 25,362 bytes 09-24-01 3:56pm

And now that you've said this, I wonder. My research on the externally furnished shutdown.exe from the shtdwn16.zip archive was originally done on an MCP2 system. The remote system is Warp4 FP17. As originally done on the MCP2 system, a fully running couple of my own objects were automatically closed with
I ran the test. The MCP2 box came right back up with no need to tell the shutdown to stop any process.

But the above all thought about, maybe what I ran remotely at the test site was
really nothing more than the IBM supplied shutdown.exe and not the test I thought I was running at all!

Hmmmm.... I think when I'm out at the remote site I will rename the externally
furnished shutdown.exe to a different name, as well as change the program name in the REXX .CMD file I wrote. It just might be that the path priority in whatever the system is using when all this fires up actually isn't using the shutdown.exe from the archive!

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001

--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Am 19.11.07 11:53 schrieb Mike Luther

Thanks Gord! (And Herbert as well!)

Replying to a message from Mike Luther 1:117/3001 to All,

I dont know if this will help Mike, maybe worth checking out:

Shutdown v1.6 for OS/2 2.x --------------------------

Shutdown is a utility to schedule a system shutdown. This can be
done in several ways. The exact commandline is as follows:

SHUTDOWN.EXE [[/axxxx] | [[/dyyyymmdd] [/thhmm]] [/b]]

where: /a - shutdown after xxxx seconds
/d - shutdown on YYYYMMDD (Year, Month, Day) /t -
shutdown on HHMM (24 hour format) /b - reboot after
shutdown has completed /? - show a help screen

SHUTDOWN without options will shutdown the system immediately

You cannot use the /a option in combination with /d and/or /t.
Command line parsing is case sensitive so you should use /a
instead of /A.

I sniffed it out and picked it up off OS2site.

In raw form it works on this box from which I'm posting these
replies which is MCP2 XRC05 level. And Herbert, yes I do have a
paid for eCs 1.2r here, but not installed as there are serious
reasons I haven't been able to move to eCs with hundreds of
thousands of files and stuff on all the machines which absolutely
create a ZOO with any form of migration from Warp4 in eCS.

Oh, eCS 1.2R gives you an easy way to migrate from WARP 4.0, 4.5, 4.51 or 4.52 to eCS. The only requirements to get it right are:
- clean os2.ini, os2.sys.ini
wptool32.zip (HOBBES) helps you to get that
- a system partiton in size of 500 MB or bigger
- do NOT format the system partiton when the installer asks for
That means to install over the old system.

To be sure for success you'll make a backup of the system before you tries to do that. Thereafter you will simply copy/move the member of the "old desktop" you likes to hold in the new system to the place you likes they have to reside now and kill the folder thereafter.

When something fails you can easy restore the backup to make another try.



--- Sqed/32 1.15/development 1110:
* Origin: Sprengt eueren Rasen und alles andere auch in die Luft (2:2476/493)

Am 20.11.07 16:51 schrieb Holger Granholm

In a message dated 11-19-07, Herbert Rosenau said to Mike Luther:

Hi Mike,

What is a good command line program which could be run from the
BBS which would properly shut down both the BBS and the
HyperHost applications, then automatically get a 'normal' OS/2
boot run started?

\ecs\bin\shutdown.exe

I have it also in the \os2\install\ directory

No, this is another one - no options, not the same functionality.

--- Sqed/32 1.15/development 922:
* Origin: Wer frueher stirbt, ist laenger tot! (2:2476/493)

And I jumped to the wrong conclusion, sadly, Herbert and Holger ..

Hi Mike,

What is a good command line program which could be run from the
BBS which would properly shut down both the BBS and the
HyperHost applications, then automatically get a 'normal' OS/2
boot run started?

\ecs\bin\shutdown.exe

I have it also in the \os2\install\ directory

No, this is another one - no options, not the same functionality.

Turns out that my research work reached the wrong conclusion at least for this remote system reboot with version 16 of the non-IBM utility. I renamed this non-IBM utility to SHUTBOOT.EXE and ran it externally for research purposes from the BBS command line SysOp mode.

BLAM! Locked box again!

OK more research showed that the apparently successful remote reboot with SHUTDOWN.EXE that I 'ran' from the REXX script was actually the IBM version in \OS2\INSTALL. I ran a PATH call and discovered that the path for \OS2\INSTALL was ahead of my utility directory I custom make for things needed here! Thus the program which 'ran' was the IBM version,not the test version.

OK, that is why we wound up with the BBS shut down, but *NOT* HyperHost in the test run. OK, when I was able to log in to HyperHost from the test remote HyperAccess Pro and saw the customary IBM gray block request for confirmation of shutdown of the 'running' process of HyperHost, I didn't do that. What I did was at that point command a Remote Reboot from the HyperAccess object selection. Which *DID* result in a clean reboot remotely.

What I've learned is that for a remote reboot I need to do is to go in with HyperAccess Pro and shut down the BBS system ahead of time. Then simply ask for a remote restart with HyperAccess Pro and that will properly reboot the remote system.

Now .. what went wrong with the non-IBM version? Dunno at this point. Remote system is not responding. I'll post what I learn when I get through there today on the trip out there to debug this on site.

Thanks..

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001




--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

In a message dated 11-21-07, Mike Luther said to Holger Granholm:

Hi Mike,

As well, the shutdown.exe file in the OS/2\INSTALL directory is
different as to size and release date for a Warp4 vs. MCP2
installation from what I've seen here.

Warp4 FP17 --------- 19,010 bytes 08-09-96 1:01am
MCP2 XRC05 -------- 25,362 bytes 09-24-01 3:56pm

OK, didn't know there were different files with the same name delivered
from IBM. Of course updates are another thing but the size difference is
larger than a normal update.

Hmmmm.... I think when I'm out at the remote site I will rename the ML>externally furnished shutdown.exe to a different name, as well as
change the program name in the REXX .CMD file I wrote. It just
might be that the path priority in whatever the system is using when
all this fires up actually isn't using the shutdown.exe from the
archive!

Well, anyway you got the remote setup working again without going there.

Have a nice day,

Holger

___
* MR/2 2.30 * Quit worrying about your health, it will go away.


--- PCBoard (R) v15.22 (OS/2) 2
* Origin: Coming to you from the Sunny Aland Islands. (2:20/228)

In a message dated 11-21-07, Herbert Rosenau said to Mike Luther:

Oh, eCS 1.2R gives you an easy way to migrate from WARP 4.0, 4.5,
4.51 or 4.52 to eCS. The only requirements to get it right are:

- - - - - - CUT - - - - - -

- a system partiton in size of 500 MB or bigger

- - - - - - CUT - - - - - -

Thanks for the information Herbert.
My present Warp 4 + FP12 occupies 120 Mb on a 170 Mb partition!

Have a nice day,

Holger

___
* MR/2 2.30 * This OS/2 system uptime is 323 days 13:29 hours (en).

--- PCBoard (R) v15.22 (OS/2) 2
* Origin: Coming to you from the Sunny Aland Islands. (2:20/228)

Thanks for the thought Herbert

Oh, eCS 1.2R gives you an easy way to migrate from
WARP 4.0, 4.5, 4.51 or 4.52 to eCS. The only
requirements to get it right are:
- clean os2.ini, os2.sys.ini
wptool32.zip (HOBBES) helps you to get that
- a system partiton in size of 500 MB or bigger
- do NOT format the system partiton when the installer asks for
That means to install over the old system.

To be sure for success you'll make a backup of the system before you tries to do that. Thereafter you will simply copy/move
the member of the "old desktop" you likes to hold in
the new system to the place you likes they have to
reside now and kill the folder thereafter.

When something fails you can easy restore the backup to make another try.

I'd like to investigate this part of your post. I do understand the migration process for moving a Warp 4 operation to Merlin Convenience Pack. But per what
I found out the very hard way, as well as formally as a member of IBM's TestCase in Austin, and also in comments with the eCs crew at the time, there simply is *NO* safe way to migrate any Warp 4 OS/2 operation directly to eCs at
all for the very huge number of files and the complex desktop operations I had in all my OS/2 Warp 4 operations. And may face in yet other systems of others which I really should move to MCP2 level code.

What I found out the hard way, IBM absolutely confirmed formally in both TestCase as well as was released to the public, you should *NOT EVER* try to migrate the hard drive operations directly from Warp 4 to MCP2. The migration process, as well as the LVM conversion of the hard drive disk partitions can *ONLY* be safely done as provided in Merlin Convenience Pack #1. As was told me, not only this was true, but IBM pulled and would not provide the LVM disk migration utility from the MCP2 level distribution. There were VERY serious data loss issues that could, did and do erupt from trying this any other way than MCP1 level upgrade path work.

Yes, that means I had to and did do two desktop migrations. I first migrated the whole systems to MCP1. Then, as absolutely required by the error issues in
MCP1, I did and you really have to install Fix Pack #1 for MCP1 to solve some serious problems there.

From there, you do a SECOND migration to MCP2. Then do the whole desktop migration a second time to MCP2 from MCP1. Then you do a complete Fix Pack update for the MCP2 code only AFTER you get the core stuff there at the MPTN, PEER and TCP/IP fix levels needed. Plus do the require audio support work and so on for that as your final steps.

In doing this I was able to completely and SAFELY move all of the OS/2 work which I had migrated first from OS/2 version 2, to OS/2 version 3,to Warp 4 through I think it was Fix Pack 15 at that time.

More important, at this point even after YEARS of service since migration, I have never once had any stability issues for desktop operations and system instability at all from the migration process. Not ever.

The absolute professional advice for all this was very specific. It wasn't an issue of eCs at all. It was the fact that there was absolutely no safe way to handle complex desktop and application migration directly to eCs. Because the migration tools and really needed technology could not be contained and furnished in the eCs product as it even first was released.

OK ... that was quite a while ago.

Now .. what absolute proof and experience is there that migration of very complex and huge file totals from Warp 4 can *SAFELY* be moved to eCs even as to the version 1.24 that I, for example, do have, but have never been able to take a chance to even install?

Precisely where is it documented by IBM and the crew that the LVM conversion can be safely done for Warp4 and the MCP2 level which is eCs at this point?

I'd really like to know the complete professional documentation and text of the
discussion for this. And it isn't a criticism of eCs at all as to the things that are in eCs in the formal releases .. or .. the eCs test crew at all to which I am speaking. I just cannot afford to make an error in mission critical
work from which there is simply no way, to as you suggest:

When something fails you can easy restore the backup to make another try.

Thanks!

Sleep well; OS/2's still awake! ;)

Mike @ 1:117/3001






--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)

Am 22.11.07 16:27 schrieb Holger Granholm

In a message dated 11-21-07, Herbert Rosenau said to Mike Luther:

Oh, eCS 1.2R gives you an easy way to migrate from WARP 4.0, 4.5,
4.51 or 4.52 to eCS. The only requirements to get it right are:

- - - - - - CUT - - - - - -

- a system partiton in size of 500 MB or bigger

- - - - - - CUT - - - - - -

Thanks for the information Herbert. My present Warp 4 + FP12
occupies 120 Mb on a 170 Mb partition!

To fix that you would
1. boot from eCS installation CD
2. press Shift+F3 to get commandline window
3. fire up LVM
4. make volumes from the partitons (needed to get the
existent partitons visible to eCS (this is free of risk)
5. exit lvm with save

6. zip -9rS system c:\*
same for any other partiton
zip and unzip are in path here!

Now you can boot again to your system (nothing chaged yet)
to burn the the zip's onto CD/DVD

Thereafter you would reboot to eCS install CD and
go on commandline window as above

call up LVM again
switch to physical view
remove any partiton as needed to get free space to recreate the new partitios
- system with minimum 500 MB in size
(better 2GB to get yet the required size for eCS 2.0)
- and to get the partitons you have removed back with reduced size.

There may be no need to remove any partiton, but you have to remove at lest 2 neighbours to get the system partiton big enough. You'simply fill the created gap in other seizes for the needed partitions.

When you have recreated the needed plain partitons you'll switch LVM back to logical view and create volumes from existent partiton

- C: should be 'compatible, bootable'
this is important because this is the only way
to get the system partiton bootable again
- others: 'compatible'. For now because you in
prepare state to migrate.

exit LVM with save.

7. format C: /FS=HPFS /L
comment. /L is needed for savety
format the other volumes you've recreated
8: restore the data from backup
That means: exchange the CD to the one youve
burned with the ZIP file on to one of the
new formatted ones to be able to replace
the the CD with the installation CD
c:
unzip x:\path\system

So, your system is back. Do the same as above to restore the data for the other
partitons. before shooting up the zip command you have to change the current directory to the root you will unzip to.

and you got you old system back without any change - except the partiton sizes.

Optionally you can boot up your old system to test that it works again - but you can ommit that step and continue directly with the installer. It's your choice.

--- Sqed/32 1.15/development 28:
* Origin: $home is where .profile is (2:2476/493)

Am 23.11.07 19:15 schrieb Mike Luther

I'd like to investigate this part of your post. I do understand
the migration process for moving a Warp 4 operation to Merlin
Convenience Pack. But per what I found out the very hard way, as
well as formally as a member of IBM's TestCase in Austin, and
also in comments with the eCs crew at the time, there simply is
*NO* safe way to migrate any Warp 4 OS/2 operation directly to
eCs at all for the very huge number of files and the complex
desktop operations I had in all my OS/2 Warp 4 operations. And
may face in yet other systems of others which I really should
move to MCP2 level code.

The differnce is that we do NOT migrate to MCP! We migrate to eCS. This is NOT the way IBM had done! The migration to eCS 1.2 is written by mensys to avoid the mistakes IBM had done in theyr migration path.

Yes, it is possible that the migration can fail - for that you would archive the complete system and restore the system from the archive when the migration fails. Sou you have always another chance to go on without loosing a bit of data.

Now .. what absolute proof and experience is there that migration
of very complex and huge file totals from Warp 4 can *SAFELY* be
moved to eCs even as to the version 1.24 that I, for example, do
have, but have never been able to take a chance to even install?

Precisely where is it documented by IBM and the crew that the LVM conversion can be safely done for Warp4 and the MCP2 level which
is eCs at this point?

There is nothing documented by IBM what eCS does to get the migration from WARP4 to eCS (not MCP!) because IBM knows nothing about the eCS migration path.
Yes, eCS is based on MCP but far from identical.

Yes the way eCS 1.2 does the migration from WARP4 is absolutely different than in eCS 1.0 and eCS 1.1. This path is rewritten from scratch to avoid all the flaws.

The requirements for migration are clear:
- clean up OS2.INI and OS2SYS.INI bevore any try,
because 99% of all problems are resulted in
unclean INIs.

I'd really like to know the complete professional documentation
and text of the discussion for this. And it isn't a criticism of
eCs at all as to the things that are in eCs in the formal
releases .. or .. the eCs test crew at all to which I am
speaking. I just cannot afford to make an error in mission
critical work from which there is simply no way, to as you
suggest:

The migration to the current eCS ends up with
- a clean new desktop
- a new folder containing the whole OLD desktop
ready to move anything needed from there
to the location the user wants it to have now.

After the user has done the last step of moving anything of interest to its place the old desktop can easy removed from the desktop because nothing is left
except of things with a bit of interest. Another cleanup of the INIs thereafter
will increase the system stabilitiy but is not a requirement.

When something fails you can easy restore the backup to make
another try.

Yeah, the backup is a requirement for security only. That is set because there are uncountable variations a long time used owns the migration can fail on. Having a complete backup of an System gives always a secure way to go back to start and restart from begin. Again, I'M not willing to speak about migration to MCP - but migrating to eCS. These are 2 completely defferent pairs of boots.
Again: eCS is NOT MCP and MCP is NOT eCS. Even as eCS uses MCP2 as root.

The differences between a new install and a migration to eCS are
- a new install starts with an empty volume
- a migration makes a backup of the INIs it findsand
- removes outdated components from disk
and lefts anythin not system related untouched
- copies anything over from CD
- recreates the old desktop into a separate folder
on the new desktop.

Again: the new installed system is not MCP, it is eCS.

--- Sqed/32 1.15/development 978:
* Origin: Lieber Kies in der Tasche, als Sand im Getriebe ! (2:2476/493)

In a message dated 11-24-07, Herbert Rosenau said to Holger Granholm:

Thanks for the information Herbert. My present Warp 4 + FP12
occupies 120 Mb on a 170 Mb partition!

To fix that you would

............................

remove any partiton as needed to get free space to recreate the new HR>partitios - system with minimum 500 MB in size
(better 2GB to get yet the required size for eCS 2.0)

And why do you think that I would be interested in updating the
operating system to something that needs more than 500 Mb when my
present OS only needs 120 Mb and does all I want it to do?

Thanks anyway for the description for upgrading to eCS.
Somebody else may need it.

Have a nice day,

Holger

---
■ MR/2 2.30 ■ This OS/2 system uptime is 327 days 10:15 hours (en).

* Origin: Coming to you from the Sunny Aland Islands. (2:20/228)

Am 26.11.07 22:35 schrieb Holger Granholm

In a message dated 11-24-07, Herbert Rosenau said to Holger
Granholm:

Thanks for the information Herbert. My present Warp 4 + FP12
occupies 120 Mb on a 170 Mb partition!

To fix that you would

............................

remove any partiton as needed to get free space to recreate the
new partitios - system with minimum 500 MB in size (better 2GB
to get yet the required size for eCS 2.0)

And why do you think that I would be interested in updating the
operating system to something that needs more than 500 Mb when my
present OS only needs 120 Mb and does all I want it to do?

Because you would need to access more current hardware as

full USB access - there is really nothing on WARP4 that works right
use tcp/ip 4.3 instaed of 4.0 - that means more functionality for
modern applications like seamonkey, thunderbird, firefox,
security fixes and so on
Ability to use up to 4TB files and logical drives with JFS
NOT to wait 8 or more hours on chkdsk after power failture or really rare now system crash with partitons bigger than 8 GB

Ability to get a system install from scratch on current and not oly really old mainboards and harddisks. Ability to get the install working directly from CD even with unsupported disk controller.

I've forgotten all the limits fallen with eCS.

Ah, yes, the minimum requirement of 500 MB does not mean that the 500 MB are full - it means only that the install process itself needs a really big disk space during install and will left about 250 MB free space after it completed. This free space will used in the running system for swapper, spooler and temporary files until you changes them to other disk.


--- Sqed/32 1.15/development 400:
* Origin: Kreuzpunkt und sonst nichts... (2:2476/493)