37 replies to this topic

[ktp]

Hi all,

Is there a way to make an image of an USB key under XP? The USB key drive is seen as removable disk and so not shown
as hard disk. So the usual Drive Image, DiskImage, Drive Snapshot, Ghost, R-DriveImage etc... do not allow to make
an image. The idea is to clone another USB key (same model).

I know there is a Hitachi filter than can make the USB key appear as fixed disk, but this requires tweaking and is specific
th one system.

[was_jaclaz]

There are several apps, two are these:
Roadkil's Disk image:
http://www.roadkil.net/DiskImg.html

Dsfo from the dsfok package:
http://members.ozema...eezip/freeware/

jaclaz

[ktp]

Thanks jaclaz, the Roadkil diskimg does not show USB drive, only fixed disks. So the only possibility for me is to try dsfok since
it allows a logical drive letter. I will test it.

[ktp]

:-(

I successed to make an image with the command : dsfo \\.\g: 0 0 i:\$image\mykey.img
But then to test, I format the USB key on g:, unplug/replug, reverify : g: is well formatted and empty.
I then execute the reverse command :
dsfo i:\$image\mykey.img 0 0 \\.\g:

then I got \\.\g: access denied

So I cannot restore my previous image ? So what is the utility to make the image ?

[was_jaclaz]

I am not sure I get it right, but:
1) the "reverse command" is not dsfo with arguments inverted, but rather dsfi with the same arguments.
2) if the key was unpartitioned/unformatted, the resulting image is unpartitioned/unformatted, so that it doesn't matter what you do to the stick, once you re-apply the previously taken image, it will be EXACTLY as before.
An image taken like this is a RAW image, i.e. a byte by byte copy of the original.

The idea of imaging a USB stick is to copy it in it's entirety, using the "PHYSICALDRIVE" reference, rather than a partition (or drive letter) on it, it's very strange that you cannot see the stick with Roadkil's Disk Image, it should see it allright, if "somehow" a letter has been assigned to a partition on the stick, the main "physical drive" must have been mounted, in case. try using vlm (on the dsfok package) to get the alternate link, something like "\Device\Floppy0".

Another app you may want to try is duBaron diskimage, that has some more options:
http://dubaron.com/diskimage/

jaclaz

[ktp]

Thank you jaclaz, I did not know the dsfi.exe command.

I tried all the three tools. Rectification : Roadkill Diskimg did show the physical disks, but its combo-box
is so small so I need to scroll down all the combo-box to see all the disks (that could explain that first time
I thought it does not detect the USB disk since removable).

The three tools use different terminology that for me is backup the USB key to an image file, and restore from the image file to the USB key.
dsfo source offset size destination = Roadkill Diskimg Store Image (to target file) = Dubaron Disk image write to file = backup
dsfi destination offset size source = Roadkill Diskimg Write Image (from source file) = Dubaron Disk image import from file = restore.

Comments :
1- Roadkill Diskimg does not show size of disk/vendor name, nor file system name etc... only hard disk 0/1/2... so it's difficult to be sure about the right disk/usb key
2- dsfo/dsfi (once used to) could be easier thanks to drive letter naming, and command line interface power.
Maybe I can boot to DOS with USB drivers, then use HX extender to run it. It could be a free man backup/restore tool
(like Drive Snapshot that can be run also from DOS command line, while dsfo/dsfi is Win32-console programs, not DOS programs).
3- Dubaron DiskImage has a GUI, is a little better, with logical volume (drive letter) or physical drive selection, so less error prone.
Then just select write to file or import from file.

But dsfi is much faster than Dubaron Disk Image to write back to USB key from saved image file.
So personally I choose dsfo/dsfi for backup/restore USB key image (power, more versatile, batch file, faster).

[was_jaclaz]

Since it appears that you like this kind of comparing, more apps are listed here:
http://www.911cd.net...showtopic=16534

