The concept is build a fake HD image, with same signature as external HD. After boot stage1, Windows will match the external HD signature against boot loader information, and think the external HD is the boot disk, and continue boot stage2.

Before start, you need GRUB4DOS, and VMWare, and contig.exe from sysinternals. Here is the detail method:

1. Throw external HD into VMWare as a raw disk, make it USB Boot friendly.
2. Create a 0.1G pre-allocated VMWare image, run contig against the *-flat.vmdk file.
3. Format this VMDK, same filesystem format as external HD.
4. Copy Following file from external HD to VMDK partition:

here 850 is your XP default codepage.
5. Copy first 0x1be bytes of bootsect from external HD to *-flat.vmdk.
6. Change bytes from 0x1b0 - 0x1be, make the VMDK has same MBR checksum as external HD. MBR checksum is sum of 128 ULONG value.
7. Load this VMDK from GRUB4DOS:

Interesting approach.

Is it tested?

Why using VMware .vmdk format, though?

As I see it using a RAW image should work as well, and you can use MBRFIX to change the MBR signature and need not to validate the checksum.

I must find the time to test this....

jaclaz

Yes, it's test with ASUS MB & FireWire HD.
The quick way to make 2 bootsect has same signature and checksum is:

copy line mark EE from External HD bootsect to Fake Image,
copy line mark FF from Fake Image to External HD bootsect,
make other lines identical.

The files under SYSTEM32\Drivers used in my test are:

Hi s4e,

this is indeed a very interesting approach. Tomorrow I have holidays and I will test it.
I do not see, why it is only usable for a VMware image. It should also work with a real XP on the external harddisk.

I think the same for ETboot on bootland for real CD boot of XP.

If I understood all right, ntldr starts and loads all the USB drivers or in this example for firewire from the normal harddisk (or floppy or CD).
But the "rest" of XP starts from the external hardisk, exact at the moment after mup.sys can be seen in boot.log.
I believe, that this is possible. I have seen something like while testing boot from USB, but I never thought, that this could be an advantage. I thought, that this is a bad behavior of XP, but now I think, also very usefull.

Nice to hear from you all,

Dietmar

VMWare is not mandantory, but it make life a lot easier. You can dual boot the external HD, modify the RAW disk image, and test USB boot.

Yes, I was thinking about using QEMU, and as said with purely RAW images you won't need a hex editor at all.

jaclaz

Hi s4e,

I am working on Your fantastic idea. Two connected harddisks with the same signature give BSOD late in the bootprocess.
This is direct after the point, that one of those 2 harddisks has to disappear, not to give XP two identical disks.

Can you please specify exact that moment, which You describe as changing from Bootstage 1 to Bootstage 2?

This is important, because this gives you the exact minimal filelist, which files are needed. I think, that those files are all together below 5 MB.

If You are right, the problem with no Bios support is solved to do USB boot (or booting from firewire or anything else, which has a signature and XP has a driver for).

I will write Tutorial 7.

EDIT: Do you use the Signatur() syntax in boot.ini or is it normal multi() ?

Nice to hear from You,

Dietmar

PS: Yesterday I was on the CEBIT in germany. I spoke with a man from OLPC Austria.
He told me a lot of things about the OLPC's hardware. After that I am sure, that XP can boot on the OLPC.

Windows don't support 2 disk with same signature. So you must use a disk image(or disabled disk) with NTLDR, and external HD without BIOS support. And Windows must see the external HD but not the fake boot disk.
For a list drivers needed in stage1, you can check ntbtlog.txt, all items above first \SystemRoot\system32\DRIVERS\ is required. It's all Start==0 drivers and some dependency. eq: WMILIB, USBPORT, USBD, BATTC, PCIIDEX, SCSIPORT, CLASSPNP, 1394BUS.
In BOOT.INI, I use the multi(0)disk(0)rdisk(0)partition(1)，because the disk image emulated as (hd0).

Hi s4e,

first try is BSOD 0x34.

I wonder, whether the USB drivers are not loaded.

Please s4e,
can you describe Step by Step, how you achived booting from firewire?
USB boot does not work until now.

Nice to hear from you,
Dietmar

It's simple. First fire the VMWare, create 0.1G pre-allocated virtual disk, contig it. boot into virtual windows, format it to NTFS. shutdown virtual windows guest. Map the virtual disk image to drive Z:, copy all files I mentioned before. Then unmap the image file, fix the signature & checksum. Reboot to GRUB4DOS, load the virtual disk.

