I have a stand-alone PC running Win-XP w/ 2 internal Hard Drives.  One 40GB (w/ Win install) & a formatted blank fat32 20GB hard drive for image destination.  Also a Win-7 box w/ a 250GB appx internal hard drive & a USB external about the same size.  All NTFS but the 20GB image drive in XP box.

I am able to use the GUI in Windows to reboot to Virtual Partition where autoexec.bat is scripted to image entire drive to spanned files on 2nd drive w/o prompts & then auto-reboot. I need a way to run from a batch file via sched task to reboot TO the Virtual Partition in DOS if possible w/o buying anything additional.  Work for County Government & $$$ not easy to eek out of them.

I have included by batch short of what the Virt Part creation puts in there like [ @echo off ] & altering the prompt to say "to reboot to windows, type ghreboot & press enter."  Pretty easy straight-forward stuff.

@ echo off
GHOST -CLONE,mode=Create,src=1,dst=D:\Image\testimg.img -Sure -Batch -Z9 -afile=ghosterr.txt

ghreboot

  ~Thanks

@ pushin1sAnd0s

NightOwl usually fields these questions and he should be along soon.

I don't know the answer regarding starting image creation from the Windows Ghost GUI. But I know you can create and restore Ghost 2003 images on a scheduled basis if you have an 8 MB FAT partition containing DOS files and ghost.exe. You can also copy this 8 MB partition and create a bootable file that can be run on a schedule. The 8 MB partition can be deleted once you have the bootable file.

@ pushin1sAnd0s


Quote:

I am able to use the GUI in Windows to reboot to Virtual Partition where autoexec.bat is scripted to image entire drive to spanned files on 2nd drive w/o prompts & then auto-reboot. I need a way to run from a batch file via sched task to reboot TO the Virtual Partition if possible w/o buying anything additional.

I don't know of any way to *schedule* the Windows based Ghost GUI to run.  Using the Windows Ghost *Virtual Partition* requires setting up the task manually in the Ghost GUI first--and there is no utility or script to automate that process that I'm aware of (but, thinking about that statement--I seem to remember there was some sort of ability to have Windows record a series of steps and save them as a batch file that you then can run and it would re-create those recorded steps--I never used it--and I don't know if it's still an option--may have been back in the Win98se era!).


Quote:

w/o buying anything additional

Ghost 2003 and Ghost 8.x are essentially DOS based--and can be set up to run from batch and script files--and you do not need anything additional to *buy*!  The *Virtual Partition* is really just a bootable primary DOS partition created in RAM on the fly by the Windows Ghost program.  And the Windows Ghost GUI passes the necessary Ghost DOS command line to carry out the procedure you set up in the Windows GUI onto that *virtual partition* once it's booted to DOS.

Without any further *purchases*, you can create a DOS primary partition on the system, make it bootable, and then create batch files to close down Windows, switch which primary partition is active and which is hidden, boot to the DOS partition with the needed Ghost script files, have Ghost carry out those scripts, and then have the Ghost autoexec.bat file re-set which partition is active and hidden and re-boot back to the Windows partition.

To *Schedule* everything, you would simply use Windows Scheduler to point to the batch file to start the process on whatever schedule you want.

Of course, the *devil is in the details*!  There are a lot of variables to keep track of--and several different *skill sets* that you have to get comfortable with--writing batch files in general, creating batch files that can change which partition is active and which is not, hiding and unhiding partitions for creating the active, boot partition, creating the Ghost script files to carry out your Ghost procedure, and using a Master Boot File Manager in a batch file for taking care of the details there!

And, if you plan on using the batch files on more than one machine, then, unless all machines are laid out identically, the batch file(s) have to be customized to each different layout.

Here's an example of how it could be done:  NightOwl's *automated* files

