said:
Hi,
>Guess it's time to update my 'emergency' boot
>capability. I have been relying on the maintenance console in recent
>years.
A customized bootable CD is useful, but these days most can get by without
it. The eCS install CD is bootable and can do most of what a maintenance
volume will do.
>I am restoring the whole Desktop. The restore croaks on all kinds of
>stuff the WPS is using, mostly stuff in the system folder. Fonts,
>various things from the hardware manager, etc. I know you get the
>picture here.
Sure, what else would you expect? The vast majority of restore tools that
work do their job before the WPS is running and are limited to full
restores only. The Object Package restore tool is an exception because it
has a deep understanding of now the WPS works.
That said, object packages or REXX scripts are very useful for restoring
settings to a working Desktop if you understand when it is appropriate to
use them.
>I tried so many things I've lost track of exactly why this didn't work.
Probably the long line. Most things will restore. It takes some care to
avoid making the system busier than it needs to be.
>I'm trying to restore the desktop that is mangled on my T61 laptop.
One way to restore a mangled Desktop is to use the eWP Desktop restore
function. You did make a couple of these before embarking on your
experiments, didn't you?
I still prefer the Unimaint backup/restore tools, but the eWP restore will
work if the backups are good.
>So I
>am booting from the eCS rc6a CD and running it. Are you saying that
>since I'm booting from 'S:' it won't work because it is trying to
>restore to the CD?
That's one of several reasons it's not working.
The REXX scripts can only update objects of the currently booted Desktop.
If you look at the scripts it should relatively obvious that the restore
location is implicit.
>In prep for putting rc6a on my laptop I made object packages of the
>desktop (as an emergency backup and glad I did....if it worked).
This would not have been my choice of backup, but it may still work.
I recommend you at least skim the OD User Guide (odjduser.pdf). You
really should read the section on Object Packages in full. It explains
how to use an object package to do a full desktop restore.
You probably should read the section on the OD Backup Advisor if you
intend to use OD as a backup tool.
>entire drive C so I could restore if necessary. What I did NOT do is
>run checkini before I did all this stuff.
Ooops.
>For whatever reason, the restoration of the drive from the above
>mentioned drive copy fails because there is no wp_desktop in the .ini.
>Weird, but it happened.
This can be corrected. Add
set Desktop=c:\Desktop
to config.sys. Once you get the WPS to boot you can
>I have done this plenty of times before without
>incident but this time it croaked.
That's why everyone has heard my litany about the importance of knowing
your backups are good before you need them.
>So I took the obj. pkg desktop and created the .cmd file and am trying to
>fix the failed restore of drive C with this obj pkg.
Since you have a .pkg file which is probably good, you should be able to
use it to restore the Desktop. Just follow the procedures in the OD User
Guide chapter titled
Restoring An Object Package Containing a Workplace Shell Desktop
>I tried from the maintenance console of the eCS CD. If I understand
>correctly, you are telling me this won't work because C: has to be the
>booted drive. Is that correct?
Yes. This is a limitation of the method you are using. Other tools don't
have this limitiation.
>When I booted to C: w/ protshell=cmd.exe and ran the
>script it didn't work.
Yes, because neither REXX support or INI file support is loaded. You can
get REXX support loaded for a command line boot, but you can not get INI
file support loaded, TTBOMK.
>Anyway, sorry for the long dialog, your last comment has left me
>uncertain about whether I am trying to do the impossible by running the
>script while booted from the CD.
It's possible, but not with the tools you are using.
The good news is that you might have wasted a lot of time, but by using
the proper procedures, you should be able to get a useful restore. This
assumes you have not done too much damage to the rest of the install.
FWIW, there was never any reason to destroy you working production volume
just to try out a migration. The easy way is
- clone C: to another volume
- hide the production C:
- rename the cloned volume to C:
- adjust boot manager
If things don't work out, hide the bad C:; unhide your production C:;
adjust boot manager and you are good to go.
It's best to do the clone whle booted to some other volume, but on a quiet
system, you should be able to clone C: while booted from C:. You will
know when you try to boot the clone.
Steven
--
----------------------------------------------------------------------
"Steven Levine" MR2/ICE 3.00.11.19 BETA #10183 eCS/Warp/DIY/14.103a_W4 etc.
www.scoug.com irc.ca.webbnet.info #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
"postmaster@scoug.com".
=====================================================
>> Next Message >>
Return to [ 18 |
December |
2008 ]
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.