you've sparked a revolution dude! guess I will still be here tomorrow morning ha! post your concept everyone is trying to boot e hdd just have a look at all the posts seasoned computer men with no answers.

once again master-plan m8

Debian

Wow, it's a bit confusing atm, but once the geniuses (Dietmar, Jaclaz etc ) figure things out about how to make this work fully, i cant wait.

Great job s4e

Hi all,

is it possible to chainboot a whole XP.img (4GB Fat32 XP, raw img, meaning with MBR and first aktive partition in it) with Grub4dos from the boot harddisk with XP on it?

Nice to hear from you,
Dietmar

Yes, it works. chainloader has two form: ramdisk and mapping. The mapping method hasn't size limitation, but require the image file is contiguous. That's why contig.exe is require, it's the simplest way making a single file contiguous.

Hi s4e,

I tried so much different approaches, but always BSOD.

After all the BSODS, I changed the menu.lst to

map (hd0,0)/wdstart.img (hd0)
map (hd0) (hd1)
map --hook
chainloader (hd0,0)+1
rootnoverify (hd0,0)

but with no success. wdstart.img contains exact those files and folders as you described with an identical bootsector as the USB stick. The USB sticks boots alone and the wdstart.img image is also tested.
The USB lamp is blinking at once when the wdstart.img is loaded via grub4dos, but then BSOD.

I also tried to boot a real XP image wdusb.img with grub4dos without any USB.
The drivers from Bootstage1 are loaded but then also BSOD. I think, that booting an image of the NT family with grub4dos
is impossible at the moment (see a comment of jaclaz:"In direct mapping, the image file must be contiguous.

The virtual disk is implemented using INT 13. Therefore, it can be accessed in system that still uses INT 13, such as all kinds of DOS and Windows 9X (compatible mode disk access), and it can't be accessed in system that usesprotected mode drivers, such as Linux, FreeBSD and Windows NT family OSs.
").


But even if it is not possible to boot a complete XP.img via grub4dos, your methode may work, because the Base drivers are loaded but the switching to the real USB disk fails.
At the moment I have no ideas, what else I could try.

Are you sure, that your firewire boot works not in an image of Vmware while Vmware is running?

Nice to hear from you
Dietmar

PS: Please make a try with a real external disk without any Vmware and a raw (real) hardisk image.
The use of contig.exe -a tells me, that my images are in one piece.
And please post your original menu.lst, thank you very much.

eventually sdb1 booted with XP installed.

@Debian
Really, you should post something more than one liners, so that people can understand what you want to say.

@Dietmar
Identical bootsector or same signature in the MBR?

The theory behind s4e's suggested method seems correct, I had no time (nor I'll have for the next few days) to test it, but it sounds both reasonable and feasible.

Maybe there is something else that is preventing it from working for you.

Can you confirm that the "other" hard disk (not the image) can boot normally?

This method should work (though of course completely unneeded) also for "standard" IDE hard disks.

I would suggest you to try it with the "XPcli" project, with two identical "hard drives", one in the form of a virtual disk mapped as a HD on the VM and the other one with a smaller sized image file contained within the first.

Say "outer" image 100 Mb, Inner image 25 Mb, and see what happens.

If it works, we can then try troubleshooting the USB issue.

The 0X34 error is "strange", I would have expected a 0x7b one or it was a 0x0000007b <0xF894D640> 0x00000034 one like this?: (numvbeer between <> may vary)

jaclaz

The bootsector must identical or same signature & checksum, signature @0x1b8-0x1bb is a disk identity, checksum is a bootsector identity.

Hi all,

some strange things are going on, hihi.
I tried to boot via grub4dos my MiniXP (last one with integrated diskpart, from a FAT32 partition, the underlying XP is also on Fat32).

Again BSOD.
But when I do chainbooting with grub4dos, and hit F8 after grub4dos in boot.ini (means Save Mode for MiniXP),
MiniXP was booted, but then appears a message, that lsass has found a wrong name, and reboots after a few seconds.
This means twice:

Booting an HD-image of the NT family with grub4dos is possible. (I wonder, why Tinybit says, that it is impossible.)

Therfor you have to change the "wrong name", what ever lsass is meaning with that.


Now I make a try with my first MiniXP, because it does not know anything about lsass.exe, because it has none...hihi.