There is really no need to use the DSFOK under HXDOS, there are good imaging utilities that already work perfectly in DOS, but it would be interesting if you have time to try it.

2- dsfo/dsfi (once used to) could be easier thanks to drive letter naming, and command line interface power.

Sorry, but it still seems to me that you are failing to see the difference:
if you use (with dsfo) a source like PHYSICALDRIVEx (with disk image this is the only way) the result is an image of an ENTIRE DRIVE
if you use (with dsfo) a source drive letter, the result is the image of JUST the PARTITION to which that letter is assigned (NO MBR, NO hidden sectors, no other partitions, no unpartitioned space)


jaclaz

[ktp]

OK thank you jaclaz for pointing out the difference. Since my USB key is removable and cannot be partitioned, and since it is
always formatted with same file system, this why with the drive letter method and dsfo/dsfi I did not see the differences.
The best way is of course using the PHYSICALDRIVE notation as you said since everything as you said is saved (mbr, hidden
sectors, all partitions if any etc...), and so this is the right method to backup and to restore later with exact image.

Thank you for the link to other tools, I will try them.

[ktp]

OK after few tests, currently I prefer DriveImage XML; It has a GUI, no installation, present in most BartPE as plugin, possibility to mount the saved image.
Backup/restore easy. No partition though, only logical drives, but for me it is sufficient since I know how to format the USB key if needed, and no need nor
possibility to partition an USB key. There is no password protection though nor compression, it can use raw mode (this means probably sector copy instead of
data copy). I assume by its backup through drive letter iI could also restore to a different key model (provided sufficient target space).

[was_jaclaz]

Yet another small correction:
The fact that your stick has the "Removable" bit set in the controller does NOT mean that it :

cannot be partitioned

it means that it cannot be partitioned with internal 2K/XP/2003 disk management (it can be partitioned allright with other tools) AND that, if partitioned, 2K/XP/2003 will be able to mount ONLY first partition, unless you use the filter driver.

This is a main concern for bootability of 2K/XP from a USB stick as, if the stick is not partitioned, the needed arcpath to %systemdir% directory is not generated.

Depending on the model/make of the stick, it is even possible to use the Manufacturer Production Tool to reset the "Removable" bit in the controller, so that all partitions will be mountable on ANY OS.

Also, it is possible that due to inherent "undivisibility" between REAL stick geometry and "HAL induced" N x 255 x 63 one, a noticeable amount of the stick space is not used/addressed, something that can be fixed with multiple partitioning and/or custom calculated MBR.

Some links:
http://home.graffiti...B/USBstick.html
http://www.911cd.net...showtopic=15776
http://www.911cd.net...o...=15837&st=6


jaclaz

[ktp]

I do not fully understand all what you said, but in other words, do you mean that partitioned USB key is recommended over non-partitioned USB key ? (recommended for booting on more systems?).

By the way I cannot post yet to other forum so I append here the data on my keys :

---
noname high speed (120x) key
usb 2GB
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_USB2.0&Prod_USB_Flash_Disk&Rev_0.00
Name: USB2.0 USB Flash Disk (USB2.0)

Logic Driver: W:\

VID&PID: Vid_0457&Pid_0151
Speed: high speed

VendorID: USB2.0
ProductID: USB Flash Disk
Product Revision: 0.00

Vendor Description:
Product Description:
Serial Number:
---

secure flash key 1GB
usb 1GB secure flash disk
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_USB2.0&Prod_Flash_Disk&Rev_2.00

Name: (USB2.0)

Logic Driver: U:\

VID&PID: Vid_0204&Pid_6025
Speed: high speed

VendorID: USB2.0
ProductID: Flash Disk
Product Revision: 2.00

Vendor Description:
Product Description:
Serial Number:

---
pconkey 2GB
pconkey
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_USB&Prod_Flash_Disk&Rev_V1.1

Name: Flash Disk (USB2.0)

Logic Driver: F:\

