The latest Image for Windows (TeraByte Unlimited) allows this.

You can schedule a restore for 3 am and when you wake in the morning you are looking at the desktop of your restored OS. It doesn't do a "better" restore than what you do manually but it is so easy and convenient. Instead of using a scheduled task you can just double click a batch file to start the restore process if you want it done immediately. No boot CDs are used and the backup image resides on a HD.

Has anyone seen a similar process with other software?

Brian, very interesting - I am unaware of any other image backup product that can do an unattended restore.  Have you tested this?  It works well?

By the way, have you seen Reply #110 in this thread?  It is an admission by TeraByte Unlimited that their PHYLock product can’t necessarily guarantee a consistent “hot image” snapshot.  That is very worrisome, since the quality of the restore is dependent upon the integrity of the backup image.

wrote on Feb 18^th, 2008 at 4:19pm:

Have you tested this?  It works well?

Pleo, it's a method I worked out. You won't find it in the userguide.

Regarding PHYLock..


Quote:

This is true of ALL backup software that is backing up a volume that is in use.

I think TeraByte Unlimited is just being honest and is not implying they have an inferior (or a superior) product. It's an issue for all hot-imaging software. In his discussion on quality of image backups, Nate (from StorageCraft) answered a question you asked.


Quote:

So the order of quality of backups is this (Best quality first): a) Cold-state backup.  Such a backup is taken when the volume is locked.  It's usually best to only lock volumes when they are not in use by applications so as to not interrupt application services.  Therefore it's generally the case that cold (locked volume) backups are only taken from within the booted Recovery Environment. b) VSS snapshot-based backup.  In such a backup, VSS will quiesce any VSS-aware applications and flush the file system prior to establishing the snapshot.  The backup image may capture files in a partially-modified state for applications which are not VSS aware. c) Non-VSS snapshot-based backup.  ShadowProtect's snapshot driver will flush the file system prior to establishing the snapshot.  Application files that are in-use may contain partially-modified entries.  This backup state is cleaner than a "crash state" backup because the file system itself is flushed. d) Crash-state backup.  We currently don't have any tool that captures your volume in this state, but we use it as a descriptive reference.  The state of your volume at the time you pull the power plug on your machine is the "crash state," and if you were to have a backup image of your volume in this state it would be a "crash state" backup.  For many users, this state is quite workable as long as they're using a journaling file system such as NTFS.

Brian


Quote:

it's a method I worked out. You won't find it in the userguide.

Interesting...but lacking in *details*  ;) !


Quote:

Has anyone seen a similar process with other software?

I have *created* a method for Ghost 2003 that is also *automated*.  I've not *scheduled* it, but it's a *click one button* batch file that takes the system through whatever Ghost process you want to perform without further intervention.  If a call to the batch file was placed in the Windows Scheduler--you could then have it run at a particular time!

It requires an imaging program that can be controlled by command lines (such as DOS Ghost).  It uses a hidden partition with the *automated* Ghost command lines that are carried out in a re-boot to the DOS OS, and then it returns you to the Windows OS.  I'm using Master Boot Record programs to switch which primary partition is active and/or hidden + commands to re-boot the system.

Brian

I saw your response to my above reply--but the move to the new server did not include several recent posts after about 8:00 am, Tues 2/19 local time here--and yours was one of those!

But, I don't think you *stole* my idea--looks like we developed a very similar approach, but using somewhat different technique because we're using different imaging software.

I presume *Image for Windows* must offer the ability to run it from a batch file using command lines--or must have some internal automated option for setting up an automated process that can be called by a scheduling program.

NightOwl,

My post disappeared in the changeover. I'm delighted that we both used basically the same technique. I didn't think it could be done from DOS as I thought you would have had to click OK somewhere along the line. I've used the same technique with Drive Snapshot and there is an OK that I can't get around, immediately before the restore.

As mentioned I have two WinXP OS and I knew I could restore an OS image from one OS to the hidden OS. This can be done with any of the hot imaging apps.

IFW can be run from a command line and has an array of switches. I used two batch files. One to reboot WinXP1 to WinXP2 and the other to run the IFW restore and to reboot to WinXP1. It even works if the second OS is Win98.

Running it as a scheduled task is interesting but practically I just double click the first batch file to start it off. It is the method I now use for my restores.

NightOwl wrote on Feb 19^th, 2008 at 9:50am:

It uses a hidden partition with the *automated* Ghost command lines that are carried out in a re-boot to the DOS OS, and then it returns you to the Windows OS.

NightOwl,

Is your backup image stored inside the hidden partition? What is the hidden partition? MS-DOS?

Brian

It's a small DOS primary partition on my primary HDD--I do not store the images there--those go to the secondary HDD--but, I could have made the partition larger and stored images there--but if my primary HDD fails (that's the one I'm backing up!), then my backup images would go with it!

Also, I prefer *whole HDD* backups--so I couldn't store the image there unless I did *partition* only backups.

It could probably be as small as 10 MBs, but I usually make it 100 MBs and place a number of other DOS utilities on it as well.

I use PartitionMagic to shrink my last partition on an existing HDD, and create the primary at the end of the HDD--I'm not needing HDD access speed for a small DOS imaging program like Ghost--it's loaded into RAM instantly.

NightOwl,

I used your technique to restore images using Image for DOS. Unattended. Nice and easy.

A few questions. Can the DOS partition be anywhere on the HD? DOS wouldn't boot when I had the partition at the end of the HD.

I know you can image and restore the DOS partition but can you restore the image to another computer? I wouldn't expect restore problems like we see with WinXP and I'm just thinking about saving a little time if I can avoid juggling floppies for the install.

Brain


Quote:

Can the DOS partition be anywhere on the HD? DOS wouldn't boot when I had the partition at the end of the HD.

I've put the primary DOS partition at the very end of the HDD--at least on older systems, it has to be the HDD on the Primary Controller, and the master HDD--I have not worked with newer systems that allow you to choose which HDD to boot from.

I've done it now on three different systems--being at the end has not been a problem--has to be a primary partition--and not inside an extended partition--although, I think you can get around that if you use some of the third party boot loader programs that Dan Goodell has discussed at his website.


Quote:

I know you can image and restore the DOS partition but can you restore the image to another computer?

