Brian

Quote:

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

Quote:

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

Quote:

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:

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:

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

Quote:

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:

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:

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!

   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:\:\;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

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:


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

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!