VID&PID: Vid_13fe&Pid_1a00
Speed: high speed

VendorID: USB
ProductID: Flash Disk
Product Revision: V1.1

Vendor Description: USB
Product Description: Flash Disk
Serial Number: 906C17000090

---
takems
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_takeMS&Prod_MEM-Drive&Rev_v1.0
USB key 4 GB

Name: MEM-Drive (USB2.0)

Logic Driver: T:\

VID&PID: Vid_13fe&Pid_1d00
Speed: high speed

VendorID: takeMS
ProductID: MEM-Drive
Product Revision: v1.0

Vendor Description: takeMS
Product Description: MEM-Drive
Serial Number: 90710800057A

---
mpman mp3/usb key 1GB
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\USBSTOR\Disk&Ven_GENERIC&Prod_USB_DISK_DEVICE&Rev_1.00
Name: USB MASS STORAGE CLASS (USB1.1)

Logic Driver: M:\

VID&PID: Vid_10d6&Pid_1100
Speed: full speed

VendorID: GENERIC
ProductID: USB DISK DEVICE
Product Revision: 1.00

Vendor Description:
Product Description: USB MASS STORAGE CLASS
Serial Number: USB MASS STORAGE CLASS

Note: on this key my BIOS recognizes it as removable media (like floppy, so must be usb-fdd), while all the others
are seen as hard disk (must be usb-hdd).
---

[was_jaclaz]

No, sorry, but there is still a communication problem, it seems to me as you are mixing different things.

Under Win2K/XP/2003 the SAME stick will be seen as either "Removable" or "Fixed" depending of a bit in the controller, that can either be changed with the appropriate "Production Tool" (if available) or filtered by a "Filter Driver".
The attribute "Removable" or "Fixed" is linked to "Device" or, better, to "USB Mass Storage Device", not to HD or FD.

This has NOTHING to do with the way the drive is partitioned (or not) or formatted.

In other words, you can have the SAME stick as BOTH "Removable" Hard Disk (if partitioned) or "Removable" Super Floppy (if not partitioned), as well as you can have ANOTHER one as "Fixed" Hard Disk (if partitioned) or "Fixed" Super Floppy (if not partitioned).

If you need to boot from the stick 2K/XP, the entry to boot them in BOOT.INI requires an arcpath, i.e. something like:
multi(0)disk(0)rdisk(0)partition(1)\WINNT
that you simply won't have if the device is non-partitioned (superfloppy) independently from it being "Fixed" or "Removable"

jaclaz

[ktp]

OK for the 2x2 matrix (removable, fixed) x (partitioned, non-partitioned).
All my keys are not seen with as fixed disks under Disk management of XP (so I cannot suppress or create partitions on them using XP built-in tools).
I understand from your explanations that hp-usb or PeToUSB formatter tools format those keys with MBR and single partition.
Under ptedit32 or beeblebrox I can see the MBR with 4 entries, the fist with correct partition ID and disk id 0x80. Also in the boot sector
of the first/partition the disk id is also 0x80 (and not 0x0).

So my keys formatted by hp-us/petousb can be accessed by arcpath, isn't ?

I tried to use boot.ini on my hard disk to provide a kind of boot manager to boot my USB key without requiring changing BIOS setting
(hard disk order).

I try to use similar syntax as with Grub
C:\grldr="Grub4Dos"
by changing C: into X: where X: is the drive letter given by XP to the usb key on normal bootup (in fact I tried from D: to F:).
D:\grldr="Grub4Dos on USB key"
But unfortunately it got worst, I did not pass the \(windows root)\system32\hal.dll step (file not found).
The system did access the USB key since the USB LED is blinking ON during those entries selection.

1) Where is this special boot.ini syntax documented ? it appears that ntdlr can boot another boot loader in addition
to the more classic arcpath with windows directory.