It is possible, that the approach from s4e works for booting any device, that Bios has no knowledge of.

To change the Signature of the MBR, you cant use MbrFix.
This is, because MbrFix only changes the 8 Hexvalues for Signature, but does not correct the checksum of the MBR.
If you use after that from the recoveryconsole of XP fixmbr, the MBR is repaired, but has after a different Signature...grr.

Hi s4e, you description of how to change the Signatur and keep Checksum, isnt all ok.
You wrote, that the other lines have to be identical, but which is the identity: The connected external HD or the MBR of vmdk image?

------------EXTERNAL HD---------------------
0000190: 0000 0000 0000 0000 0000 0000 0000 0000 // ==
00001a0: 0100 07fe 3f02 3f00 0000 04bc 0000 0000 // FF <---\
00001b0: 0000 0000 002c 4463 fd62 7287 0000 8001 // == |
00001c0: 0100 07fe ffff 3f00 0000 828a a112 0000 // EE --\ |
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 // == | |
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 // == | |
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa // == | |
-------------FAKE IMAGE------------------------ | |
0000190: 0000 0000 0000 0000 0000 0000 0000 0000 // == | |
00001a0: 0100 07fe ffff 3f00 0000 828a a112 0000 // EE <-/ |
00001b0: 0000 0000 002c 4463 fd62 7287 0000 8001 // == |
00001c0: 0100 07fe 3f02 3f00 0000 04bc 0000 0000 // FF ----/
00001d0: 0000 0000 0000 0000 0000 0000 0000 0000 // ==
00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 // ==
00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa // ==

Big things are going on,
you will hear from me,

Dietmar

Wait a minute, now I am really confused, can we re-start from the beginning, possibly using the proper terms and clarify the matter?

In a normal Hard Disk MBR there is NO such thing as a checksum.

Usually bytes from offset 17B to 1AF are 00's.

Disk signature is 4 bytes 1B8 to 1BB.

In a normal Partition bootsector there is NO disk signature, but rather a Volume Number and NO checksums.

Volume number is in a different position on the bootsector depending if it is FAT16, FAT32 or NTFS.

VMware disk images may be different, but there are a few versions of them, which version was used for this test, (not only the version of VMware, the actual version and type of disk image)?

jaclaz

Yes, I assume the external HD has single active partition and started @ sector 63. The image file has same layout (not reason to change it). So I make the line 1B0 identical between 2 bootsect, and swap 1C0 and 1A0 line, it will make 2 boot sect checksum identical (only 2 byte at line 1B0 belong to partition table, first byte 80 means active partition, and second means head==1).

And again: The 2 bootsect has same signature & checksum, both must be identical. If 2 partition table is different, and other bytes is same, the checksum wont be same. So you must fix the checksum afterwards.


The signature is a random ID Windows set to every disk (just like GUID in GPT partition table, you need it if disk size > 2T). The checksum is NTLDR & ntoskrnl's internal identity, to verify the mapping between the ArcName Path used by NTLDR and physical disk device in kernel. The algorithm calculating the bootsect checksum is: split bootsect to 128 ULONG value and sum them all, cast to 4 byte ULONG value.

If you have the leaked ***** source, you can find it easily.

Here is a small program calcuate bootsect checksum:

Usage:
cs \\.\PhysicalDrive0
cs firewire-flat.vmdk

First syntax calculate Disk0 (index in devmgmt.msc), and second against raw disk image.

s4e,
really I cannot understand.

You are talking of the MBR, not of the bootsecor.

As said, normal MBR on disk has NO checksum, is it possible that the checksum is added while loading the MBR in memory?

Can you provide a compiled version of the CS program?

jaclaz

Hi all,

I boot my XPMini.vdmk image (NTFS) (without any lsass.exe) via grub4dos on a NTFS partition. No BSOD .
It boots, but says,

lsass.exe - Fehler in Anwendung
Die Anwendung konnte nicht richtig initialisiert werden (0xc0000142). Klicken Sie auf "OK", um die Anwendung zu beenden.

english:

lsass.exe - Application Error
The application failed to initialize properly (0xc0000142). Click on OK to terminate the application.

This means: Not lsass.exe from the vdmk image produces this error (because it has no lsass.exe), but the lsass.exe from the underlying XP.

But now I think, it is only a small step to make all working.

Nice to hear from you
Dietmar

