Copying OS2 to another drive
A. Willard Reese
to a removable hard drive using XCOPY X:\*.* /h /o /t /s /e /r /v,
will I be
able to boot from this drive (a primary partition in a hard drive
removable rack)? Assuming I add the new partition to my boot manager,
of course.
I guess my real question is: Will this XCOPY command transfer all the
files necessary to make the new partition bootable? And do I use the
same command to restore the partition?
Thanks,
Lorne Sunley
settings will refer to drive X:
This will cause LOTS of problems unless you go through all
the INI settings and change the X drive to whatever your
other drive letter is.
Usually this method is used to copy a working system to
a replacement drive.
The BOOTOS2 programs (available at hobbes) are probably
a better choice for this.
Lorne Sunley
On Thu, 31 Dec 1998 04:32:36, are...@bestnetpc.com (A. Willard Reese)
wrote:
Stewart Buckingham
> Can someone tell me? If I copy my OS2 partition from my master drive
> to a removable hard drive using XCOPY X:\*.* /h /o /t /s /e /r /v,
> will I be
> able to boot from this drive (a primary partition in a hard drive
> removable rack)? Assuming I add the new partition to my boot manager,
> of course.
> I guess my real question is: Will this XCOPY command transfer all the
> files necessary to make the new partition bootable? And do I use the
> same command to restore the partition?
> Thanks,
All you need to do is SYSINST to the new drive letter after copying and you'll
be able to boot from it.
Stu/2
Maurice Janssen
Yes, but only if the drive letter hasn't changed....
Maurice
--
Maurice Janssen | The best way to accelerate
| a computer running Windows
mau...@warp.xs4all.nl | is at 9.8 m/s^2
Will Rose
: Can someone tell me? If I copy my OS2 partition from my master drive
: to a removable hard drive using XCOPY X:\*.* /h /o /t /s /e /r /v,
: will I be
: able to boot from this drive (a primary partition in a hard drive
: removable rack)? Assuming I add the new partition to my boot manager,
: of course.
: I guess my real question is: Will this XCOPY command transfer all the
: files necessary to make the new partition bootable? And do I use the
: same command to restore the partition?
Yes, I did this the other day; however, the OS/2 installation is
drive-specific; you can't copy the setup used to boot drive D
onto drive E and expect it to work. Theoretically you should be
able to patch your way out of this, but in practice it's easier
to reinstall.
I added the new drive, booted from a floppy, ran xcopy, and then
removed the old drive so that the system had the same partition
set up as before.
Trevor Hemsley
->Hi,
->
->> Can someone tell me? If I copy my OS2 partition from my master drive
->> to a removable hard drive using XCOPY X:\*.* /h /o /t /s /e /r /v,
->> will I be
->> able to boot from this drive (a primary partition in a hard drive
->> removable rack)? Assuming I add the new partition to my boot manager,
->> of course.
->> I guess my real question is: Will this XCOPY command transfer all the
->> files necessary to make the new partition bootable? And do I use the
->> same command to restore the partition?
->> Thanks,
->
->All you need to do is SYSINST to the new drive letter after copying and you'll
->be able to boot from it.
SYSINSTX is only required if both source and destination drives are FAT.
If they are HPFS then the necessary boot code is already installed and
SYSINSTX is not required (but doesn't hurt).
Trevor Hemsley, London, UK
(Trevor-...@dial.pipex.com or 75704...@compuserve.com)
mike....@ziplog.com
Maybe you'll tell me to get a good red book and read it, which is OK
too, cuz I've never either been either aware enough or motivated enough
to try to dig all this out of the REDBOOK site, which is OK... However
other non-IBM utlilities do exist for disk maintenance and so the
following questions seem more than just a REDBOOK reading assigment! :)
If the HPFS comment above is true, then why after the conversion of a FAT 16
to HPFS with PMagic, is SYSINSTX required on the partion to make it
bootable?
I've never seen the message, "OS/2 is unable to run your ...", which I
can recall comment about. If I were to see this message, will SYSINSTX,
run after a boot from the untility disks, possibly solve this problem..
Is SYSINSTX really the same as the DOS operation SYS?
Exactly what does SYSINSTX do and what files does it COPY, from where to
where, and/or CREATE - where?
In a related way, what is the start order of what OS/2 does to bring up
the system, as a superimposed overlook of what all else is required
beyond the process spawned by CONFIG.SYS?
If a Master Boot Record (MBR) has been hosed, not by wrong use of FDISK,
but corrupted, in some other way, and you have replaced it from a saved
copy made by DTDISK, but the disk still won't boot, will running
SYSINSTX on top of that possible do some good. Assume that the .INI
files are intact and good.
Now, if the answer to that question is "Yes", but the INI files are bad,
will running UNIMAINT's restore of the Desktop, after the MBR has been
replacesd, then SYSINSTX has been run, if that's the proper order of
things, the perhaps fully restore a disk?
If you don't own GTDISK, is substitution of the use of FDISK for OS/2
with the /NEWMBR option (in comparison with /MBR for the DOS version),
likely to be a valid fix for the scrambled MBR part of this whole deal?
Conversely, can FDISK with the /NEWMBR option, leave you worse off than
before, somehow? It is possible, I know, from experience, to let GTDISK
attempt to recover a partion, only to be told during the boot run that
the partion is not bootable after you run it.
That said, obviously it poses the next question, if GTDISK is used to
REBUILD a partion of a hard disk that has not been re-written or
formatted over, because the creation of GTDISK.SEC for that disk was
*NOT* saved, to make it bootable then, do we simply run SYSINSTX on that
partition in order to finish the process?
Then, if the Desktop is still corrupt, can we recover it with UNIMAINT,
or, if necessary with the <ALT F1> and pick your poison approach out of
the last three archived desktops?
After doing all this, how can we clean up the various NOWHERE#'s
directories that seem to appear from salvage operations? Surely some of
them are useless! Is there a way, or a utility is UNIMAINTE or GTDISK,
that I've missed, or one out there otherwise written, that will go
through and aggregate/fix the multiple NOWHERE dirctory deal? On one
much-maligned development box I now have SEVEN (7) NOWHERE directories!
FREEDOM FILE, if loaded, only shows ONE of them, NOWHERE1..
Does that tell me that only ONE of them, the NOWHERE1 is in use, or,
conversely, that it is the only one that is NOT in use? Or does this
tell me nothing at all, really? Chuckle!
I know this all sounds like Lewis C and the discusion with the Mad
Hatter and the White Rabbit over watches...
but really, funny is, that in OS/2 *OUR* watch does tell the months!
In order to not get booted out from our system's, perhaps the answers to
the above, had I known them all, would have saved me from resorting to
my tape backup several times in the past...
I'll bet I'm not the only one here who could use the answers to the
above and, maybe, avoid doing something stupid or worse!
//-----------------------------
Mike....@ziplog.com
Mike....@f3000.n117.z1.fidonet.org
Trevor Hemsley
->In <geribeurzfyrlqvnycvc...@news.dial.pipex.com>, "Trevor Hemsley" <Trevor-...@dial.pipex.com> writes:
->>On 31 Dec 1998 07:13:06 GMT, Stewart Buckingham wrote:
->
->>->> Can someone tell me? If I copy my OS2 partition from my master drive
->>->> to a removable hard drive using XCOPY X:\*.* /h /o /t /s /e /r /v,
->>->> will I be
->>->> able to boot from this drive (a primary partition in a hard drive
->>->> removable rack)? Assuming I add the new partition to my boot manager,
->>->> of course.
->>->> I guess my real question is: Will this XCOPY command transfer all the
->>->> files necessary to make the new partition bootable? And do I use the
->>->> same command to restore the partition?
->>->> Thanks,
->
->>->All you need to do is SYSINST to the new drive letter after copying and you'll
->>->be able to boot from it.
->
->>SYSINSTX is only required if both source and destination drives are FAT.
->>If they are HPFS then the necessary boot code is already installed and
->>SYSINSTX is not required (but doesn't hurt).
[snip]
->
->If the HPFS comment above is true, then why after the conversion of a FAT 16
->to HPFS with PMagic, is SYSINSTX required on the partion to make it
->bootable?
Because SYSINSTX determines the file system type of the boot drive and
installs the right copy of the OS/2 boot file (OS2BOOT). This file differs
for FAT and HPFS which is why I said "if they are HPFS" meaning if they
are BOTH HPFS then SYSINSTX is not required since the right copy of
OS2BOOT is already installed.
->I've never seen the message, "OS/2 is unable to run your ...", which I
->can recall comment about. If I were to see this message, will SYSINSTX,
->run after a boot from the untility disks, possibly solve this problem..
Probably not. This usually means "I went to try to read a file I was
expecting to find on your boot drive and either it wasn't there or I got
an error trying". The most common cause of this is that you've installed a
new hard disk and defined a primary partition on it and you have OS/2
installed on a logical drive on the first physical disk. The new primary
partition has caused all the drive letters to shuffle up by one so OS/2 is
expecting to find itself on, say, D: when in fact it's now on E:. It can
also mean that you've installed a new driver for the controller that
operates your hard disk and it doesn't operate it<g>.
->Is SYSINSTX really the same as the DOS operation SYS?
Pretty much.
->Exactly what does SYSINSTX do and what files does it COPY, from where to
->where, and/or CREATE - where?
I think it reinstalls the first sector of the drive you point it at and
also the correct version of OS2BOOT though where it gets that from is
anyone's guess!
->In a related way, what is the start order of what OS/2 does to bring up
->the system, as a superimposed overlook of what all else is required
->beyond the process spawned by CONFIG.SYS?
Without consulting the books... the boot sector loads OS2LDR which loads
OS2BOOT which loads OS2KRNL which processes CONFIG.SYS which connects to
the thighbone.... I could be wrong on the order there (specially the last
one).
->If a Master Boot Record (MBR) has been hosed, not by wrong use of FDISK,
->but corrupted, in some other way, and you have replaced it from a saved
->copy made by DTDISK, but the disk still won't boot, will running
->SYSINSTX on top of that possible do some good. Assume that the .INI
->files are intact and good.
I don't think you can give a catch-all answer to this - if it's hosed then
you have to work out why and then fix it ;-)
[snip]
->After doing all this, how can we clean up the various NOWHERE#'s
->directories that seem to appear from salvage operations? Surely some of
->them are useless! Is there a way, or a utility is UNIMAINTE or GTDISK,
->that I've missed, or one out there otherwise written, that will go
->through and aggregate/fix the multiple NOWHERE dirctory deal? On one
->much-maligned development box I now have SEVEN (7) NOWHERE directories!
->FREEDOM FILE, if loaded, only shows ONE of them, NOWHERE1..
->
->Does that tell me that only ONE of them, the NOWHERE1 is in use, or,
->conversely, that it is the only one that is NOT in use? Or does this
->tell me nothing at all, really? Chuckle!
I suspect nothing at all. The only way I know of to find out which NOWHERE
directory is in use is to ask OS/2. In Melissa Woo's Stupid Tricks INF
file there's a rexx command given to open the nowhere directory. This
works in Warp 3 but last time I tried it in Warp 4 it didn't (it did
nothing at all). It runs
/* NOWHERE.CMD This REXX program does nothing dangerous. */
/* It simply opens OS/2 "no where" folder so that you can */
/* see the temporary or transient WPS objects. You will */
/* see them come and go as folders are opened and closed. */
/* Red balls with FS in them are un-named File System */
/* objects. From a note by Dan Kehn on IBM OS2BBS OS2WPS */
/* CFORUM July 12, 1993. --Lynn */
Call RxFuncAdd 'SysLoadFuncs', 'RexxUtil', 'SysLoadFuncs'
Call SysLoadFuncs
rc = SysSetObjectData("<WP_NOWHERE>", "OPEN=DEFAULT");
I suspect that UniMaint would be able to tell you too, in fact I'm sure it
can since I just had it do it ;-) Fire it up, look at OS2.INI scroll down
the application list 'til you hit PM_Workplace:Location then scroll down
the keys 'til you hit <WP_NOWHERE> and right click it and take "Explain".
For those too cheap to buy UniMaint and keep Larry in the manner in which
he's become accustomed <g> you can also use my IP Monitor 1.02
application. Right click the main window and take "Startup..." then scroll
down the right hand window until you hit <WP_NOWHERE> and then hit
"Identify...".
Now before you go ahead and blindly nuke something that the system
requires you should also be aware that the Maintenance Desktop uses it's
*own* copy of NOWHERE which is why you will _always_ have at least two of
them. I have no idea how you find out which one belongs to him but I
suspect that it doesn't matter as much since I believe he'll recreate it
if you ever boot to it. If this were my system I'd also have a complete
verified backup on tape before I touched them and I'd use Mark Kimes'
FM2Utils DELTREE from an Alt+F1 command prompt boot to get rid of the
extras.
Shmuel (Seymour J.) Metz
at 07:13 AM, Stewart Buckingham
<s...@ifyoureplyhereyoumustbestupid.com> said:
>All you need to do is SYSINST to the new drive letter after copying
>and you'll be able to boot from it.
Only for FAT.
--
-----------------------------------------------------------
Shmuel (Seymour J.) Metz, SysProg and JOAT
Atid/2
Team OS/2
Team PL/I
Any unsolicited commercial junk E-mail will be subject to legal
action. I reserve the right to publicly post or ridicule any abusive
E-mail.
I mangled my E-mail address to foil automated spammers; reply to
domain acm dot org user shmuel to contact me. Do not reply to
spam...@library.lspace.org
-----------------------------------------------------------
James Knott
"Trevor Hemsley" <Trevor-...@dial.pipex.com> wrote:
>->All you need to do is SYSINST to the new drive letter after copying and you'll
>->be able to boot from it.
>
>SYSINSTX is only required if both source and destination drives are FAT.
>If they are HPFS then the necessary boot code is already installed and
>SYSINSTX is not required (but doesn't hurt).
A couple of years ago, when I converted a Warp 3 FAT partition to
HPFS, I had to run SYSINSTX to make it bootable.
--
E-mail jkn...@ca.ibm.com
_________________________________________________________________________
The above opinions are my own and not those of ISM Corp., a subsidiary of
IBM Canada Ltd.
Will Rose
[...]
: Now before you go ahead and blindly nuke something that the system
: requires you should also be aware that the Maintenance Desktop uses it's
: *own* copy of NOWHERE which is why you will _always_ have at least two of
: them. I have no idea how you find out which one belongs to him but I
: suspect that it doesn't matter as much since I believe he'll recreate it
: if you ever boot to it. If this were my system I'd also have a complete
: verified backup on tape before I touched them and I'd use Mark Kimes'
: FM2Utils DELTREE from an Alt+F1 command prompt boot to get rid of the
: extras.
I blindly nuke any nowherexxx directories that I can see - the 'real'
nowhere directory is a hidden file in the root directory - and then
immediately shut down and reboot. So far my systems have always
survived, but I may be living dangerously. However, I've never seen
a second copy of nowhere; I thought all the maintenance stuff went
into \OS2\ARCHIVES.
Trevor Hemsley
->Trevor Hemsley (Trevor-...@dial.pipex.com) wrote:
->[...]
->: Now before you go ahead and blindly nuke something that the system
->: requires you should also be aware that the Maintenance Desktop uses it's
->: *own* copy of NOWHERE which is why you will _always_ have at least two of
->: them. I have no idea how you find out which one belongs to him but I
->: suspect that it doesn't matter as much since I believe he'll recreate it
->: if you ever boot to it. If this were my system I'd also have a complete
->: verified backup on tape before I touched them and I'd use Mark Kimes'
->: FM2Utils DELTREE from an Alt+F1 command prompt boot to get rid of the
->: extras.
->
->I blindly nuke any nowherexxx directories that I can see - the 'real'
->nowhere directory is a hidden file in the root directory - and then
->immediately shut down and reboot. So far my systems have always
->survived, but I may be living dangerously. However, I've never seen
->a second copy of nowhere; I thought all the maintenance stuff went
->into \OS2\ARCHIVES.
The Maintenance Desktop uses CONFIG.M when you boot to it and this
contains the lines
SET USER_INI=\OS2\INSTALL\INSTALL.INI
SET SYSTEM_INI=\OS2\INSTALL\INSTALL.INI
to point to other INI files. They also have their own nowhere directory. I
have two on my system and I can tell which is which by the date - Nowhere1
is dated yesterday, Nowhere is dated 6/6/97 and must belong to the MD.
Will Rose
: On 2 Jan 1999 16:18:49 GMT, Will Rose wrote:
: ->Trevor Hemsley (Trevor-...@dial.pipex.com) wrote:
: ->[...]
: ->: Now before you go ahead and blindly nuke something that the system
: ->: requires you should also be aware that the Maintenance Desktop uses it's
: ->: *own* copy of NOWHERE which is why you will _always_ have at least two of
: ->: them. I have no idea how you find out which one belongs to him but I
: ->: suspect that it doesn't matter as much since I believe he'll recreate it
: ->: if you ever boot to it. If this were my system I'd also have a complete
: ->: verified backup on tape before I touched them and I'd use Mark Kimes'
: ->: FM2Utils DELTREE from an Alt+F1 command prompt boot to get rid of the
: ->: extras.
: ->
: ->I blindly nuke any nowherexxx directories that I can see - the 'real'
: ->nowhere directory is a hidden file in the root directory - and then
: ->immediately shut down and reboot. So far my systems have always
: ->survived, but I may be living dangerously. However, I've never seen
: ->a second copy of nowhere; I thought all the maintenance stuff went
: ->into \OS2\ARCHIVES.
: The Maintenance Desktop uses CONFIG.M when you boot to it and this
: contains the lines
: SET USER_INI=\OS2\INSTALL\INSTALL.INI
: SET SYSTEM_INI=\OS2\INSTALL\INSTALL.INI
: to point to other INI files. They also have their own nowhere directory. I
: have two on my system and I can tell which is which by the date - Nowhere1
: is dated yesterday, Nowhere is dated 6/6/97 and must belong to the MD.
Very interesting. My archived desktop seems to be in \os2\archives\0x\desktop,
and config.m points to a desktop in <WP_MAINT> for which I can't find a
definition.