What's missing from the above reference--the batch file to start the process from Windows--I can help with that easily if you need help with that.  And, my above batch file keeps three backups, deletes the oldest when next run and adds the newest to the backup list--so it's a little more sophisticated than it would have to be--but, that can be easily adjusted as well.

Earlier in that reference, we discuss creating a bootable DOS partition to use for this technique.

Thx NightOwl, seems very do-able.  By the way, I didn't want to run the sched task from the Ghost GUI.  Your solution is the type of thing I was searching for.  Boot to virt part in DOS etc.

Brian mentions in his reply that once the bootable file is created that there is no longer need for the 8MB partition used to create the file.  If so, can 'partcopy.bin' reside on the boot/system drive?  [  C:\>  ]  it appears to be where this is going.  [ I hope ]  I can then point the scheduler to it & so-on as you describe.  I guess the missing "batch file to start the process from Windows" you mentioned & offered to help w/ comes into play here.

Many thanks for the info & the offer which I will probably need to take you up on.   :)

@ pushin1sAnd0s


pushin1sAnd0s wrote on Mar 14^th, 2011 at 11:15am:

once the bootable file is created that there is no longer need for the 8MB partition used to create the file.If so, can 'partcopy.bin' reside on the boot/system drive?[C:\>

Yes, it can reside in the C: drive. But this is just icing on the cake. It's easier to leave the small DOS partition in place unless you have a reason to remove it. I guess one advantage of partcopy.bin is you can just copy it to other computers and it will work. It is easy to edit the batch files in partcopy.bin for use in other computers. Alternately you can restore an image of the DOS partition to other computers and edit the batch files.

Are you familiar with TBOSDT? I didn't mention partcopy.bin in my first post.

@ pushin1sAnd0s

I'm enthused again. I've summarized my notes and this works.

Download this ISO and make a CD.
http://www.allbootdisks.com/downloads/ISO/AllBootDisks_ISO_Image_Downloads25/Win98SEnoram_bootdisk.iso   

Create an 8 MB FAT16 partition (anywhere on HD0, after the Windows partition) using a BING CD (or your favourite partitioning app). I currently have the FAT16 partition at the 40 GB mark and it boots.
Boot from the Win98 CD and at the A: prompt type sys C: (and press Enter) (check to make sure C: is the FAT16 partition before doing this)

Boot to Windows. Show Hidden Files. Show extensions. Show Protected OS Files.
Copy these files from the CD (data section) to the FAT16 partition.

autoexec.bat
config.sys
himem.sys

Delete drvspace.bin from the FAT16 partition.

Download ctmouse.exe from http://cutemouse.sourceforge.net/
Download the Zip format of v1.9.1
Unzip it and you only need one file. ctmouse.exe (dated 01 June 2003)
Copy ctmouse.exe to the FAT16 partition  (ctmouse isn't used in the following exercise but it is there in case you would like to do something manual rather than auto)

Copy ghost.exe (your Ghost 2003 file) to the FAT16 partition

Edit autoexec.bat to

@ECHO OFF
PROMPT $p$g
echo.
ctmouse.exe
ghost.bat

Edit config.sys to

DEVICE=HIMEM.SYS /testmem:off
DOS=HIGH,UMB
FILES=30
buffers=10

Edit msdos.sys to (you have to temporarily remove Read Only. Remember to tick Read Only after you have saved the file)

[Options]
BootWarn=0
BootWin=1
Logo=0

Download "MBR Utility" from http://www.terabyteunlimited.com/downloads-free-software.htm
Copy mbr.exe from the DOS folder to the FAT16 partition
This file is for the reboot from DOS to Windows

Create ghost.bat (in the FAT16 partition) containing your command line and a mbr line to auto reboot to Windows when the image has been created. For example...

ghost -clone,mode=pcreate,src=1:1,dst=2:1\winxp.gho -z1 -fx -sure
mbr 0 0 /a /reboot

Copy mbr.exe from the WIN folder of MBR Utility to the C: drive and rename it to mbr32.exe
Create a batch file in the root of the C: drive which will enable the restart into DOS. Type the following line.

mbr32.exe 0 1 /a /reboot 
(this assumes you only have two partitions on the HD)(If the FAT16 partition was the third partition the line would be mbr32.exe 0 2 /a /reboot)
This batch file can be scheduled to run at say 3 AM.

I just made a partcopy.bin and it works fine.

@ Brian


Quote:

Are you familiar with TBOSDT? I didn't mention partcopy.bin in my first post.

I think he read down to your post #48 in my above link NightOwl's *automated* files

Way back when, I never followed up and tried this TeraByte technique--but, I'm going to have to now..... ;)!

Do you know when you execute the *bootfile* command in Windows to load the *partcopy.bin* file, and you boot to the OS (that apparently does not need to use one of the 4 max partition table slots), can the files that are loaded in DOS--do they have the ability to *write* to the booted partition?

The reason I ask--you talk above about adding a DOS mouse driver (ctmouse.exe)--does it need a *mouse.ini* file associated with it?  One problem some folks have had in the past in creating a bootable optical disc with DOS files is that some versions of the DOS mouse driver require a *mouse.ini* file that the mouse driver creates on the fly as the system boots and loads the mouse driver.  The *virtual A:\ drive* created by an optical boot disc can not be written to, and so if there is not a *mouse.ini* file already included--you get a boot failure!

Also, if DOS Ghost experiences an error while booted from the optical disc's *virtual A:\ drive*--it attempts to write an *ghosterr.txt* file--again, if using Ghost booted from an optical disc, that fails and one doesn't see why--the system appears to *freeze*.

Just wondering if you have any insight into those issues?

@ NightOwl


NightOwl wrote on Mar 16^th, 2011 at 11:00pm:

you boot to the OS (that apparently does not need to use one of the 4 max partition table slots), can the files that are loaded in DOS--do they have the ability to *write* to the booted partition?

Yes. The virtual partition is writable. You can check the partcopy.bin later and the log file is present.


NightOwl wrote on Mar 16^th, 2011 at 11:00pm:

you talk above about adding a DOS mouse driver (ctmouse.exe)--does it need a *mouse.ini*

ctmouse doesn't use a mouse.ini and can be run from optical media without an issue.


NightOwl wrote on Mar 16^th, 2011 at 11:00pm:

-it attempts to write an *ghosterr.txt* file--

That would be written to partcopy.bin.

TBOSDT copies the DOS partition and creates a partcopy.bin. This needs to be run from HD0. When I first did this I ran it from HD1. Big mistake as my partitions disappeared. But running bootfile.exe from DOS brings them back.

Say you have partcopy.bin in C:\test. You have to copy the Windows bootfile.exe to that folder and also create a batch file containing...

C:\test\bootfile C:\test\partcopy.bin

So there are 3 files in the folder. Double clicking the batch file causes Windows to shutdown etc. If you have Win7 you have to right click the batch file and Run as Administrator.

This is another way of doing Method #1

Copy tbosdtw.exe from the win folder to the dos_tbos folder. Work from the dos_tbos folder.
double click tbosdtw.exe
type    list hd 0   (and press Enter)
write down the ID of your DOS partition. Let's say it is 25
exit

Create a text document containing (use your ID in place of 25)

copy partition 0 0x25 c:\partcopy.bin /b
mount 0: c:\partcopy.bin
copy file bootfile.exe 0:
set textline 0:\autoexec.bat "bootfile.exe" /b
exit

Save this as part.txt. Change the extension to run. Now you have part.run

Create a batch file called part.bat. It contains

tbosdtw.exe part.run

All these files are in the dos_tbos folder.

Double click part.bat and partcopy.bin will appear in C:\

A refinement to part.run. Use this...

copy partition 0 0x25 c:\partcopy.bin /b
mount 0: c:\partcopy.bin
copy file bootfile.exe 0:
set textline 0:\autoexec.bat "bootfile.exe" /b
interactive
exit

interactive is like pause in DOS. Make sure you see

Copying BOOTFILE.EXE...Complete.
               1 file(s) copied.

Then type exit to close the Command window.

You only have to make one partcopy.bin. To use it in another computer you simply need to edit ghost.bat, the file containing the Ghost command line.

Copy tbosdtw.exe and partcopy.bin to C:\ on the new computer.
Double click tbosdtw.exe and type these lines

mount 3: partcopy.bin   
copy 3:\ghost.bat C:\ /y

ghost.bat is now in your C: drive. Make the needed edits and type these lines to put the edited ghost.bat into partcopy.bin

copy ghost.bat 3:\ /y

To view ghost.bat inside partcopy.bin, type   (yes, you have to type "type")

type 3:\ghost.bat

Before using partcopy for the first time you should view autoexec.bat to make sure the first line is bootfile.exe

type 3:\autoexec.bat

After viewing the file, type

exit

The reason for having the first line of bootfile.exe in autoexec.bat is to change the MBR partition table back to your normal table. If bootfile.exe wasn't present, Ghost would run but then you wouldn't be able to boot into Windows because you would be in the virtual partition. To fix this, run the dos_tbos version of bootfile.exe from DOS or tbos. Simply type

bootfile

This has only happened to me once. The first time I used partcopy.bin. I used it from HD1 instead of HD0.

@ NightOwl


NightOwl wrote on Mar 16^th, 2011 at 11:00pm:

Also, if DOS Ghost experiences an error while booted from the optical disc's *virtual A:\ drive*--it attempts to write an *ghosterr.txt* file-

I deliberately created an incorrect Ghost command line in ghost.bat. ghosterr.txt was created in partcopy.bin and contained...

Date   : Fri Mar 18 12:46:43 2011
Error Number: (662)
Message: Cannot create image file
Version: 2003.793 (Dec 17 2003, Build=793)
Command line arguments: -clone,mode=pcreate,src=1:1,dst=4:2\winxp.gho -z1 -fx -sure
Active Switches :
       AutoName
       Sure
       Exit to DOS

@ Brian


Quote:

TBOSDT copies the DOS partition and creates a partcopy.bin. This needs to be run from HD0. When I first did this I ran it from HD1. Big mistake as my partitions disappeared. But running bootfile.exe from DOS brings them back.

Made me laugh!  Yes, that would probably make most folk's day appear pretty *bad*!  How did you figure out to use *bootfile.exe* to recover?

Haven't heard from *pushin1sAnd0s* recently--hope he's been taking notes!--this is some good info.....

Was out of town last couple days--started working on this this evening.......haven't finished following the outline as yet--ran into a couple issues--maybe you have insight(s)....


Quote:

Create an 8 MB FAT16 partition (anywhere on HD0, after the Windows partition) using a BING CD (or your favourite partitioning app). I currently have the FAT16 partition at the 40 GB mark and it boots. Boot from the Win98 CD and at the A: prompt type sys C: (and press Enter) (check to make sure C: is the FAT16 partition before doing this)

I had to make the new 8 MB partition *active* before the partition was available in DOS and I could do the *sys.com C:*.


Quote:

Boot to Windows. Show Hidden Files. Show extensions. Show Protected OS Files. Copy these files from the CD (data section) to the FAT16 partition.

What am I missing here?  I'm using WinXP.  When I boot back to WinXP after using PartitionMagic to create the 8 MB FAT16 partition (I had to make the WinXP partition *active* again, so the 8 MB DOS partition was now not active (and hidden--using PartitionMagic)--in WinXP I don't have access to that hidden 8 MB DOS partition.  How are you getting access to copy files?

So, out of computing time for this evening--I might not be available 'til Tuesday.

@ NightOwl


NightOwl wrote on Mar 21^st, 2011 at 1:01am:

How did you figure out to use *bootfile.exe* to recover?

TeraByte Support told me. David F. usually replies promptly to my emails.


NightOwl wrote on Mar 21^st, 2011 at 1:01am:

had to make the new 8 MB partition *active* before the partition was available in DOS and I could do the *sys.com C:*.

There must be something different with Partition Magic. I used a BING CD and didn't make the FAT partition active at any time. It was seen in Windows just like any other partition. It was a Type 6h FAT partition.

I'll try Partition Magic and let you know.

Edit....  PM wouldn't let me make a 8 MB FAT partition at the end of the 40 GB HD. But 16 MB was OK. I booted to WinXP and the partition was visible. Booted from a Win98 CD and did sys C: without a problem. Booted to WinXP and the partition was visible. We must have different hardware.

Edit again... In BING the FAT partition that PM said was at the end of the HD wasn't. It was immediately after the WinXP partition at about the 5 GB mark on the HD. BING called it a FAT12 partition, Type 1h.

@ NightOwl

I'm looking forward to you replicating my steps. It's nice when someone else confirms the steps are reproducible.

@ Brian


Quote:

I'm looking forward to you replicating my steps. It's nice when someone else confirms the steps are reproducible.

Okay, I'm back.  Been doing some testing to try to figure out what's what--this has not gone *smoothly*!


Quote:

Booted to WinXP and the partition was visible. We must have different hardware.

I'm suspicious that it's *different software* rather than hardware--but, haven't ruled it out as yet!


Quote:

Edit....  PM wouldn't let me make a 8 MB FAT partition at the end of the 40 GB HD. But 16 MB was OK.

Weird--my PM had no issue with the 8 MB FAT--what PM are you using--the boot to DOS version, or the Windows version--my version # is 8.02--and I used the DOS version to create the test 8 MB partition.


Quote:

Edit again... In BING the FAT partition that PM said was at the end of the HD wasn't. It was immediately after the WinXP partition at about the 5 GB mark on the HD. BING called it a FAT12 partition, Type 1h.

What?!  FAT12 is what's on floppy disks!  Something tells me BING and PM don't play nice with each other--don't the beginning and ending addresses have to be specific--how can there be a difference?

So, here's what I've found so far:

DOS PM's default behavior is to not allow more than one primary partition to be visible at one time.  If I selected the *Advanced* option to *unhide* the DOS partition while the WinXP partition was still visible and active, I got the following warning:


Quote:

Making this partition visible may cause drive letters to change.  Are you sure you want to unhide this partition?

After clicking *Yes*, then a second warning pops up:


Quote:

OS/2 and Windows 95/98 do not support multiple visible primary partitions.  If you unhide this partition, and then boot OS/2 or Windows 95/98/ME, data loss can occur.  Continue with unhide?

Once it was *unhidden*, now a reboot allowed it to be assigned a DOS drive letter *C:/* (it's the first DOS partition seen).  And, once booted to WinXP, it was now visible and in Disk Management, I could manually assign a drive letter to it so I could access it while in WinXP to do file copying, etc.

So, started making the partition changes you had outlined above, but I added to the TeraByte batch files for the *mbr* program a line to hide the OS partition that's not in use--similar to what the PartitionMagic (PM) program does when used to switch which partition is being booted.  The PM program *automatically* hides the previously *active* partition when you use the command to change the *active* partition to a different primary partition (I assume because of the above warnings regarding drive letter changes and possible data corruption).

I labeled my WinXP batch file *batch32*:

mbr32.exe 0 0 /h
mbr32.exe 0 1 /u
mbr32.exe 0 1 /a /reboot

Ran this batch file and booted to the DOS partition without any problem.

Then ran the batch file to get back to WinXP (I labeled it *batch16*):

mbr.exe 0 1 /h
mbr.exe 0 0 /u
mbr.exe 0 0 /a /reboot

Rebooted and about 2/3  of the WinXP boot processes occurred and then this:


Quote:

Autocheck program not found--skipping autocheck

And then immediately a BSOD!

Well, that wasn't good!  What I eventually discovered was the WinXP partition was still *hidden*!  (It's amazing that 2/3 of the WinXP boot process occurs without needing to actually access the partition data through *normal* channels before that error occurs!)  Once the partition was *unhidden* again, all was back to *normal*.

What I further discovered is that both the *mbr.exe* program for DOS and for Windows (mbr32.exe) do not have the ability to use the *unhide* command!  When run in DOS, or for the mbr32.exe program--in a DOS window (command box), you get the following response to *mbr.exe /u*:


Quote:

unknown option /u

So, why was I able to initially boot to the DOS partition successfully above?  Well, it was *unhidden* while I was working with it in WinXP--so it did not need *unhidding*--but, once it was hidden, then the TeraByte *mbr* program could not *unhide* it, and rebooting to the DOS partition failed!

(As a side note:  I'm now getting an error in my Windows PM interface--it fails to launch saying there is a *partition table error*!  I don't know if that occurred when I first created the 8 MB partition, or after subsequent manipulations--I have not yet attempted to troubleshoot that--but, I do not get that error when using the DOS version of PM.)

So, I will have to not *hide* anything--because if I do, I can't *unhide* it using TeraByte's *mbr* tool.  I may insert the *MasterBootWizard* tool instead.

Just about ready to try the next step using the TeraByte tool to create a boot file--but, out of computing time for now......more to come!

@ NightOwl

If I had known you were going to be adventurous with mbr.exe I would have given you a warning. Using multiple lines can give unpredictable results and using /h and /a together can give unpredictable results. I tried to use mbr.exe as a boot manager with hidden and visible partitions and I gave up. Keep it simple and it works. Anyway, neither WinXP or DOS need to be hidden from each other.

I used PM 8.05 from a boot CD. I'm just trying it again and still getting a 16 MB partition. It won't produce an 8 MB partition. At least the Status is None so there won't be any Active/Hidden issues. It is C: drive in PM as expected.
In WinXP now and the FAT partition is at the end of the HD (Disk Management). It has a drive letter in My Computer.
In BING now and it's a Type 14/Eh: FAT16 partition at the end of the 40 GB HD. Now that's better than last time.

Our PMs don't behave the same. I'm not getting any issues about Active partitions but then again my FAT partition Status is None. If I change the FAT Partition Status to Active in PM, WinXP becomes Hidden. If I then make WinXP Active, FAT becomes Hidden. I don't like PM. FAT partition can be changed back to a Status of None and everything is OK.


NightOwl wrote on Mar 25^th, 2011 at 1:22am:

Well, that wasn't good!What I eventually discovered was the WinXP partition was still *hidden*!

That causes


Quote:

Autocheck program not found--skipping autocheck

as you know.

   Had to abandon NightOwl's splendid idea due to my work wanting a faster solution even if more manual for the user.  [ Isn't that always the case :) ]  I've gone to Boot Disk solution which works fine on the XP box w/ a floppy drive, but I have a Win-7 Dell w/ 250GB internal HD & 250GB external HD.  I'm imaging the Internal drive to image files on the external [USB] drive.

[Need insight as to what Generic/SATA CD drivers I can use & what USB drivers Win-7 likes.  Won't use 'uhci.exe' or 'ohci.exe' which work in XP.]

    In AUTOEXEC, (on the CD), I placed 'pause' statements after each command while testing & I'm getting no drive found, (referring to the CD), & "Invalid drive specification". Startup files are as follows & thanks for taking a look at this...

(Files in CD boot sector attached as screen-shot.  All other files on root of CD such as Ghost.exe & DOS utils.)

    [CONFIG.SYS]
    DEVICE=HIMEM.SYS /testmem:off
    DOS=HIGH,UMB
    DEVICE=EMM386.EXE NOEMS
    FILES=30
    BUFFERS=20

    DEVICE=cd1.SYS /D:CDROM

    rem DEVICE=cd1.SYS /D:CDROM /P:1f0,14
    rem DEVICE=cd1.SYS /D:CDROM /P:170,15
    rem DEVICE=cd1.SYS /D:CDROM /P:170,10
    rem DEVICE=cd1.SYS /D:CDROM /P:1e8,12
    rem DEVICE=cd1.SYS /D:CDROM /P:1e8,11
    rem DEVICE=cd1.SYS /D:CDROM /P:168,10
    rem DEVICE=cd1.SYS /D:CDROM /P:168,9

    DEVICEHIGH=MTMCDAI.SYS /D:CDROM

    DEVICE=uhci.exe
    DEVICE=ohci.exe
    LASTDRIVE=Z
  _________________________________________________

    [AUTOEXEC.BAT]
    @echo off
    echo 1
    pause

    SET TZ=GHO+05:00
    MOUSE.COM
    LH MSCDEX.exe /D:CDROM /L:G
    echo Loading...
    cls

    echo 2
    pause

    echo Sets the prompt & path then Loads image task with parameters & launches image software.
    echo _

    PROMPT $t $d$_$p$g
    SET PATH=A:\;C:\;D:\;E:\;F:\

    echo 3
    pause

    echo Loading...
    G:\GHOST.exe -CLONE,mode=Create,src=1,dst=2 -Sure -Batch -z3
    echo Restart the computer. (Be sure to allow the restart process to begin
    echo before removing the CD from the CD Drive.)
    echo _
    pause

    REM shutdown /r /f /t 7

    REM GHREBOOT is not in the boot sector of this disk. Path statement must ensure accessibility to file wherever placed.  This is to restart the computer post backup!
    ghreboot.exe

---

@ pushin1sAnd0s

There you are--good to see you back!

You may have noticed Brian and I have been wondering around discussing various topics related to your original post--but wandering away slightly as well.....Brain's use of TeraBytes bootfile may be the *better* solution in the end--but, I've not reached that point yet.


Quote:

REM GHREBOOT is not in the boot sector of this disk. Path statement must ensure accessibility to file wherever placed.  This is to restart the computer post backup! ghreboot.exe

This caught my eye--did a search on the *ghreboot* and found this:  http://forums.techguy.org/all-other-software/987965-sata-cd-usb-drivers-win.html

So, that looks similar to your post here! Is it also yours?  (amazing what Google finds these days!)  Just mentioning it because I was so appalled by the response by *Evandel*--a *Moderator with 43,308 posts.*:


Quote:

I doubt very much that you will find drivers for DOS. The whole issue of USB drivers for DOS has been examined ad nauseam and no satisfactory, total solution was ever found before DOS went out of Windows in 2000.

Do *total solutions* exist for anything PC?!  But there are often *good workarounds* if you look hard enough!  Folks who haven't really looked into a particular matter and don't have some working knowledge of the issue(s), should simply say they don't know much about it--rather than making blanket statements such as this!

See:  Yes, there are USB drivers for DOS...

A Better USB 2.0 DOS Driver for Ghost + More!


The reason I searched on *ghreboot* was because of your *REM* statement:


Quote:

This is to restart the computer post backup!

*ghreboot*, to my knowledge, is used if you have booted your Windows system to the Ghost *virtual partition* and have become stuck there because the system will not re-boot from the *virtual partition* back to the origianl Windows Partition.  It might work *to restart the computer post backup*--but that was not its original primary function--which is why I Googled it to see if there was more info out there that I was not aware of.

There are DOS drivers for SATA Optical drives--see here:

GCDROM for DOS command line syntax

SATA optical drive & Ghost 2002 report

How to add SATA DOS optical drive drivers to Boot Disc

Download *gcdrom.sys* here--v2.3 and v2.4 available!

There has been a recent change (as of around 2009) in the USB controllers by Intel that has made most (all?) DOS USB drivers obsolete ( http://bretjohnson.us/ ).  But, I was daydreaming about how to work around that change this afternoon, and I might have an idea--but, not the time to test it out until tomorrow at the soonest.

How old is the Dell with Win 7 on it?  What chipset does it use?

NightOwl,
  As before, good to hear back from you.  Yes that was my post on Tech Guy.  I too was appalled by the answer I got.


NightOwl wrote on Mar 26^th, 2011 at 1:46am:

Quote: I doubt very much that you will find drivers for DOS. The whole issue of USB drivers for DOS has been examined ad nauseam and no satisfactory, total solution was ever found before DOS went out of Windows in 2000.

Virtually anything is possible, as you say, if you look hard enough for the answer.  Agreed, folks shouldn't comment on things for which they have little or no reference.

  I have been seeing the posts between you & Brian on my original question.  Wish I didn't have to give that up but I have 2 different PCs, running 2 totally different OSs, & they, (county government I work for), aren't willing to wait for the bugs to be worked out.  [ Everyone wants it NOW! these daze ~  >:( ]  I greatly appreciate the effort from the two of you though.

  So I have trained the users to pop the disk out in the AM & hit a key on a pause statement restarting Windows then popping the disk back in so that night's scheduled task will restart the machine again & create that day's image.

  But hey, I appreciate you getting back to me on the Win-7 issues I'm having w/ this.  Some info below...

- Win-7 box is less than 2 months old.  [from purchase date.]  While working on the 1st backup project, (XP-Box), I was told by the user that this was a Dell.  After checking I found out this was built by a local PC shop.
   Taken from PCs 'System Information'...
     * Manufacturer - Intel
     * Model - DH55TC
     * Processor - 3.2 GHz
     * Memory - 4GB

- Checking the DOS USB & SATA CD drivers.  Will get back as to outcome.

- REM statement on *ghreboot.exe* is 1st for the comment/description.  The actual reference to calling the file is not commented out.  ALSO, I have 'shutdown.exe' REM'ed out.  This is to give me ability to use either method on the fly.  *ghreboot.exe* seems to work more smoothly for me w/ Ghost.  It is intended for reboot from virtual partition as you stated but also works if copied to bootable floppy/CD to restart post-imaging.  This is working on the solution I have in place for my XP-Pro box.

  Again, I can't state enough how appreciative I am for your's & Brian's assistance.  This site by FAR has given me more pertinent information than all others I've taken this issue & run up the flag-pole.

~Thanks again - Will let you know how the drivers work out.

-Scott

@ pushin1sAnd0s


Quote:

Wish I didn't have to give that up but I have 2 different PCs, running 2 totally different OS

Quote:

So I have trained the users to pop the disk out in the AM & hit a key on a pause statement restarting Windows then popping the disk back in so that night's scheduled task will restart the machine again & create that day's image.

I thought you were trying to avoid asking the users to do the backup but if they can do it, fine.

Having two different computers with two different OS is no problem for partcopy.bin. It runs independent of the OS. You could make partcopy.bin on your home computer (it only needs to be done once) and later edit the command line (using PowerISO) to suit each work computer. You mentioned time issues which I can't understand as the whole project only takes minutes to complete. Except if you get adventurous.

Brian,
  Thx for getting back.  YES! I was feverishly trying to avoid user interaction.  However I'm having issue w/ External USB-HD & Internal SATA CD drivers in DOS & my employer doesn't want to wait much longer.

  I've been asked to provide a quick solution for now then I fully intend to continue pursuing the fully automated suggestions you & NightOwl have passed along.

  NightOwl posted the links to the Panasonic jp version drivers for SATA & USB-HDs.  Building that now actually.  I'll get back to you guys on the success of the virtual partition solution though once I can get back to it.

-Thx!