PS: Please s4e, can you compile your small program to calcuate bootsect checksum to an *.exe to make live easier?

This boot of an vmdk image via grub4dos kills the Hive config\system of the underlying XP. This behavior is reproducible,...brr, so make a rescue copy of your config folder.

cs.zip(cs.exe) attached in previous post.

The target SYSTEM hive will replace by source image's one, I observed the same behaviour. That's too bad because You can't change the target SYSTEM hive or you must sync them frequently.

Hi all,

I succeed to boot into a XP.img via grub4dos. I use as the underlying XP my 16MB Minixp (with no lsass.exe at all).
But there appears a problem. If there is a ntldr in this image, then hd(0,0) is bootet.
This is the first partition of your normal harddisk (this behavior can also be seen in SDI images with ntldr in it).
So, the method from s4e may work, but it would be better to make an image started by grub4dos, that has no extra ntldr in it.

Nice to hear from you,
Dietmar

YEEEAAAAHHHYYIIPPPIIEEEHH, thank You so much s4e


Today I can write the missing Tutorial 7 for USB boot, for every compi, that has no USB support in Bios at all.

I succeed with the method from s4e,

to boot a full USB XP SP1 via an USB to PCI slotcard.

That has never been done before. I worked so long and I saw so many BSODS, but now is the break to the light.

To boot XP via an PCItoUSB slotcard was a no go yesterday.

Now, I can implement XP on the OLPC laptop.

I am writing this lines from that USB XP harddisk, that is connected via an Belkin USB to PCI slotcard.
There is a nonono USB support in Bios.

Nice to hear from you
Dietmar

Click to view attachment

Click to view attachment

I'm looking forward to the long awaited tutorial 7 Dietmar

Does the procedure also apply to SP2, or is SP1 only working at the moment?

you really don't stop till you succeed do you! I admire that Dietmar. got Gutsy 7.10 booted from sdb1 myself

GOOD news!

Hope that the tutorial will also give an answer to my questions.

jaclaz

P.S.:
@Dietmar
Unrelated/not useful for this at the moment, but pavel just posted:
http://www.911cd.net/forums//index.php?sho...c=21276&hl=

great news about FREELDR, we may soon have an alternative loader!

Hi jaclaz,

do you know a tool for XP, with which you can easy mount any HD image (Fat, Fat32, NTFS, with MBR and Partitionstable)
as a virtual harddisk?

Best would be a tool, that writes the complete virtual disk back (as image with MBR), during disabling it.

Nice to hear from you,
Dietmar

EDIT: I had make a try with the cenatek ramdisk. But it cant load all images.

+1 please !!!!!!!!!!

I am not sure I got the question correctly , it's the third year I go around posting about the features of VDK!

Ken Kato's VDK.EXE:
http://chitchat.at.infoseek.co.jp/vmware/vdk.html
+ (optionally) my GUI for it:
http://home.graffiti.net/jaclaz:graffiti.n...ts/VDM/vdm.html

That can mount a RAW disk image (including MBR and partition table).

Using it there is NO need to create a MBR when unmounting or saving the image, the entire Disk, including (if needed) partitions besides the first one is mounted.

Read these if you need to use CHS geometry features:
http://forum.winimage.com/viewtopic.php?p=938
http://www.msfn.org/board/Help-Mount-physi...1.html&st=1
http://www.forensicfocus.com/index.php?nam...sc&start=38
http://www.forensicfocus.com/index.php?nam...sc&start=42

And IMDISK, that can mount only a partition or volume, just like FILEDISK (NO MBR):
http://www.boot-land.net/forums/ImDisk-f59.html

These and more are listed in this thread:
http://www.boot-land.net/forums/RAMdisk-an...vers-t1507.html

jaclaz

Hi jaclaz,

in commandline simple typing

VDK.EXE OPEN * usb.img

works.

Thank you very much,
this helps me such a lot to make USB boot with no Bios support much easier,

Dietmar

EDIT: I make a binary check of my USB.img and the virtual disk build with vdk.exe.
There are no differences, what a great tool.

Happy it helps you.

On a side note, VDK commands are "telescopic" so:
INSTALL will install the driver.
START will INSTALL and START driver.
OPEN will INSTALL and START driver and OPEN given image.

It is recommended, when you want to "end" a session using VDK, to use instead of the "normal" CLOSE command the REMOVE command:
CLOSE will close (unmount) the given image.
STOP will CLOSE all images and STOP the driver.
REMOVE will CLOSE all images and STOP the driver and REMOVE (uninstall) it.