I also try several entries like :
multi(0)disk(0)rdisk(1)partition(1)\minint="minint on USB key rdisk 1 partition 1"
multi(0)disk(0)rdisk(1)partition(1)\grldr="grldr on USB key rdisk 1 partition 1"
multi(0)disk(0)rdisk(1)partition(1)\cmdc="cmdc on USB key rdisk 1 partition 1"
multi(0)disk(0)rdisk(1)partition(1)\erdc="erdc on USB key rdisk 1 partition 1"

but got same errors on hal.dll.

If it ever this work, this is very pratical since I do not have to change each time my BIOS setting to get my USB key
on top of the detected hard disk.
As far as I know, the solution is to use Grub4dos, then use the swap hard disk
function (map hd0 and hd1 ?).

Could someone point out the syntax to do this ?

By the way is there a detailed documentation on each of the grub4dos command somewhere?
In the grub4dos the documenation is scarce, and there is not such a list where each command is explained,
only some examples. For example I do not understand when I need to use the +1 like chainloader (fd0)+1 or
chainloader (hd0)+1. Or map --hook usage.

Also for me :
multi(0)disk(0)rdisk(0)partition(1) = (hd0,0)
multi(0)disk(0)rdisk(0)partition(2) = (hd0,1)
multi(0)disk(0)rdisk(1)partition(1) = (hd1,0)
multi(0)disk(0)rdisk(1)partition(2) = (hd1,1)

Could you confirm ?

[ktp]

Well I find some answer to my own questions

My PC Internal hard disk and USB key both have boot.ini loading grub4dos.

On the hard disk, in menu.lst:
title Boot USB key (usually 2nd hard disk)
map (hd1) (hd0)
root (hd1,0)
chainloader +1
boot

On the USB key in menu.lst:
title Boot 2nd hard disk from USB key (= Windows XP usually)
# note: the 2 map commands are necessary, otherwise it does not work
map (hd1) (hd0)
map (hd0) (hd1)
rootnoverify (hd1)
chainloader +1
boot

So, if change my BIOS settings to set my USB key as first hard disk, grub on USB key has one entry to boot on my PC internal HDD (good).
If the key is withdrawn, the default BIOS setting is internal hard disk as first HDD, so later on if I plug my key I can still
test(boot) the key WITHOUT changing the BIOS setting (USB disk first), grub on HDD invoke grub on the key. This works well for booting Linux or BartPE-like OS.

I still got a problem: booting DOS or DOS image like:

title Partition magic 8.05
find --set-root /images/pmagic8.ima
map --mem /images/pmagic8.ima (fd0)
#map --hook
chainloader (fd0)+1

I got the error:
- FAT12 BPB found with 0xEB (jmp) leading the boot sector, then Error 27: Dsk read error, Press any key to continue.
I commented out the "map --hook" command (without understanding its usage) to avoid another error saying
Error 41: The int13 handler already on hook

Is there a solution so that it will work perfectly booting from any device (hdd, usb key) in any order in BIOS setting, booting any OS?

[was_jaclaz]

I still got a problem: booting DOS or DOS image like:

title Partition magic 8.05
find --set-root /images/pmagic8.ima
map --mem /images/pmagic8.ima (fd0)
#map --hook
chainloader (fd0)+1

I got the error:
- FAT12 BPB found with 0xEB (jmp) leading the boot sector, then Error 27: Dsk read error, Press any key to continue.
I commented out the "map --hook" command (without understanding its usage) to avoid another error saying
Error 41: The int13 handler already on hook

Is there a solution so that it will work perfectly booting from any device (hdd, usb key) in any order in BIOS setting, booting any OS?

EVERYTIME you use the map --mem command, you have to "hook" memory afterwards, see it as something like "Save current settings".

Once memory is "hooked" you can't "hook" it again.

You need to give the command

map --unhook

Before being able to "hook" it again.

jaclaz

[ktp]

Thank yaclaz, the missing map --hook command caused error 27 : disk read error.
Adding the map --unhook command helps, but only when a previous hook is installed, otherwise
it is a fatal error. So I found that the best command is map --rehook, this works every time, regardless
of previous hook state.

