TeraByte Unlimited

I think I've posted about this before, but, if so, I can't find the post.

Also, it's not clear to me whether the best place for this is here, in Image for DOS/Linux/Windows, Scripting or somewhere else.

Anyway, currently with BIBM 1.07a/IFD 2.69, using the IFD GUI, I can create images using either BIOS or BIOS Direct.

I have a script which is invoked via BootNow. This script creates images of several partitions in a single image file using BIOS. If I modify the script to use BIOS (Direct) (change b to d), IFD simply hangs. The backup progress screen comes up, but the percentage complete never changes from 0.

What kind of drive? if SATA, what mode is the controller in? what are the
difference in options you have on the boot disk that works vs the copy on
the HD? It may have to do with reading from the drive in BIOS mode which
causes some to lock, ensure you use "d" on your /f target as well or file
access will be "BIOS".

"Bob Coleman" wrote in message news:[email protected]...

I think I've posted about this before, but, if so, I can't find the post.

Also, it's not clear to me whether the best place for this is here, in
[b:1oi4kiu7]Image for DOS/Linux/Windows[/b:1oi4kiu7],
[b:1oi4kiu7]Scripting[/b:1oi4kiu7] or somewhere else.

Anyway, currently with BIBM 1.07a/IFD 2.69, using the IFD GUI, I can create
images using either [b:1oi4kiu7]BIOS[/b:1oi4kiu7] or [b:1oi4kiu7]BIOS
Direct[/b:1oi4kiu7].

I have a script which is invoked via BootNow. This script creates images of
several partitions in a single image file using
[b:1oi4kiu7]BIOS[/b:1oi4kiu7]. If I modify the script to use
[b:1oi4kiu7]BIOS (Direct)[/b:1oi4kiu7] (change [b:1oi4kiu7]b[/b:1oi4kiu7] to
[b:1oi4kiu7]d[/b:1oi4kiu7]), IFD simply hangs. The backup progress screen
comes up, but the percentage complete never changes from
[b:1oi4kiu7]0[/b:1oi4kiu7].

TeraByte Support wrote:What kind of drive? if SATA, what mode is the controller in? what are the
difference in options you have on the boot disk that works vs the copy on
the HD? It may have to do with reading from the drive in BIOS mode which
causes some to lock, ensure you use "d" on your /f target as well or file
access will be "BIOS".

SATA controller mode: AHCI

Boot disk vs HD is not a relevant question.

All things described here involve running a script via BoootNow.

The following script run via BootNow works:
Note that /log:0 /rb:4", 1) is actually on the end of the previous line.

If I change the script to (just changed b to d twice) and invoke it via BootNow, the backup hangs as previously described.

both being "d" now *should* work, but there may be some bios call happening
dealing with the GUI. There is a system here that I can used to test for
that problem to see if there is a BIOS call, but in the mean time, if you
really need to use direct, consider dropping in the CUI version of image.exe
over the GUI version.

"Bob Coleman" wrote in message news:[email protected]...

[quote="TeraByte Support":3a2y1phg]What kind of drive? if SATA, what mode
is the controller in? what are the
difference in options you have on the boot disk that works vs the copy on
the HD? It may have to do with reading from the drive in BIOS mode which
causes some to lock, ensure you use "d" on your /f target as well or file
access will be "BIOS".[/quote:3a2y1phg]

SATA controller mode: AHCI

Boot disk vs HD is not a relevant question.

All things described here involve running a script via BoootNow.

The following script run via BootNow works:

[code:3a2y1phg]sub main()
exec("^"C:\IMAGE.EXE^" /b /uy /d:b0@0xAB,0xA,0x365,0x3B3
/f:b0@0x3EA:^"\Daily^" /log:0 /rb:4", 1)
end sub[/code:3a2y1phg]

Note that [b:3a2y1phg]/log:0 /rb:4", 1)[/b:3a2y1phg] is actually on the end
of the previous line.

If I change the script to
[code:3a2y1phg]sub main()
exec("^"C:\IMAGE.EXE^" /b /uy /d:d0@0xAB,0xA,0x365,0x3B3
/f:d0@0x3EA:^"\Daily^" /log:0 /rb:4", 1)
end sub[/code:3a2y1phg]

(just changed [b:3a2y1phg]b[/b:3a2y1phg] to [b:3a2y1phg]d[/b:3a2y1phg]
twice) and invoke it via BootNow, the backup hangs as previously described.

TeraByte Support wrote:both being "d" now *should* work, but there may be some bios call happening
dealing with the GUI. There is a system here that I can used to test for
that problem to see if there is a BIOS call, but in the mean time, if you
really need to use direct, consider dropping in the CUI version of image.exe
over the GUI version.

No, it still doesn't work with version 2.70.

No, I don't really need to use direct, but just to see what would happen, I replaced image.exe with the one from the CUI version. That works.