I have done this on two systems so far!  I have created an image of the primary DOS partition with the boot files and utility programs--and simply restored it to the available space created for it on the destination HDD.  If you have created automation command lines, then you have to be sure the partitions are laid out the same as the command lines point to on the source on the new destination system--or you have to adjust the command lines to match the new system.  

NightOwl,

Most helpful. I've been using BING as the boot manager and I just found a link on the TeraByte site that says BING requires the DOS partition to be within the first 8 GB of the HD. That's what confused me before.

I restored an image of the DOS partition (taken from a test computer) to a 55 MB partition on the second HD of my main computer. It boots fine using the BING "swap" option. (I've removed my old batch files for the time being)

It's very interesting. As you know I've avoided DOS in the past. A late adopter.

I haven't tried installing DOS to a logical volume as my volumes are well beyond 8 GB. I'll try later on a test computer.

Brian


Quote:

I've been using BING as the boot manager and I just found a link on the TeraByte site that says BING requires the DOS partition to be within the first 8 GB of the HD.

Interesting!  As long as you are experimenting--you might want to determine if that statement is *outdated*--it might be!

The PartitionMagic User Guide also talks about 2 and 8 GB limits for booting depending on what DOS dependent OS is being used.  Some time after the release of Win98se (DOS based OS), there was an update so the system was no longer bound by that requirement that the boot files had to be within that 8 GB limit.

Before I started using WinXP, all my primary partitions were 2 GB each--so they stayed well below the 8GB limit (Win98se's footprint was small!).  When I started dual booting and experimenting with WinXP, I expanded the size of the primaries to 4 GB each--so the second and third primary extended past that 8 GB limit--and I couldn't boot my Win98se if it was in the second or third primary--I wanted to leave the first two primaries for WinXP experimenting.  So, I could restore the Win98se to that first primary and it booted fine--second or third primary--no boot!  If I adjusted the partition size of the second primary so it stayed below the 8 GB limit--then Win98se booted fine from the 2nd partition also.  And WinXP also showed the same behavior!!!

At the same time, I was trying to find out why when I restored my WinXP image using Ghost 2003 to my physical 2nd primary (when I had adjusted it below the 8 GB limit), I could not boot successfully--but if I used PartitionMagic's copy function to place my working, booting WinXP onto that 2nd partition from the first partition, it booted fine (you may recall, I have a Master Partition Table that has the sequence of partitions listed out of order vs how the partitions are laid out physically on the HDD--and Ghost, without documentation or warning--makes changes to the *boot.ini* file based on what it thinks is the correct boot partition for WinXP images--and it's got a bug and chooses the wrong partition to point to in the *boot.ini* file!)!  So, I was attempting to use TeraByte's *editbini.exe* to access and view the *boot.in* file--but that program would also fail--I could not access the *boot.ini* if WinXP was on the second or third partition (  TeraByte Unlimited Freeware--See *EditBini* ).

Well, sorry for that long intro--the long and short of it is:  It's the Master Boot Record that's installed in sector 0!!!

I inadvertently stumbled on the fix for the above issue with non-booting if the partition extended beyond the 8 GB limit by running the WinXP Recovery Console command:  fixmbr

XP: Repair or fix master boot record using recovery console

This replaces the MBR that you originally placed on the HDD from whatever source with the WinXP's version of the MBR (it does not change or corrupt the Master Partition Table)--and now there was no limit on where I place the primary boot partition--even at the end of a 120 GB HDD--and TeraByte's *editbini.exe* began working just fine!  And Win98se could boot from a primary partition that was well beyond the 8 GB limit too!!!

I had used the Fdisk program from the original Win95 recovery disk, and apparently it has that 8 GB limitation--I think it might be the Fdisk from WinME that resolved that problem--I've never gone back to work out which version fixes the issue--and I don't know what MBR is created by other partitioning tools like PartitionMagic, etc.

But, if you use Dan Goodell's trick to clear up the drive letter assignments for WinXP--your MBR will be based on whatever version of Fdisk you are using--and it may not be up to the task of allowing booting beyond the 8 GB limit if it's an earlier version!!!

Dan Goodell has made the comment in earlier threads on the forum that the version of the MBR isn't really *critical*--any version of Windows will boot regardless--well, that's a partially correct statement until you try to boot from a partition that's beyond the 8 GB limit--and you are still using the original software programming for the MBR--if you never put a boot partition beyond the 8 GB limit--or you are using a *boot loader* that is by a third party--then maybe the MBR doesn't matter--but I wonder if the *boot loader* may have similar issues if it's an older version of the MBR that was originally used--I don't know.

There's something in the programming of the MBR that determines if the system will be able to boot from a primary partition beyond the 8 GB limit--I'm sure it has to do with *seeing* and being able to access boot files on a *large HDD*--but, I don't understand the details!

NightOwl,

Some interesting and confusing results. Here is the link on booting DOS with BING. I can confirm that it is correct on my old test computer.

http://www.terabyteunlimited.com/kb/article.php?id=123

I had BING installed and one DOS partition at the start of the HD. I copied (cloned) this partition so that number 2 DOS commenced at 5 GB, number 3 DOS commenced at 7 GB and number 4 DOS commenced at 9 GB. The first three booted and the last didn't. There was just a flashing cursor underneath 3 dots.

I then deactivated BING and using Partition Magic made the first partition Active. It booted. Then using the Recovery Console (WinXP) I ran fixmbr.

The first DOS booted. Using PM, I made each other partition Active, in turn. DOS 2, 3 and 4 wouldn't boot. The error was "Non-System Disk or disk error".

I then installed DOS (over the top) to the second partition. No problems with the install but it wouldn't boot. "Non-System Disk or disk error".

I tried fdisk /mbr. DOS 1 booted but the other three partitions still failed to boot. "Non-System Disk or disk error".

I reactivated BING and the first three partitions all booted. The fourth at (9 GB) wouldn't.

I then deleted DOS 2, 3 and 4 and cloned DOS 1 into a logical volume inside an extended partition. This partition commenced 2 GB from the start of the HD. I tried to boot this with BING and saw "Starting MS-DOS" but there was a flashing cursor underneath and no progression.

So, some unexpected results. Maybe I shouldn't have started this.  

Brian


Quote:

Maybe I shouldn't have started this.

Oh, but that's what makes *messin* with computers fun!!!

I don't have those system any longer--they are friend's systems and they are at their respective owner's places.

I will see if I can re-configure my system to see if I find any problems.

How did you create a DOS boot partition--what steps and software did you use--that might suggest what we may be doing different?

More. I zeroed track 0 and created a 50 MB FAT partition at the start of the HD with Partition Magic, made it active and installed DOS 6.22 from the three floppies. Easy.

I zeroed track 0 and created a 50 MB FAT partition at 3 GB into the HD, made it active and tried to install DOS. After the format stage I saw "Setup cannot install MS-DOS 6.22 on your computer". I tried at 5 GB and received the same error.

So I can't install DOS to any partition that isn't at the start of the HD.

I don't know why our results differ. Don't spend too much brain power on this. It's not critical.

PS I just tried an install at 1 GB and it worked. I guess I have a 2 GB barrier. Perhaps an old BIOS??? It's a Pentium 3 computer.

Brian wrote on Feb 27^th, 2008 at 1:31am:

So I can't install DOS to any partition that isn't at the start of the HD.

Brian, I can't remember all the details anymore, but as I recall, years ago the boot partition had to be located within xx megabytes of the beginning of the disk drive.  It was a bios and DOS issue with pc's at the time because there wasn't enough room in the offset to hold a value greater than yy in size.  Then Logical Block Addressing came along and you could have your boot partition further away.

I remember that Partition Magic gave you a warning if you tried to move your boot loader/partition further away from the beginning.

If I find a reference to the exact details, I'll post it.

In the "good ole days" drives were only 20 or 40 megabytes total.  Actually I remember having one of those drives.  I was so happy.   :)

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/multi-os/x191.html