Remember the need for using .pln descriptor files in order to have the "correct" geometry instead of the default nx64x32 one, and you can use MBRBATCH/MKIMG:
http://www.boot-land.net/forums/MBRBatch-0...LPHA-t3191.html
to create from scratch new images, partition and format them.

jaclaz

Hi jaclaz,

when I use the command

VDK.EXE CREATE

Winhex shows me a new harddisk, but it cant be opened, and also XP or Partition Magic cant see it.
So my question is: Is it possible to create an empty virtual harddisk with VDK or have you to use an existing image with
any content and build the content new?

Nice to hear from you
Dietmar

PS: Hi jaclaz, do you know any reason, why there are so many problems to boot to an XP.img via grub4dos?

As said, use MBRBATCH/MKIMG to create a new image:

Comeon, why would I have lost lots of time to write those two batches if it was possible to just "get away" with VDK CREATE?

About NT based images, problem is still the same about a missing NT driver, and it has nothing to do with grub4dos, if you do not believe me , do believe tinybit which is a co-author of grub4dos:
http://www.boot-land.net/forums/index.php?...=2692&st=26
http://www.boot-land.net/forums/index.php?...=3287&st=52

jaclaz

Hi jaclaz,

you are right, that in protected mode nothing from an XP.img can be seen, because of a missing driver for that image.
But the people from Qemu and Vmware must have such an driver for their images (!).

But that is not the whole trues: During ntldr works in real mode, all the loaded drivers at that time can find any device,
where they are written for. So you can boot another device (if ntldr loads a driver during real mode for) with an XP.img
via Grub4dos. That is the working idea from sd4 for USB or Firewire boot without any bios support.

Nice to hear from you,
Dietmar

PS: Is there a possibilty to load more drivers during that bootstage 1 (real mode)??? I think yes. They must only have an entry in Registry hive SYSTEM Services. Its a simple idea, to look at Vmwares registry or Qemu, which driver is there located with start=0 entry, to let them boot their images. This is the same for a ramdiskdriver.

Yes, it's very easy to add new BOOT storage device driver to NT base kernel: first add some Start==0 drivers, second add device(or compatible) id to the CriticalDeviceDatabase registry. All the whole USB boot method covered by these two registry: raise Start type to BOOT(by NTLDR), and PCI ID or (class ID) to CriticalDeviceDatabase. I always install new Windows(incl Vista) inside VMWare (because I can load ISO instead burn a disc), then adding new storage driver to registry.

But Loading a driver for .VMDK at BOOT stage is not the same thing, VMWare guest system didn't use an .VMDK driver, istead it emulate an IDE/BusLogic/LSILogic device, and use that driver. VDK or VMWare virtual mount could mount a Volume inside vmdk, but couldn't emulate a DiskDrive device, and need a third utility to initialize it. If you need boot from Image as SYSTEM drive directly, ETBOOT maybe the idea, and need a special device access int13 directly.

My boot method expose an idea to cheating boot process, to switch the realmode & actually boot device. Because the SYSTEM hive problem, It's not very practical. The SYSTEM hive loaded by NTLDR, and modified by boot process, after AUTOCHK completely, NT kernel will start the SMSS.EXE, the SMSS issue NtInitializeRegistry, Link the in memory registry to disk file, and commit the dirty pages. So the SYSTEM hive from realmode must match the target disk, or you get a hosed registry.

@Dietmar
Well, no.

Qemu use the "normal" "Dual Ide PCI controller", VMWare has it's own driver, but that works ONLY within the Virtual Machine.

What the clever idea from s4e does is using an existing (firewire or USB) device driver, loading it through a "trick" to bypass a missing feature of BIOS/NTDETECT.COM.

So we still need a NT driver for disk images capable to be "hooked" by NTDETECT.COM, which, however, does not provide for such a thing, exception made for the (in)famous NTBOOTDD.SYS.

As said elsewhere, the only one that could maybe used as NTBOOTDD.SYS I was ever able to find is the Perisoft one:
http://www.boot-land.net/forums/RAMdisk-an...vers-t1507.html
http://www.perisoft.net/miniport/index.htm
which, like "real" SCSI and SATA drivers is a "miniport" one.