So far so good, now I am very happy since I no longer need to change each time my BIOS settings (a lengthy operation)
in order to test my keys. Now I just plug in and reboot the system ! I use different colors for menu.lst on the key and on the hard disk
to be sure which grub I am booting or switched too ::-).

Thank you a lot for your help.

My next step is to try to install XP from USB key (so the key is like the install CD), this seems to have various methods but what is your recommened one ?

[ktp]

Rectification from above post: the map --rehook command cannot be used (fatal error) if no previous is found. So the best way
seems to keep map --hook in menu.lst, and only when it fails edit (type "e" in Grub menu) to edit the command to map --rehook.

[was_jaclaz]

My next step is to try to install XP from USB key (so the key is like the install CD), this seems to have various methods but what is your recommened one ?

Well, with reference to my post here:
http://www.msfn.org/...mp;#entry563654

method 1) is fully documented (so no more fun with it )
method 2) has yet to be started working upon, no takers here:
http://www.boot-land...p?showtopic=644
method 3) still requires experimenting
method 4) :
http://www.msfn.org/...showtopic=61384
is on hold at the moment due to lack of time (and also of some ideas) from me and porear, and possibly someone that could merge into it the reported experience of cdob:
http://www.msfn.org/...showtopic=81788
method 5): is in my opinion easily attainable, but the hardware reuirements make it a possible solution only for "high end" hardware.

Since you seem very quick in experimenting and learning, to report your experience in detail, and you like grub4dos, I would suggest you get involved in method 3):
http://www.911cd.net...showtopic=17425

I would leave method 2) to people already familiar and "up to date" with .script developing (I have at this point lost any expectation of ever being able to write .script code, at least until syntax becomes, if not fully defined, a bit more "stable" - this is not a critic to the development of Winbuilder or to the very good work developers are doing - just my point of view of the current "variability" of the language).

If you have any idea or suggestion about any possible workaround for the current (hopefully last) obstacle to defining method 4) you are of course welcome.

Adding the map --unhook command helps, but only when a previous hook is installed, otherwise
it is a fatal error.

Just an idea, mind you, and totally NOT experimented, but there are two possible way out:
1) Add a map --unhook to EVERY menu.lst entry that has a map --hook command AFTER the chainloader (or boot) command
2) Study the sintax of the fallback command and use it to the purpose of "looping" through a map --unhook command in case of booting failure


jaclaz

[ktp]

OK jaclaz, I like method 3 too, since it is exactly what I am expecting. It is exactly the method that works already but from my multiboot DVD using bcdw 2.01. Installing XP Pro is just a line in bcdw bootcat.ini with :
\PRO1\setupldr.bin ; Install Microsoft Windows XP Pro SP2 US ; xppro2

