55 replies to this topic

[tinybit]

Probably you should think of PARTNEW as a PARTITION TOOL like fdisk.

PARTNEW changes ONLY the partition table in the MBR(only one partition entry, i.e., 16 bytes, will be changed) and it will modify the number-of-hidden-sectors(a 4-byte long integer) in the BPB in the boot area of the partition image if PARTNEW thinks the hidden-sectors field should be adjusted. Besides those two areas(which added up to only 20 bytes), nothing else will be changed on the hard disk by PARTNEW.

So I need to create an extended partition with one unique logical partition inside it before parnew command?

No. you don't have to. Any logical partition can be hooked to the partition table by PARTNEW, and thus the logical partition will have a new equivalent primary partition. You may think of the new primary partition as an alias of the original logical partition. Both will link to the same area(the partition's content/data) on the disk.

The above talk also applies to a contiguous file, in place of the logical partition mentioned above.

Or I only must have unallocated space, and let partnew create the extended partition + logical partition from disk image (which should be without MBR) ?

No. You don't have to. PARTNEW does not duplicate data/sectors. The existing logical partition(or the existing contiguous file) itself will be the source AND the destination. So no copy action will happen(occur).

Since there is no copy, for me it still will be a kind of mapping of the image file to the logical partition, isn't it?

No. There is no mapping made. The partition table of the hard drive will be modified permanently by PARTNEW. If you don't want the partition table to be modified, and you want it to be an emulation, then you should use the 'map --in-situ' feature(see readme).

Thanks for your questions.

[ktp]

@tinybit
OK I believe I have to look at map --in-situ command which seems to match my needs better.

Otherwise, great success for the hard disk emulation now. I succeeded to boot real XP inside the hard disk image (so ntldr protected-mode if
in effect does not give problem). Unfortunately after the XP logo screen I got BSOD 0x7B.

Summary:
- on my usb hdd, I had real XP booted off USB using usboot.org method. I did also check that all mentioned usb* services are with starttyp=0.
- on inside the xphdd.img, I copy Documents and settings, Program files and Windows directories, and of cours ntldr, ntdetect.com, boot.ini.
- I boot the USB key, got grub4dos menu, select boot from xphdd.img, and the disk image boots until it got BSOD 0x7b. I even have the modified
ntdetect.com from Dietmar that should circumvent the 0x7B problem.

Other question for you tinybit: on hard disk emulation, does the write operations by the OS/software inside the hard disk image reflected
(that is to say does the image got change to reflect the modifications) ?

For jaclaz/tinybit: by emulating (hd0) with the image contained inside the USB HDD, when XP boots off this image what does it see as HDD?
Does it see an USB HDD it is booting off, or other thing else (IDE...)?

Thank you for your ideas and support.

[was_jaclaz]

ktp, sorry to say so, but, notwithstanding the great troubleshooting work you did with tinybit , you are NOT an inch closer to actually booting XP from a hd image than you were before.

With the exception of VERY rare cases of "black magic" as I like to define them or "voodo" as Peter (psc calls them, all computer related problems are usually (read always) caused by something.
The generation of an error can be traced using logic.

There is NO WAY, and I mean NO WAY to boot XP from a disk image, you will always get a 0x000007b boot error.

This has nothing to do with grub4dos, please follow me:
1) grub4dos main utility is the ability to chainload something else
2) once it has chainloaded this something, it rather obviously has not anymore ANY control on the following actions performed by the something that was chainloaded
3) in the case of "DOS", or "real mode" if you prefer, the IO.SYS, however invoked, trusts the info passed to it by the BIOS (and eventually modified by grub4dos) and "acts" accordingly
4) In the case of NTLDR or SETUPLDR.BIN, after an initial phase, in "real mode", during which info from the BIOS (and eventually modified by grub4dos) is trusted, it switches to "protected mode" and re-scans the system, loading the APPROPRIATE driver for the boot media.
5) during this re-scan, PHYSICAL devices are detected NOT "virtual" ones, the grub4dos re-mapping of a virtual disk image ONLY works until this re-scan has been completed, and since there is NO WAY to tell NTLDR or SETUPLDR.BIN that it needs to load the driver for this "virtual" device, you get 0x07b BSOD
6) there is an exception, which is the RAMDISK.SYS driver that has provisions (Server 2003 SP1+) embedded in the NTLDR and SETUPLDR.BIN

So, to make a NT based system boot from a RAW image we need:
EITHER:
a. a new NTLDR/SETUPLDR.BIN that has embedded provisions to do so AND a NT kernel driver capable of accessing/loading the image
OR:
b. a NT Kernel driver capable of accessing/loading the image that could somehow (by being renamed to RAMDISK.SYS) take advantage of the provisions already embedded in the 2003 SP1+ NTLDR/SETUPLDR.BIN

It is several months that I try to find such a driver, or a capable programmer (it is not an easy task to write a NT kernel driver) interested in writing one, to no avail.

Check these:
http://www.boot-land...?...ic=1441&hl=

http://www.boot-land...?...ic=1507&hl=

http://www.911cd.net...o...c=19960&hl=

jaclaz

[tinybit]

Thank jaclaz for the clarification.

Yes. When an OS leaves real-mode and enters protected mode, it will not recognize our virtual drive any more.

I would like to take another example for Linux. Suppose you have a floppy image with Linux installed in it. You may create a real diskette using this image, and boot Linux from the diskette. But when you try to map this image with grub4dos and boot the virtual floppy, you might encounter problems once the kernel would try to access the (virtual) floppy.

But if you build the image in a proper way, you can still gain a chance to boot Linux inside the floppy image. Here is a working way:

(1) let the floppy image have a boot loader, e.g., grub4dos
(2) place vmlinuz and its corresponding initrd.gz in the floppy.
(3) boot the kernel and its initrd.gz, e.g., in this way:

kernel (fd0)/vmlinuz .........
initrd (fd0)/initrd.gz
boot

This could succeed, because the kernel needn't access data in the floppy image after it enters protected mode. The kernel only need to access data in the RAM disk(initrd). So the kernel needn't use BIOS int13. Thus no problem will occur.

[ktp]

Additional information:
0x7b=inaccessible_boot_device
Usually it is because the USB driver is reinitialized, hence problem with external USB HDD.

I took another try using the same HDD but put in the laptop (so it became an IDE HDD, so normaly 0x7b should not occur).
This time I got BSOD 0x6b PRCESS1_INITIALIZATION_FAILED :-).

OK the positive thing is that the hard disk emulation code of Grub4dos has been enhanced (fixed).
The bootability success of the hard disk image depends afterwards on the OS boot loader (real/protected-mode etc...).
It is the same as for ISO emulation function (hd32). It works for some, and not for others.

[tinybit]

OK the positive thing is that the hard disk emulation code of Grub4dos has been enhanced (fixed).

True. Thank you very much for your help. Without your dedicated help, the bug cannot be killed.