The available version, being limited to 128 Mb, would not however be suitable for anything but the "XPcli" project, I was waiting for some "maturing" of that, and to tell you honestly, was also expecting much more enthusiasm and feedback for that GREAT idea of yours, but it seems like people is not much interested in it:
http://www.boot-land.net/forums/XPSP1-with...0-MB-t3717.html

Once purged of the "leechers" and a few people that posted there unneeded/unuseful comments, the evidence is clearly that there are just three people interested in that project, dog, yourself and me .

@s4e
Sorry, we were cross-posting.

Point is that such a driver is not available, the way to load it can be found, once we find the driver.

Could you please reply to my previous questions about MBR and checksum?

jaclaz

OK. Before jump into NTOSKRNL, NTLDR will load 2 registry: SYSTEM HIVE, and HARDWARE REGISTRY(by NTDETECT.COM and volatile, don't commit to disk file). Then Load all needed drivers, build a LOADER_PARAMETER_BLOCK to NTOSKRNL. In the LOADER_PARAMETER_BLOCK(and BOOT.INI), it use the ArcName to identify the boot & system disk. NTOSKRNL need a method the bind the disk provided by protected mode driver to the ArcName, that's the ARC DISK INFO LIST. The essential value in ARC DISK INFO is the Disk Signature plus MBR checksum. MBR checksum just a way to double check bindings between ArcName and DiskDrive.

BTW: there's EDD standard can map int13 device to PCI device number, but NT base kernel don't use it.

Ok, maybe I am starting to understand.

The checksum, as provided by your algorithm and the cs.exe program, is just a checksum, and in order to have the same checksum you devised the very clever trick of re-writing a "fake" number of bytes, complementary on each other, on both the disk image and the real hard disk MBR's in an area that is not used by the MBR boot code, nor by windows, i.e. the 1A0 to 1AF area.

So, I can as well write just four bytes wherever I want, in the 00 space between 17C and 1AF, in the given example you posted, these bytes would be:
EXTERNAL HD: 40024ABA
FAKE IMAGE: A112C988
that satisfy the checksum, and everything should work as well.

jaclaz

Hi all,

I just succeeded with XP Booting from USB with no Bios support without any use of VMware .

Thank you jaclaz, I use the mkimg.cmd and all its needed *.exe files from

http://www.boot-land.net/forums/MBRBatch-0...LPHA-t3191.html

and Winhex to store the *.img file from the generated virtual harddisk.

I noticed, that with mkimg I can format the virtual harddisk with XP and that it can be manipulated with Partition Magic.
That was not possible for the original vdk virtual harddisk.

And the Hive config/SYSTEM from the underlying XP isnt destroyed any more.

Now, Tutorial 7 is only one step away, but now I am to tired.

Thanks to s4e, who invented USB boot new.

I think, that this in some kind is a better solution than my USB boot, because you will never have any troubel with any silly Bioses and the effekt, that sometimes an USB device is recogniced and sometimes not, has gone.

The USB stack, that Microsoft implemented in their XP SP1 is a much better (and faster, boottime is 15 seconds for a full XP) solution than any BIOS USB driver,

Dietmar

VERY good!


Yes, the only "missing" feature of a RAW image mounted through a .pln descriptor file, or actually any image mounted through VDK is that VDK and the native windows "DISK MANAGEMENT" do not "talk each other", hence the MKIMG method of manually writing a MBR, as the FORMAT command is independent from the Dusk Management and works when it finds a proper MBR, as well, native DEFRAG won't work, but ultradefrag works:) :
http://ultradefrag.sourceforge.net/

jaclaz

Hi all,

does anyone tried the Etboot (by Dhilip89)
methode from CD-Rom, to boot via boot.ini to another, harddisk based XP?

I am searching for the simpliest bootmedium for USB XP without Bios support.
For a floppy disk, it is too (?!) large.

Today, most computers have the possibilty to boot from CD, so I think that this is the easiest way,

Dietmar

Works great, you can found a loot of info on bootland about that project!

Joshua

As I see it, there is no need to use the ETBoot method (that involves the use of a Hard Disk emulation CD).

Simplest should be a disk image on CD loaded by grub4dos, using grldr as no-emulation bootsector, this way, the rest of the CD can easily be used for other disk images and/or a PE.

The menu.lst entries suggested by s4e would become:


Once the above is proved to be working, one could also try with memdisk and with .gz or .zip compressed images.

If you give me the exact size of the files needed, I can make you a couple of the smallest possible images.

Something that must also be tested is if the idea from s4e can be used for "mixed" filesystems.

I mean, in the posted example, both the FAKE image and the hard disk are 07 (NTFS), if the filesystem actually needs to be the same, you will need at least THREE images:
06 FAT16
0b FAT32
07 NTFS

Or maybe, even FIVE of them:
06 FAT16
0b FAT32
0c FAT32 LBA
0e FAT16 LBA
07 NTFS

As is, the procedure has the drawback of being tightly "linked" to a certain hard disk (Disk Signature + checksum), thus it is not only not "portable", but also won't work anymore if the hard disk MBR is "fiddled" with in any way.

Ideally one could:
1) map to memory a "generic" fake image with grub4dos
2) boot to dos (USB or firewire drivers will be necessary)
3) use a dos batch to patch the MBR of the image loaded in memory, as to have same disk signature of the found "real" USB or Firewire hard disk and same checksum
4) re-start grub4dos via grub.exe
5) finally boot from the image and use the trick to actually boot from the "real" hard disk