Brain


Quote:

So I can't install DOS to any partition that isn't at the start of the HD. I don't know why our results differ.

I think I do!  I have never tried to actually *install* DOS--especially v6.22--to a bootable partition--that was the latest update used back with Win3.x--and I think the only file system supported may have been FAT16!

I looked back at one of the Ghost images I created of the *Ghost Boot Partition* that I have been putting on my friends' systems--and it's FAT32!  And I made the DOS bootable partition using a Win98se Emergency Recovery Disk (ERD).  It has the DOS program *sys.exe* (edit:  it's *sys.com*), which you use to make a floppy disk or HDD bootable.  And, Win98se's DOS is able to work with FAT32 partitions, apparently, because that's what I've been using.  I bet DOS 6.22 can not work with large HDD geometries--may not be LBA aware--and that may be the source of your boot limitations!  Does BING require FAT16--or will it work under FAT32?

I use PartitionMagic to create a primary FAT32 partition (on my older systems--it has to be on the HDD that is master, on the primary controller), make it active, boot from the floppy Win98se ERD disk.  The FAT32 partition will be C:\.  Use the *sys.exe* (edit:  it's *sys.com*) program with this command at the A:\ prompt:  sys.exe a: c: (edit:  it's sys.com a: c:) to transfer the needed DOS system files being used on the floppy disk to the C:\ HDD partition.  Add whatever DOS boot files are needed for your programs on that partition--and any DOS utilities.

Boot Disks  I use Win98se OEM.

(By the way, one can not use the WinMe boot disk--the *sys.exe* (edit:  it's sys.com) program on that boot disk will give you an error if you are trying to create a bootable HDD partition--will only work on creating bootable floppy disks!  DOS for WinMe must have changed--don't know the details!)

http://www.gnu.org/software/parted/manual/html_chapter/parted_4.html#SEC45


Quote:

Note: LBA addressing is not supported in MS-DOS 6.22 and lower, as well as all versions of PC-DOS. Warning: some BIOSes won't enable LBA addressing, unless you enable it in the BIOS as well. If for some reason, Windows doesn't boot after changing this flag, this is probably the problem. the "real" MS-DOS (i.e. up to version 6.22) and MS-DOS 7.0 (i.e. Windows 95/95a) don't know about FAT32. It's therefore possible to boot them from the second fat (FAT16 only, of course) partition, when the first fat partition is FAT32. Both have to be primary partitions, so you'll have to set the one you want to boot from as active partition.

Ghost4me

That pretty well confirms our previous suspicions--thanks for the input!

NightOwl wrote on Feb 27^th, 2008 at 9:59am:

Ghost4me That pretty well confirms our previous suspicions--thanks for the input!

I don't know if the dos boot problem is resolved now with newer motherboards.  It was definitely a problem with the old pc's.  You probably remember that there were lots of bios updates targeted at support of newer lareger hard drives on older pc's.

I guess a lot depends upon how old Brian's pc is.

Ghost4me,

It is a Compaq Pentium 3. Probably year 2000 vintage. It has 240 head geometry. It was my brother's computer so I'll bet it has the original BIOS.

I'm glad you can recall those historical details because the solution is now falling into place.

NightOwl,

FAT32 did the trick. I used your instructions and created partitions at 3 and 9 GB from the start of the HD and also one at the end of the HD. Used sys a: c: (it didn't like .exe). All three booted using Partition Magic to set the active partition.

BING was then installed. The partitions at 3 GB and at the end of the HD booted. The partition at 9 GB wouldn't boot (error was Invalid system disc). I created another partition at 11 GB and it wouldn't boot.

Well, I think we have resolved my issue. Of interest is I didn't have to use fixmbr. The Win98 MBR was sufficient.

Thanks to both of you.

Brain

Glad to help!


Quote:

Used sys a: c: (it didn't like .exe).

My bad!  It's sys.com!


Quote:

BING was then installed. The partitions at 3 GB and at the end of the HD booted. The partition at 9 GB wouldn't boot (error was Invalid system disc). I created another partition at 11 GB and it wouldn't boot.

Weird--boots at the end, but not in the middle!  How big is the HDD--where at the end did you put the primary partition that did boot?

The HD is 20 GB. The partition was at the very end. No space after the 50 MB partition.

I think if the boot loader is close enough to the beginning of the drive, you are ok.

I found a reference to the hard drive size bios boundaries.  Kind of interesting historically speaking.  The first boundary that had to be overcome was any hard drive larger than 528 MB, which required a bios update.  Then as they got larger, new boundaries appeared.  Here is the intersting article that summarizes everything:

Hard Drive Size Limitations and Barriers
http://www.dewassoc.com/kbase/hard_drives/drive_size_barrier_limitations_2.htm

I now have two WinXPs on that HD and I created a FAT32 DOS partition at the end of the HD. BING is installed and DOS boots. I cloned the DOS partition and positioned it at 9 GB from the start of the HD. It boots.

I give up. Now BING can boot DOS (FAT32) from anywhere on the HD. It couldn't when the WinXP partitions weren't present. Each WinXP partition is 2 GB.

I moved that DOS partition to 14 GB and it still boots.

Brian wrote on Feb 27^th, 2008 at 4:25pm:

I give up. Now BING can boot DOS (FAT32) from anywhere on the HD. It couldn't when the WinXP partitions weren't present. Each WinXP partition is 2 GB.

When you install WinXP, you get the associated MBR, which knows about the convention for the partition table structure where the partition start address is specified as LBA and therefore uses the LBA-mode INT13X API (where it exists, as it must if the LBA-type partitioning convention is used).

Remember that Win2000 and above use a different method of storing their drive identifiers than Win9X did - their MBR code is different, and thus the location of the 4-byte "hole" in the code where each team slipped in a few bytes of signature information is different. The newer MBR always wins since 9X wasn't actively using its drive signatures the way Win2000 and above do, where they aren't optional.

wrote on Feb 27^th, 2008 at 8:28pm:

When you install WinXP, you get the associated MBR, which knows about the convention for the partition table structure where the partition start address is specified as LBA and therefore uses the LBA-mode INT13X API (where it exists, as it must if the LBA-type partitioning convention is used).

Now, I have questions!  I think Brian may not have *installed* WinXP, but used an image to *restore* WinXP--how about that, Brian?

When I first started using WinXP, I installed it to an available unallocated space by creating a new primary partition on a HDD that was running Win98se exclusively--and, I had made the mistake way back when I first installed Win98se of using Fdisk from Win95 to begin the partitioning process.  I discovered that Fdisk did not work correctly after creating one or two partitions--so I deleted them, and started over with the Fdisk from WinME which did see the correct size of the HDD now.  But, apparently the WinME Fdisk never changed the MBR that had been created initially by the Win95's version of Fdisk!

But, as described earlier in this post (Reply # 11)--I had all sorts of boot problems after I installed WinXP--the MBR wasn't working correctly if I made my partitions larger so they went past the 8 GB barrier.  So, at least for me, installing WinXP did not correct my MBR inability to boot correctly anywhere on the HDD!  It wasn't until I *accidently* used the WinXP Recovery Console and ran *fixmbr* that everything suddenly started working correctly!

Brian

Did you use TeraByte's Image for DOS to restore WinXP partition images to those partitions--or did you do an install?  

Did you use PartitionMagic to create the partition structure initially?  Did you create NTFS partitions for WinXP?  What I'm getting at is what was the initial MBR that this HDD started with?

And how exactly did the MBR get *altered*?!  My experience has been that the MBR is a *hands off* area by most partitioning tools, and OS installation discs if the MBR already exists--you have to do a specific command with an MBR tool to have it altered--like *Fdisk /mbr*, or WinXP's Recovery Console's *fixmbr*.  Otherwise, to get partitioning tools to alter the MBR, you have to zero sector 0 so they see the HDD as *empty*, and then they will step in and make a new MBR!

Oh, man--my head hurts--too many variables (that are hidden from view and you are not allowed to see and manipulate--things are manipulated for you in the background and you don't know what's happening when)!!!!!

NightOwl wrote on Feb 27^th, 2008 at 10:13pm:

And how exactly did the MBR get *altered*?!  My experience has been that the MBR is a *hands off* area by most partitioning tools, and OS installation discs if the MBR already exists

The rules for this kind of thing are pretty ad-hoc, and to be honest I wouldn't try and second-guess what combination of rules all the pieces of software around have used.

The main thing is that somehow he's ended up with an MBR of the right generation that is aware of the modern conventions for using LBA-mode BIOS APIs.

It took a lot longer for Microsoft to switch over to using the extended BIOS APIs in the MBR simply because there isn't enough room in a one-sector MBR to code in a lot of alternatives. Remember that one of the big changes in FAT32 was that the boot code in the BPB expanded to 3 sectors, and the MS-DOS FAT32 secondary boot was able to use that space to do things like more capability probing of the BIOS to determine which API set to use. The MBR never had that luxury.

That, incidentally, is why PC-DOS as bundled in Ghost sometimes doesn't boot on some machines; it uses basically the same one-sector BPB secondary boot for both FAT16 and FAT32, and if it's booting off a hard disk it simply assumes that not only does INT 13X exist, it relies on it to comply with the API spec (which some BIOSes fail badly at, overwriting registers the API spec says they must not). Microsoft's larger secondary boot code is, by virtue of taking up more room, able to have more kinds of safety features coded into it to allow it to work around some of these problems.

NightOwl wrote on Feb 27^th, 2008 at 10:13pm:

I think Brian may not have *installed* WinXP, but used an image to *restore* WinXP--how about that, Brian?

Correct. I used TeraByte's IFD to restore the first WinXP and I cloned that into WinXP2 (in BING). But let me work out when BING was installed.

Initially I zeroed the first track and then used PM to create the three FAT32 partitions. All booted after sys C:

BING was then installed and the middle OS wouldn't boot.

The WinXP image was restored and then cloned. Now all DOS OS booted. (I deleted one before cloning WinXP)

However, I don't have a WinXP MBR. BING installs its own MBR and when you look at LBA-0 in a Disk Editor the BING MBR looks quite unique. The text at the right hand side is all about TeraByte.

I'm lost. Please continue the discussion.

I've just read Nigel's last post. It may be relevant that BING has code in the first 8 sectors. Sectors beyond LBA-0 are called an EMBR. Extended MBR.

Brain

So, it's actually the *BING* MBR that is present--when you install BING, it replaces the MBR that was previously there--and you did not uninstall BING--just added the WinXP restored images?  And that made BING work...huh--interesting!

And, TeraByte's FAQ says BING doesn't work past the 8 GB barrier!  Well, PartitionMagic's User Guide has similar statements saying you can't boot a DOS partition--but, then they copied and pasted a table that says an updated Win98se is capable of booting beyond the 8 GB barrier--gotta love technical writing and proofing--should be called *spoofing*!!!!

I was using BING as a boot manager and also for its partition cloning ability. It does a heap of other things as well.

It may well be that BING itself isn't really doing the heavy lifting; I couldn't say for certain since I don't have (and I'm not going to get) the tool, but once it does whatever things it does as a "front end", it could well be that once it gets to the point of actually booting a partition,it loads in one of the standard MBRs into memory, sets it up with the partition table it wants it to see, and then lets it go as if it had been loaded from the BIOS instead of by a front-end wrapper.

[ That may not be how it works, but that'd be my first instinct if I was to write such a thing, since it would be the most compatible with whatever was already on a system in the first place and custom MBRs are becoming quite common again. ]

If that were the case, then it would share whatever features or limitations existed in the MBR it was wrapping around. A known-bad MBR like the Win9X one would be unable to boot LBA, a known-good one like the WinXP one would be able to.

A tool that worked by delegating the final boot like that could be following absolutely any rule one could imagine to choose which MBR to actually use once you'd chosen a partition in the front end.

NightOwl, I contacted TeraByte about the web page on booting DOS with BING. Apparently it doesn't apply to Win9x versions of DOS that support over 8GB.

My DOS knowledge is lacking and although I had no trouble running a batch file from DOS 6.22, I can't do it from the FAT32 version (Win98 SE). Whenever I put my command line into autoexec.bat, DOS boots to a Win98 splash screen. Help!

Brian

:)  Welcome to DOS!!!!!


Quote:

I contacted TeraByte about the web page on booting DOS with BING. Apparently it doesn't apply to Win9x versions of DOS that support over 8GB.

I kinda suspected that.


Quote:

Whenever I put my command line into autoexec.bat, DOS boots to a Win98 splash screen.

I forgot about that--haven't done it recently!!!--so didn't remember to warn you--if you use the system files on the Win98se boot disk--on a floppy there is no splash screen--but if you put it on a HDD--some other flag must be set--and somewhere in there that Win98 splash screen is coded and it pops up!!!  I don't remember--does the system just stop there--or do you eventually get to the A:\ prompt--sounds like it stops based on your post!!!

But, fairly easy to fix!  It's the *msdos.sys* file!  It probably is *read only*, so you will have to remove the hidden, system, and read only attributes to edit.  Open it with a *pure* text editor like *NotePad* (i.e. no text formatting abilities).

Here's the changes--I left out the bottom half of the file just leave those x's alone!:


Quote:

[Paths] ;WinDir=C:\WINDOWS ;WinBootDir=C:\WINDOWS ;HostWinBootDrv=C [Options] Logo=0 BootMulti=0 BootGUI=0 DblSpace=0 DrvSpace=0 LoadTop=1 ;DoubleBuffer=1 AutoScan=0 ;WinVer=4.10.2222 ; ;The following lines are required for compatibility with other programs. ;Do not remove them (MSDOS.SYS needs to be >1024 bytes).

It's the *Logo* one that's critical--the others are optional but I have made those changes.  If those options do not exist--just add them with their respective parameters.  The options with a *;* in front are *Rem'd* out (i.e. ignored)--they should not be needed for a DOS utility boot partition.

Change the attributes back to read only, hidden, and system.

Here's a reference talking about some of the edits:  http://forums.pcworld.co.nz/archive/index.php/t-40142.html

Did that solve the problem?

You can turn off the Win9x splash screens in those versions of DOS by editing MSDOS.SYS (which in older versions of DOS contained code, but in those newer versions contain settings).

In this case, the setting is "Logo=0" in the [Options] section to turn off the splash screen; see http://support.microsoft.com/kb/118579/EN-US/

Thanks guys.

NightOwl asked about the Win98 splash screen. It persisted for about 5 minutes and I then saw a C:\ prompt. I did your msdos.sys edits and the unattended restore is running now. Many thanks.

Do you have a favourite autoexec.bat? Without knowing any better I just copied the DOS 6.22 file.

Brian

I think I may be leading you astray!!!

Looked at the *msdos.sys* on the Win98se ERD boot disk and it looks like this:


Quote:

;W98EBD

I think you need to just add this as a minimum underneath the above:


Quote:

;W98EBD [Options] Logo=0

My previous reply was using the *msdos.sys* from my Win98se installation--which has more requirements than the ERD boot disk!

NightOwl,

I like the first msdos.sys better. With the second one, DOS boots to a "Microsoft Windows 98 Startup Menu". "Command Prompt Only" is highlighted. There is a 30 second countdown and then my IFD restore commences. With the first msdos.sys my IFD started immediately.

One hiccup that I didn't notice. As DOS is loading there is "SMARTDrive cannot be loaded because the XMS driver, HIMEM.SYS is not loaded. Check the CONFIG.SYS file for a device=himem.sys command line".

I then get a C:\ prompt and IFD works.

The first line of config.sys is

DEVICE=HIMEM.SYS /testmem:off

Brian

*himem.sys* is not a *system* file--so it is not copied over to the HDD as part of the *sys.com* command--you would have to manually copy it from the Win98se ERD disk to the HDD so it's available.  Also, *SMARTDrive* is not going to be a file on your HDD either unless you have copied it over to the HDD from the floppy--so expect additional errors when that command is run even if *himem.sys* is present!

Post your [config.sys] and [autoexec.bat]--if it's from DOS 6.22--they probably have commands that are not needed for a simple DOS boot, and can be *Rem'd* or deleted.

I'm tied up for the day, but I will post my *simple* boot file contents later this evening when I have more time!

NightOwl,

After doing sys c: and seeing that DOS did boot from my HD I copied all of the floppy files to a folder called "dos". So they were present but I had config.sys in the folder instead of in the root. When I realized this I moved config.sys but I still got an error. Eventually I found some lines that worked and this is what I'm using now.

DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH
FILES=30

My autoexec.bat is

C:\DOS\SMARTDRV.EXE /X
@ECHO OFF
PROMPT $p$g
PATH C:\DOS
SET TEMP=C:\DOS
ctmouse
call brian.bat

So all is fine. No errors and I can run a WinXP to WinXP restore with IFD from brian.bat.

Thanks for your help. I'd be interested to see your setup.

Brian

This is from my bootable optical disc that I use for Ghost on my own system.  I don't currently boot from a DOS partition on the HDD because I'm using my primary slots for test OSs.

Ghost is in a sub-directory *Ghost* in the data portion of the disc, as are the DOS files for PartitionMagic in a sub-directory *pqmagic*.

Here's my list of files in the boot sector:

AUTOEXEC.BAT
COMMAND.COM
CONFIG.SYS
DI1000DD.SYS
EDIT.COM
HIMEM.SYS
IO.SYS
MEM.EXE
MOUSE.COM
MOUSE.INI
MSCDEX.EXE
msd.exe
MSDOS.SYS
OAKCDROM.SYS
Usbaspi.sys

Here's my [config.sys]:


Quote:

device=himem.sys device=usbaspi.sys /v device=di1000dd.sys device=oakcdrom.sys /d:mscd001 dos=high lastdrive=z

Here's my [autoexec.bat]:


Quote:

path=a:\;x:\;x:\ghost;x:\pqmagic;c:\ mouse.com mscdex.exe /d:mscd001 /l:x /m:16 /v

NightOwl,

Thanks. That gives me a better understanding of what I've done and what I could do. My current setup works for me so I don't need to change much.

If anyone is interested, this is brian.bat


Quote:

image /r /d:b0@0x2 /base:b1@0x202:\BackupImages\IFW\WinXP /f:b1@0x202:\BackupImages\IFW\brian /rb:0 /mp /v /a /o bootndos 2

b0@0x2  is the WinXP partition on the first HD

b1@0x202 is the backup partition on the second HD

WinXP is WinXP.tbi, a baseline image

brian is brian.tbi, a differential image. I may have a string of differential images. If I want to restore to a specific differential image, I change the filename to brian.tbi while I'm in Windows, prior to the first shutdown and boot to DOS.

bootndos 2 performs the reboot to the restored WinXP partition

Brian


Quote:

bootndos 2 performs the reboot to the restored WinXP partition

I assume *bootndos* must come with the *Image for DOS* program.  

Interesting command line!

Here's my most recent *automated* files I created for a friend:

[config.sys]


Quote:

[menu] menuitem=auto, Automatic Ghost Backup of Primary HDD menuitem=ghost, Run Ghost Interactively (Manually) submenu=dos_prompt, DOS Prompt Only--Select the DOS Configuration of Choice menuitem=bkup_usb, Backup the Primary HDD to an External USB HDD menuitem=restore, Restore the Most Recent Backup of the WinXP OS Partition menuitem=bootxp, Re-Boot to Windows Now! menudefault=auto,30 menucolor=15,1 [common] [auto] lastdrive=z [ghost] device=oakcdrom.sys /d:nightowl lastdrive=z [dos_prompt] menuitem=basic, Basic DOS--No Memory Managers Will Be Loaded menuitem=himem, DOS + Himem.sys Loaded--Some Systems Require Himem.sys menuitem=emm386, DOS + Himem.sys + Emm386.exe Loaded submenu=usb_support, Add USB Support to the above DOS Configurations submenu=menu, Return to the Main Menu [basic] device=oakcdrom.sys /d:nightowl lastdrive=z [himem] device=himem.sys dos=high device=oakcdrom.sys /d:nightowl lastdrive=z [emm386] device=himem.sys device=emm386.exe Ram dos=high,umb devicehigh=oakcdrom.sys /d:nightowl lastdrive=z [usb_support] menuitem=usb_basic, Basic DOS, No Mem Mgrs + DOS USB Support menuitem=usb_himem, DOS + Himem.sys + DOS USB Support menuitem=usb_emm386, DOS + Himem.sys + Emm386.exe + DOS USB Support submenu=dos_prompt, Return to Previous Menu [usb_basic] device=oakcdrom.sys /d:nightowl device=usbaspi.sys /v device=di1000dd.sys /dU lastdrive=z [usb_himem] device=himem.sys dos=high device=oakcdrom.sys /d:nightowl device=usbaspi.sys /v device=di1000dd.sys /dU lastdrive=z [usb_emm386] device=himem.sys device=emm386.exe Ram dos=high,umb devicehigh=oakcdrom.sys /d:nightowl devicehigh=usbaspi.sys /v devicehigh=di1000dd.sys /dU lastdrive=z [bkup_usb] device=himem.sys dos=high device=oakcdrom.sys /d:nightowl device=usbaspi.sys /v device=di1000dd.sys /dU lastdrive=z [restore] [bootxp]

[autoexec.bat]


Quote:

@echo off cls SET TZ=GHO+08:00 set path=c:\ goto %config% :auto if exist g:\bkup3\nul deltree /y g:\bkup3 if exist g:\bkup2\nul move g:\bkup2 g:\bkup3 if exist g:\bkup1\nul move g:\bkup1 g:\bkup2 if not exist g:\bkup1\nul md g:\bkup1 c:\ghost.exe -script=c:\script1.txt -z if errorlevel 1 goto Problem goto bootxp :Problem echo. echo There has been an error reported by Ghost. echo Contact your local, friendly support person! echo. pause goto bootxp :ghost MOUSE.COM mscdex.exe /d:nightowl /l:x /m:16 c:\ghost.exe goto end :basic MOUSE.COM mscdex.exe /d:nightowl /l:x /m:16 goto end :himem MOUSE.COM mscdex.exe /d:nightowl /l:x /m:16 goto end :emm386 loadhigh c:\MOUSE.COM loadhigh c:\mscdex.exe /d:nightowl /l:x /m:16 /v goto end :usb_basic MOUSE.COM mscdex.exe /d:nightowl /l:x /m:16 /v goto end :usb_himem MOUSE.COM mscdex.exe /d:nightowl /l:x /m:16 goto end :usb_emm386 loadhigh c:\MOUSE.COM loadhigh c:\mscdex.exe /d:nightowl /l:x /m:16 goto end :bkup_usb if exist u:\bkup3\nul deltree /y u:\bkup3 if exist u:\bkup2\nul move u:\bkup2 u:\bkup3 if exist u:\bkup1\nul move u:\bkup1 u:\bkup2 if not exist u:\bkup1\nul md u:\bkup1 mscdex.exe /d:nightowl /l:x /m:16 c:\ghost.exe -script=c:\script3.txt -z if not errorlevel 0 goto Problem goto  usb_bootxp :restore echo. echo This procedure will first backup your echo current non-working WinXP OS Partition. echo. echo Then it will verify that image. echo. echo Then the most recent backup of your echo WinXP OS Partition will be restored. echo. echo Then you will boot back to WinXP. echo. echo If you have previously used this function, echo the previous bad OS backup will be deleted, echo and be replaced by this new backup of the echo current bad OS Partition. echo. echo Do you wish to continue?  A "No" response echo will cause a reboot, and loading of the echo first Main Menu.  You can then echo choose to reboot to Windows or make other choices. pause choice /c:yn Do you wish to continue? if errorlevel 2 goto reboot if exist g:\bad_os\nul deltree /y g:\bad_os if not exist g:\bad_os\nul md g:\bad_os c:\ghost.exe -script=c:\script2.txt -z if errorlevel 1 goto Problem goto bootxp :reboot reboot.com :bootxp mbrwizd /hide=2 mbrwizd /inactive=2 mbrwizd /active=0 reboot.com :usb_bootxp pqboot.exe /p:1 :end

[script1.txt]


Quote:

-clone,mode=create,src=1,dst=g:\bkup1\dsk1.gho -chkimg,g:\bkup1\dsk1.gho -fx

[script2.txt]


Quote:

-clone,mode=pcreate,src=1:1,dst=g:\bad_os\bad.gho -chkimg,g:\bad_os\bad.gho -clone,mode=prestore,src=g:\bakup1\dsk1.gho:1,dst=1:1 -fx

[script3.txt]


Quote:

-clone,mode=create,src=1,dst=u:\bkup1\dsk1.gho -chkimg,u:\bkup1\dsk1.gho -fx

Using *script* files with Ghost allows multiple commands to be carried out by Ghost without having Ghost unload and then reload for each command in a batch file--which could be done also--just speeds things up a bit.

NightOwl, impressive. A work of art. It makes my couple of lines look puny.

Bootndos (and bootnow) are free downloads from TeraByte but BING has to be installed for anything to happen.

bootndos 2 makes BING boot the second item in the boot menu. (The Dell diagnostic partition is item 1 in my menu. WinXP is item 2)

NightOwl wrote on Mar 1^st, 2008 at 12:28am:

I don't currently boot from a DOS partition on the HDD because I'm using my primary slots for test OSs.

Then BING is worth considering. You can have 5, 6 or even 200 primary partitions. I've been reluctant to accept unlimited primary partitions but I've tested it so many times that I'm now comfortable with the concept. But it took time.

When you set up a boot item in BING you have to choose which 4 primary partitions will take up the partition slots for that item and BING puts them into LBA-0 for that session. (The full primary partition information is stored in the EMBR). When you look in Disk Management, all partitions that aren't in the four slots show as unallocated space. It's ingenious. However, all partitioning must be done with BING when you have unlimited primaries enabled.

NightOwl,

This is exciting. You and I can run our DOS restores without a DOS partition on the computer. I'm just running my second IFD restore on my test computer after having deleted the DOS partition. The restore was started from a batch file.

It's done with TeraByte OS Deployment Tool Suite (Free for personal use).

http://www.terabyteunlimited.com/tbosdt.htm

Basically you create an "image" of your DOS partition and boot from this file.


Quote:

Example 1: Start with a partition already containing a bootable copy of DOS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In this example, it's assumed we already have a partition containing a bootable copy of DOS. The goal is to copy the DOS partition to a file, and then boot from that file using BOOTFILE. The steps below will list and explain the TBOSDT and BOOTFILE commands required to accomplish this. 1. Use TBOSDT to copy the DOS partition into a file: copy partition 0 0x1 d:\partcopy.bin /b The command line above runs the "copy partition" function to copy the partition with ID 0x1 on hard drive 0 into the file d:\partcopy.bin. The /b option adds 1 sector to the file in preparation for using it with the BOOTFILE utility. That extra sector is used by BOOTFILE to save the original MBR when the file is booted from. Note that partition ID numbers can be determined for a given hard drive by using the LIST HD command in TBOSDT. Example: list hd 0 2. Use TBOSDT to mount the file created in step 1 as drive 0: mount 0: d:\partcopy.bin 3. Use TBOSDT to copy the *DOS/TBOS* version of bootfile.exe to the mounted file system: copy file bootfile.exe 0: 4. Use TBOSDT to create or modify the autoexec.bat file: set textline 0:\autoexec.bat "bootfile.exe" /b In the above command, the SET TEXTLINE command is used to insert the line "bootfile.exe" in the autoexec.bat file. That line is necessary in order to restore the original MBR after the file is booted from - so that the next reboot will boot the system normally again. If autoexec.bat already exists, the command will add the quoted text as the first line in the file. If autoexec.bat does not already exist, the command will create the file, and then write the quoted text to it. If desired, the SET TEXTLINE command can be used to add/delete other lines in autoexec.bat at this time. 5. Be sure to EXIT from TBOSDT at this point so that drive 0: is unmounted. Exiting TBOSDT automatically unmounts the drive. 6. Run the *Windows* version of BOOTFILE to boot the system from the file: bootfile d:\partcopy.bin  (full path to partcopy.bin must be given) The command above updates the MBR to boot from d:\partcopy.bin, and then initiates a system reboot. Because of the way d:\partcopy.bin was updated in steps 3 and 4, bootfile.exe and autoexec.bat will be in place, and booting the file should be successful. On the next reboot, the system should boot normally, the same as before.

Make sure partcopy.bin is created on the first HD so you have a first HD boot.
partcopy.bin can be edited with UltraISO etc if you need to change paths or batch files. Other TeraByte software isn't needed.

Brain

Very interesting--so to make sure I'm following the above--this procedure creates a file that the boot sequence can read so as to create a *virtual boot partition* -- so no floppy boot disk or bootable CD/DVD--and when the system re-boots--you're back in your regular Windows partition.

Sounds like a similar solution that Ghost 2003 uses in its Windows interface.  

Does this procedure require that you leave an open Master Boot Partition primary slot, unused and free--like Ghost 2003--I would imagine that must be the case!

Quote:

so no floppy boot disk or bootable CD/DVD--and when the system re-boots--you're back in your regular Windows partition.

Yes.


Quote:

Does this procedure require that you leave an open Master Boot Partition primary slot,

Definitely not. My test computer has no DOS partition (now) and all 4 slots are in use. The computer boots from the file.

As a test I tried the partcopy.bin file in another computer and it worked fine. No other TeraByte software was in that computer, apart from bootfile.

I'm going to try to "copy" a 3 GB WinXP partition today.


Quote:

BootFile is a utility that enables to you boot an OS from a raw file (up to 4GB) containing a FAT/FAT32/NTFS file system .

My WinXP was 2 GB, not 3 GB. The partcopy.bin file boots to WinXP, programs work and everything looks normal. I can see the partitions on the second HD but I can't see the other partitions on the first HD. In Disk Management the active WinXP partition is in the position of the data drive (a logical volume) that contains partcopy.bin. Other areas of Disk 0 are shown as Unallocated Space.

Overwhelming at present but I'm slowly understanding what it does.

When I rebooted, it went back to the partcopy.bin WinXP. A little concerning at first until I discovered that unlike DOS, you have to manually reset the MBR with "bootfile /restore". A one second job.

With a few batch files you can do an unattended IFW restore using this "copied" Win XP and your real WinXP. You don't need a second physical partition.

The easiest way yet to do an unattended restore. You don't need a DOS partition at any stage or a dual boot or to copy the OS partition. All that's needed is a 1 MB bootable file created with the TeraByte OS Deployment Tool Suite. This file contains the IFD exe, the IFD command line and bootndos.exe.

From Windows you run the bootable file and your computer shuts down, runs the restore and boots into the restored Windows.

Creating the bootable file only takes a few minutes.

Correction to above post. Bootndos.exe isn't needed.

NightOwl,

You back yet? I've done a few unattended restores with Ghost 2003. One using a DOS partition and the other using the bootable "image" of the DOS partition.

I had an interesting experience along the way. I didn't understand the Ghost command line adequately and overwrote 4 partitions with a restore. So I went from having two WinXPs, a data partition and a DOS partition to having a single WinXP taking up the whole HD. Fortunately I had a first track backup in BING which gave me my partitions back and all I had to do was restore a WinXP image to the first partition as that OS wouldn't boot.

I just wanted to report that Ghost 2003 joins IFD and Drive SnapShot as definite unattended restore apps.

PS For Drive SnapShot you need ntfsdos.exe in DOS to access your image in a NTFS partition.

Brian

Yes...I'm back....!

I'm impressed--you have been working hard there!


Quote:

Definitely not. My test computer has no DOS partition (now) and all 4 slots are in use. The computer boots from the file.

That's certainly a plus--if you are testing out multiple OS's and want them on their own primary, hidden partition!

How big are the image files--does the program leave out unnecessary files like the hibernation file and the swap file--and empty space--but restores everything needed in its proper place?

Are partitions restored as the same size--or can they be changed to fill a larger HDD space?

NightOwl,

I hope you enjoyed the break.


Quote:

How big are the image files--does the program leave out unnecessary files like the hibernation file and the swap file--and empty space--but restores everything needed in its proper place?

I guess you are asking about IFD. File size is about the same as Ghost, pagefile and hibernation file aren't included. Partition restore can be resized to fill unallocated space if needed.

I mentioned a 1 MB bootable file. Great to use with IFD but unfortunately Snapshot and Ghost can't run from this file. All three apps can run from the "copy" of the DOS partition. This is a .BIN file the same size as the DOS partition. So if DOS is 100 MB, you have a 100 MB .BIN file. The .BIN can be edited in UltraISO so can be extensively changed after its creation. Files can be added or deleted. Typically your image/ restore batch files.  When the .BIN is run from Windows it causes a shutdown, a boot to DOS (the DOS in the .BIN), the appropriate batch file runs and then Windows boots.

I know your interest is Ghost so here is my rough effort in batch files for restore and image. They work in the test computer.


Quote:

ghost -chkimg,2:2\winxp.gho -fx -sure if not errorlevel 0 goto fail ghost -clone,mode=prestore,src=2:2\winxp.gho:1,dst=1:1 -fx -sure pqboot /p:1 :fail echo. echo Verify failed

Quote:

ghost -clone,mode=pcreate,src=1:1,dst=2:2\winxp.gho -z1 -fx -sure ghost -chkimg,2:2\winxp.gho -fx -sure if not errorlevel 0 goto fail pqboot /p:1 :fail echo. echo Verify failed

I'm not sure about the errorlevel. What do you think?

Update:

Unattended image restores can be done from Windows, DOS or the TeraByte bootable files.

Windows....                      Image for Windows, Drive SnapShot, Ghost32.exe

DOS.....                           Image for DOS, Drive SnapShot, Ghost 2003

TeraByte bootable files....   Image for DOS

If using a virtual machine (VM) rather than a multi-boot configuration, the problem of easily “restoring” the state of the PC is simplified.  VMware Workstation 6, for example, supports the concept of “snapshots,” which allow the user to “preserve the state of the virtual machine so you can return to the same state repeatedly.”  Although not “unattended,” such a “restore” involves nothing more complicated than clicking the Revert button on the VMware Workstation toolbar.

Alternatively, one could keep a duplicate of the VM in a separate folder, and automatically “restore” the VM by simply copying the saved .VMX and associated files to the original location.

As the popularity and ease of use of virtual machines increases, the role of multi-booting seems destined to gradually diminish, in my opinion.

Night owl you mentioned your way of using ghost 2003 for complete unattended batch process... is there anyway you can post complete step by step approach?

I'd like to report that an unattended image restore can be done when the backup image is stored in a networked computer.

I used NetBootDisk. With Bart's Network Boot Disk, a password has to be entered each time so the procedure can't be automated.

http://www.netbootdisk.com/index.htm

NetBootDisk was installed to a bootable FAT partition (8 MB) and configured. I preferred FreeDOS as it booted faster than MS-DOS.

From Windows, a batch file starts the process. Your computer shuts down and restarts into DOS. Networking is established and an image in the other computer is restored to a partition in your computer. Your computer then restarts into the restored Windows OS. No user intervention.

I used TeraByte's BING and IFD but I'm sure it would work with Ghost 2003.

Though very late in the discussions, i created a user guide to have fully automated restore using Ghost.

On the internet the one step recovery was mainly using Lenovo's files etc(if i remember correctly).

This guide i made has snapshots and the batch file of creating a backup in hidden partition and then finally restoring it using any keyboard key lile F10 etc at boot time.
The image is in hidden partition and is not accessible in windows hence less prone to any virus infection also.

The post is down below.

http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1211223513

you can get the guide from
http://www.esnips.com/web/kaviteshsingh/

For automated process from CD/DVD check this one:
http://radified.com/cgi-bin/yabb2/YaBB.pl?num=1217024697/

thx very much for ur explanation ..

i create these steps but still have an error

could u please send me the bootdisk with all those changes so i can simply burn it with my image onto a dvd .

i have try million times in alot of forums to do this ghost image deploy but always get error.

thx in advance and hope to send me the boot file ready to burn it with my image on dvd.