I already tried this method on the USB key, copying the PRO1 directory to the USB stick then add a menu
to grub on the stick. But I got an error that now I forgot, I have to experiment with more details (maybe patching \PRO1\setupldr.bin.

For the additional map --unhook as you suggested, I will try and retport the result.

[ktp]

Result of my experimentations :

My hard disk and USB key have both ntldr/boot.ini and grub installed. HDD is the first hard disk in BIOS.

The boot sequence is:
hdd ntldr - hdd boot.ini - hdd grldr - switch to usb key boot with

map (hd0) (hd1)

map (hd1) (hd0)

root (hd1,0)

chainloader +1

boot

then
- usb ntldr - usb grldr - usb menu.lst - load dos image with

title Partition magic 8.05

find --set-root /images/pmagic8.ima

map --mem /images/pmagic8.ima (fd0)

map --hook

chainloader (fd0)+1

The problem is with the map --hook above (int13 already hooked).
I change to map --unhook, but by doing this, when I boot the key as first drive
then select directly the pqmagic.ima, map --rehook fails (since no hook previously).

Wishlist for grub4dos: a kind of "force" option. Automatically unhook if previous hook found (= --rehook).
map --hookforce

@jaclaz, your suggestion for map --unhook AFTER chainloader does not apply car after chainloader I
already boot into DOS image so the command does nothing. The problem of hook here is due to one instance of grub (hdd) calling another
instance of grub (on usb).


For using USB to install XP (method 3), I got the error txtsetup.sif not found error 18 (= no directory).
I invoke the install from my key with:

title Windows XP Pro SP2 install
chainloader /PRO1/setupldr.bin

\PRO1\setupldr.bin has been patched correctly to change I386 to PRO1.
Also In \PRO1\txtsetup.sif
SetupSourcePath = "\PRO1\"
OsLoadOptions = "/fastdetect /noguiboot /nodebug"


So why do I encounter the error code 18 for txtsetup.sif ?

Directory structure of PRO1:
PRO1\
PRO1\i386
PRO1\system32

This should not be not so far, since the same directory structure and file contents but on the CD/DVD with bcdw 2.01 works.

[ktp]

Update :

I patched 2 occurrences of minint in \pro1\setupldr.bin
Now I go farther, and got message \$WIN_NT$.~BT\biosinfo.inf not found, code 18.
Wow, sound familiar, so I patched again 2 occurrences of it in \pro1\setupldr.bin to PRO1 then reboot.
I then get for the first time to the Windows setup blue screen, with F6/F2 (ASR) and loading drivers etc... then the message
The file dmload.sys could not be found. Press any key to continue.
Then I press a key => status line: Setup failed. Press any ky to restart your computer.

I think it will be difficult for me to go farther :-(.

[ktp]

Update: wow now it is much better.
I restart from scratch, clean the \PRO1 directory on the stick, copy to \PRO1 the content of I386 from the XP CD.
Then I patch 2 occurrences of minint, 2 occurrences of $WIN_NT$.~BT
in \PRO1\setupldr.bin and reboot on the key.
Then now F6, F2, windows executive step, drivers loading etc... passed OK. I got to the blue screen where I can quit (F3),
Enter to install or Repair. Wow!

I will test on with iso image under Vmware, since the invocation of grub on usb key is same as invocation of bcdw on CD/DVD.
grub on USB key: chainloader /PRO1/setupldr.bin
bcdw on CD/DVD : \PRO1\setupldr.bin

Update #2:

After pressing Enter I got the message: Setup cannot find the End User License Agreement (EULA).
Then I edit \pro1\txtsetup.sif, change to SetupSourcePath = "\PRO1\" and reboot : same eror

In \PRO1\txtsetup.sif, there is one line:

eula.txt = 1,,,,,,_x,2,0,0

Maybe someone could tell how to check and fix for the location of the eula.txt file ?

[was_jaclaz]

Check here:
http://www.msfn.org/...showtopic=14852
particularly, get the .gif here:
http://www.msfn.org/...opic=14852&st=3
http://www.msfn.org/...t...ost&id=1038

and these:
http://www.msfn.org/...showtopic=50513
http://gosh.msfn.org/txtsetup.htm


Also, try the:

OemSkipEula = Yes

suggested here:
http://www.msfn.org/...showtopic=31844

jaclaz

[ktp]

I made some progress, but now I stumble on the following message:

Setup
insert the cd labeled Windows xp professional service pack 2 CD into your cd-rom drive. press enter when ready

Well I already have the files win51ip and win51ip.sp2 on the root of the key and inside the \PRO1 (equivalent to \i386 on CD).
Any idea? I am searching with Google to find out a solution for this.

[was_jaclaz]

I guess that the problem might be some registry entry mapping DosDevices or something like that, maybe you can find a solution through the migrate.inf.

Do review the info posted by me, cdob and porear here:
http://www.msfn.org/...opic=81788&st=7
http://www.msfn.org/...s...61384&st=22

jaclaz