The above seems to me overly complex and prone to problems.

The only other workaround I can find is to create a "standard" FAKE image with a certain Disk Signature and checksum and write a batch to be used on "real" hard disk that:
1) Saves current MBR (you never know )
2) Patches it changing it's disk signature and adding the needed bytes to satisfy checksum with reference to the "standard" FAKE image

This way you have a single FAKE image that can boot ANY "prepared" external hard disk.

jaclaz

P.S.: @Joshua, sure it works, but the question was "to boot via boot.ini to another, harddisk based XP", how are ARCPATHS affected by the hard disk emulation?

Yes.
jaclaz' post describe all the problem and the workarounds. The the filesystem type problem, setting NTFS & FastFat driver's Start to 0 should solve it.

Hi jaclaz,

I also think, that the idea of a generic fake image is the best.
One idea is, not to enlarge the boottime of the USB XP too much.

I remembered with horror my experiments, to boot a real XP (not SDI) from CD with the files from Windows Embedded.
That worked only after weeks with the "patched" ntdetect.com, therefor I had to change the whole registry from XP Embedded against the one of real XP. One result of those experiments is the MiniXP, that I offered at bootland. But I give up with the real XP from CD (DVD), because a 4,5 GB XP needs 6 minutes to boot from DVD.

For the fake image on CD you only have to write a batch for the MBR of the external harddisk, that changes only there the Signatur to the Signature of the fake image, build the checksum of that updated MBR and calculate the checksum differences to the MBR of the fake image and added it in 00001A0 to00001AF of the MBR.
No changes have to be made on the MBR of the fake disk.
I would not prefer ram boot for this fake image, because of older machines, there may be not enough ram.

I build a XP.img in a 50MB virtual harddisk. I do not believe, that the hive SYSTEM reaches more than 12MB.
And I have in system32\drivers all of my normal XP drivers. So, at the moment, I need 39MB, but I am sure,
that about 5 MB for the XP.img is enough, so that a compressed Floppy image also MAY work.

s4e told us, that the registry hive SYSTEM of the fake image has to be the same as the one on the external HD.
If this is the only possibility, you cant build a generic fake image. I will test that. Also I test, whether it is possible to boot another filesystem on the external HD, different from the one of the fake image. At the moment, I use NTFS for both. This isnt enough, because NTFS is bad for an external USB stick. Perhaps you have to use 2 different fake images, one with NTFS and one with FAT32. I don not think, that LBA or CHS makes a difference for XP, only for Win98.

jaclaz, can you please make, or tell me how to do, a boot CD, that only starts Grub4dos and loads from that CD the fake image XP.img as hd(0,0) with a size about 50MB ? Because in menu.lst the XP.img is set to read only, this should work. I can give you my XP.img or I burn it with Nero 6 on that boot CD.

Nice to hear from you all,
Dietmar

Menu.lst entry is in my previous post, to make a grldr based .iso, use the info in these:
http://www.911cd.net/forums//index.php?showtopic=18657
http://www.911cd.net/forums//index.php?sho...18045&st=25

About the requirement of an identical SYSTEM hive, I think that only some parts of it (accessed during booting) need to be the same, so, my guess is that in due time we may succeed in reducing the SYSTEM hive in the FAKE image to a pure "core", thus reducing size of the image.

jaclaz