How to set a drive letter to a setupldr.bin RAM loaded image? Options

[cdob]

I like to set a RAM loaded image drive letter at BartPE (may be used at USB XP installation too).
Requested solution has to work at boottime. X: dosn't exist. Windows set another letter.

From http://www.911cd.net/forums//index.php?s=&...st&p=130963

HKLM,"SYSTEM\MountedDevices","\DosDevices\U:",0x00030001,\
10,27,11,27,00,7E,00,00,00,00,00,00

The green numbers are the hex values of the disk signature i.e. contents of bytes 440,441,442 and 443 of the MBR exactly as they are.

The red numbers are the offset of the beginning of the partition, calculated in bytes.

The blue zeroes appear to be an extension of the addresses, ALL my partitions, on ALL drives have 00 as 11th and 12th number, most probably they are used on larger drives.

Thanks.

Unfortunately a 2003 setupldr.bin RAM loaded image are floppy like images.

Images are created with ImDisk, there is no MBR.
Olof mentioned "Session Manager\DOS Devices". http://www.911cd.net/forums//index.php?s=&...st&p=133099

I tried

CODE

;2003 SP1 setupldr.bin RAM loaded floppy image
HKLM,"SYSTEM\MountedDevices","\DosDevices\R:",0x00030001,\
  fc,57,b2,d9,4e,68,cb,4d,ab,79,03,cf,a2,f6,b7,50

HKLM,"SYSTEM\ControlSet001\Control\Session Manager\DOS Devices", "A:", %REG_SZ%,\
  "\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}"

Both numbers are similar, just order and notation is changed.

BartPE SystemDrive get letter X: still.
BartPE Registry contain \DosDevices\X: fc,57,b2,d9,4e,68,cb,4d,ab,79,03,cf,a2,f6,b7,50

There is a additional letter a: available.
A: and X: contain the same files.
A: and X: are mapped to the same RAM loaded disk.

Actually I don't want X: used at all. I expected R: and/or A: at this example.

Different image sizes result in the same number.
\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750} is always the same.

A loaded SDI image give the same \Device\Ramdisk number.
Setupldr.bin ignores MBR in minint mode, a loppy like image is loaded in RAM.

DOS devices are defined late at boot.
http://www.windowsnetworking.com/kbase/Win...ctionSteps.html

http://www.jsifaq.com/SF/Tips/Tip.aspx?id=9375
http://alter.org.ua/en/docs/win/persist_subst/

Question remains:
How to set a drive letter to a setupldr.bin RAM loaded image?

This post has been edited by jaclaz: Jun 16 2008, 12:47 PM

[jaclaz]

Cdob,
you can try to make a "real" hd image, including MBR and hidden sectors, with VDK than mount it in IMDISK with the "offset" feature and as well mount it through setupldr.bin with the same "offset" features.

More or less this is one of the reasons why I originally asked Olof to support this kind of images:
http://www.boot-land.net/forums/index.php?...c=2072&st=8
though I cannot say if having a PHYSICALDRIVEx access will also work for ramdisk.

It seems like those numbers are somehow "fixed", check this:
http://www.tech-archive.net/Archive/WinXP/...0886.html"

jaclaz

This post has been edited by jaclaz: Jun 16 2008, 05:22 AM

[cdob]

Yes, I can make a "real" hd image, including MBR and hidden sectors.

But how do I use this "real" hd image?
How to load this image with setupldr.bin?
A offset to the bootsector load a floppy like image - without a MBR.

In 2002 there was a another RAM boot solution.
RAM Boot Using SDI in Windows XP Embedded with Service Pack 1
November 2002 http://msdn2.microsoft.com/en-us/library/ms838543.aspx
I understand, ntldr, boot.ini and ntdetect.com are part of image.
A OEM-Authored Boot Program load this image to RAM. This program is not part of XP Embedded.
But I have no idea, how to use this today.
Dietmar may have used this Code Sample.



Thanks for "fixed" numbers. Mentioned link gave a idea.
2003 Setupldr.bin RAM disk can be loaded at PNP.
At BartPE:

X:\I386\INF>devcon hwids *ram*
RAMDISK\RAMVOLUME\{D9B257FC-684E-4DCB-AB79-03CFA2F6B750}
Name: RamDisk
Hardware ID's:
Ramdisk\RamVolume
ROOT\RAMDISK00
Compatible ID's:
DETECTEDInternal\ramdisk
DETECTED\ramdisk

X:\I386\INF>devcon install ramdisk.inf Ramdisk\RamVolume
Device node created. Install is complete when drivers are updated...
Updating drivers for Ramdisk\RamVolume from X:\I386\INF\ramdisk.inf.
Drivers updated successfully.

X:\I386\INF>devcon listclass ramdisk
Listing 3 device(s) for setup class "Ramdisk" (Ramdisk).
RAMDISK\RAMVOLUME\{D9B257FC-684E-4DCB-AB79-03CFA2F6B750} : Windows RAM Disk Device (volume)
ROOT\RAMDISK00 : Windows RAM Disk Controller
ROOT\RAMDISK01 : Windows RAM Disk Device (volume)

[jaclaz]

I was hoping (maybe wrongly) that something like this:
http://www.goodells.net/multiboot/partsigs.htm#regkey
would happen, changing the drive number.

Just throwing random ideas, but what if you use a HD image WITHOUT offset in txtsetup.sif?

(i.e. letting the RAMDISK have an MBR)

Would it work?

If yes, does it change something?

jaclaz

[cdob]

Just throwing random ideas, but what if you use a HD image WITHOUT offset in txtsetup.sif?

(i.e. letting the RAMDISK have an MBR)

Setupldr.bin load image to RAM.
Next message: txtsetup.sif not found.

Idea: 2003 SP1 setupldr.bin does expect a boot sector in front.
A MBR in front is read as a boot sector. This fails.

Or does ramdisk.sys support a MBR?
Does this old 2000 example support a MBR? http://support.microsoft.com/kb/257405/

More weird ideas:
http://www.znpc.net/bbs/viewthread.php?tid...page=1#pid18444
How to load at grub4dos a image and connect a windows device driver to loaded image?
Without a connected windows device driver you get a BSOD 0x7b.

This post has been edited by jaclaz: Jun 16 2008, 05:23 AM

[jaclaz]

No, I am afraid that the problem is at a higher (or lower) level, most probably the RAMDISK driver does not provide a \.\\PHYSICALDRIVEx, just like IMDISK does not (but VDK does).

I don't think that the method suggested by windrv on the referenced link is of any use (and I don't think it can work, it seems like he maps something to something else, hooks the memory and then accesses the original device ?! :unsure)

Maybe you could see if Winobj:
http://www.microsoft.com/technet/sysintern...ion/WinObj.mspx
works in your PE environment and see if it is possible to get some ideas from the ways it sees the RAMDISK

... but I am really short of (even random) ideas

jaclaz

This post has been edited by jaclaz: Jun 16 2008, 05:24 AM

[Olof Lagerkvist]

Images are created with ImDisk, there is no MBR.
Olof mentioned "Session Manager\DOS Devices". http://www.911cd.net/forums//index.php?s=&...st&p=133099

I tried

CODE

;2003 SP1 setupldr.bin RAM loaded floppy image
HKLM,"SYSTEM\MountedDevices","\DosDevices\R:",0x00030001,\
  fc,57,b2,d9,4e,68,cb,4d,ab,79,03,cf,a2,f6,b7,50

HKLM,"SYSTEM\ControlSet001\Control\Session Manager\DOS Devices", "A:", %REG_SZ%,\
  "\Device\Ramdisk{d9b257fc-684e-4dcb-ab79-03cfa2f6b750}"

Both numbers are similar, just order and notation is changed.

BartPE SystemDrive get letter X: still.
BartPE Registry contain \DosDevices\X: fc,57,b2,d9,4e,68,cb,4d,ab,79,03,cf,a2,f6,b7,50

There is a additional letter a: available.
A: and X: contain the same files.
A: and X: are mapped to the same RAM loaded disk.

Actually I don't want X: used at all. I expected R: and/or A: at this example.

...\Session Manager\DOS Devices just creates a new drive letter. It is the old method of setting drive letters manually that was used in NT 4 and earlier, before the Volume Mount Manager that was introduced in Windows 2000. So what you essentially do here is that you create two drive letters, one with the "modern" Volume Mount Manager method and one with the old DOS Devices method. Apart from these methods drivers can also define drive letters themselves, either directly or through the Volume Mount Manager by notifying it about a new drive and then respond with a suggested drive letter.

ImDisk does not support Volume Mount Manager and does only create virtual partition images that are not subdevices of complete harddisks. That means that there is no \Device\HarddiskX\Partition0 interface (or better known as \\.\PHYSICALDRIVEX). But in most cases I have seen problems are not really about a harddrive object missing but more of a drive letter not defined when it is expected.

I have recently added a new registry setting for ImDisk so that the driver can define a drive letter itself without help from other drivers or user-mode applications. The setting is called DriveLetter0. Look at the latest posts in the "ImDisk as RAM-disk" thread: http://www.911cd.net/forums//index.php?sho...0&start=160

This post has been edited by jaclaz: Jun 16 2008, 05:20 AM

[jaclaz]

I guess that a this point a direct (and maybe ignorant ) direct question to Olof is unavoidable:
Can IMDISK work as BOOTABLE RAMDISK?

jaclaz

[cdob]

It is the old method of setting drive letters manually that was used in NT 4 and earlier, before the Volume Mount Manager that was introduced in Windows 2000. So what you essentially do here is that you create two drive letters, one with the "modern" Volume Mount Manager method and one with the old DOS Devices method. Apart from these methods drivers can also define drive letters themselves, either directly or through the Volume Mount Manager by notifying it about a new drive and then respond with a suggested drive letter.

Thanks for this explanation.

To clarify:
2003 Sp1 setupldr.bin load a image to RAM. And calls kernel and other files inside this RAM loaded image.
A unkown part set drive letter for this RAM boot device. X: at PE. And C: for Windows.
Driver ramdisk.sys might set drive letter. Contrary XP SP2 files set X: to a non RAM loaded image too.
Actually I don't know which part set drive letter to this RAM loaded image, maybe ntoskrnl.exe or setupdd.sys.

Can IMDISK work as BOOTABLE RAMDISK?

Just dreaming:
'rename imdis.sys ramdisk.sys' without a BSOD 0x7b. No, not tested.

[Olof Lagerkvist]

I guess that a this point a direct (and maybe ignorant ) direct question to Olof is unavoidable:
Can IMDISK work as BOOTABLE RAMDISK?

I have not tested it but I suspect that it won't work for practically two reasons.

ImDisk needs to load the image file to the RAM-disk from somewhere on a mounted filesystem on an already present device. Because disk drivers are loaded before file system drivers this would be...somewhat painful to try. As far as I have understood things the RAM-disk driver in the Windows 2003 setup does not load the image at all, that is instead done in an earlier stage by the boot-loader. This is a workaround that is as far as I can see only possible to use if one can modify the boot-loader to support this...

The other reason is that it looks like the boot-sequence nowadays need the disk drivers for boot devices to support Volume Mount Manager. ImDisk does not currently support that but it is possible that this particular matter can be solved relatively easy by wrapping another driver around ImDisk in the cases where this support is really needed.

[jaclaz]

The fact that also MS RAMDISK "likes" pure partition only images (no MBR), makes me think that volume mount manager might not be affecting it.

What cdob "dreams" could be a possibility, if I am guessing right, what the booting sequence of 2003 does is:
1) something in setupldr.bin (osloader.exe?) copies the image specified in WINNT.SIF:

OsLoadOptions = "/noguiboot /fastdetect /minint /rdpath=rampe.img

to RAM to a specific address
2) something else reads the line:

BootDevice = "ramdisk(0)"

and "understands" that the RAMDISK.SYS must be started, connecting to device "ramdisk(0)" the contents of the said RAM address

Now the questions are several:
1) at what address in RAM does SETUPLDR.BIN load the image (and RAMDISK.SYS accesses it)?
2) at what address in RAM does IMDISK access it's images
3) Could the two addresses be (or be made) the same?
4) Can we replace "ramdisk(0)" with "imdisk(0)" or something similar?
5) Can we use the "euhenio" method (basically using NTLDR instead of SETUPLDR.BIN and a line in BOOT.INI like ramdisk(0)\WINDOWS="RAM Boot XP" /rdpath=\win.img /fastdetect /SOS /BOOTLOG + a Registry patch like http://mobileos.boot-land.net/old/regpatch.reg) with some renaming or with any other trick?


Sorry, lots of questions without any answer....

jaclaz

[Olof Lagerkvist]

The fact that also MS RAMDISK "likes" pure partition only images (no MBR), makes me think that volume mount manager might not be affecting it.

No, it does not seem like that in this case. Strange. It is possible that this is handled completely different than all other kind of boot devices.

1) at what address in RAM does SETUPLDR.BIN load the image (and RAMDISK.SYS accesses it)?

Don't know. This is the key issue I think. There must be a way for a driver to find out where the image is loaded.

2) at what address in RAM does IMDISK access it's images

No particular pre-defined address. It allocates memory enough for the size of the image and then uses the address given by the OS. But it would be very easy to make it look at a particular address and use that instead if it only knew where to look...

3) Could the two addresses be (or be made) the same?

Yes, should be no problem if we just knew what the address is or how to check it when the driver starts.

4) Can we replace "ramdisk(0)" with "imdisk(0)" or something similar?

It would at least be possible to give that a try in that case. ImDisk would be able to register a device at that name but I am unsure wether Windows would like it or not. We could in that case probably try to use the name ramdisk(0) from ImDisk too.

5) Can we use the "euhenio" method (basically using NTLDR instead of SETUPLDR.BIN and a line in BOOT.INI like ramdisk(0)\WINDOWS="RAM Boot XP" /rdpath=\win.img /fastdetect /SOS /BOOTLOG + a Registry patch like http://mobileos.boot-land.net/old/regpatch.reg) with some renaming or with any other trick?

I would not rule out that. It could very well be possible.

[jaclaz]

@Olof

This somehow re-connects this topic to the (never released as far as I know) Dietmar's ramloading driver and to the original reason of the quest for a new driver (luckingly resulting in IMDISK ):
http://www.boot-land.net/forums/index.php?showtopic=1441
http://www.boot-land.net/forums/index.php?showtopic=1655

There are several scattered around references to this around, here are some of them, maybe, if you have the time, you could have a look at them and hopefully be able, "reading between the lines", to find some answers to these questions:
http://www.911cd.net/forums//index.php?sho...18485&st=40
http://www.talkaboutsoftware.com/group/mic...ages/46808.html
http://www.pcreview.co.uk/forums/thread-2081350.php
http://syslinux.zytor.com/archives/2006-April/006792.html
http://www.911cd.net/forums//index.php?showtopic=18326
http://syslinux.zytor.com/archives/2005-July/005399.html
http://microsoft-personal-operating-system.../1/Default.aspx
http://microsoft-personal-operating-system.../1/Default.aspx
http://microsoft1.groupbrowser.com/t647812.html
http://www.mcse.ms/message1751015.html
http://www.mcse.ms/message1745048.html


And yet some more references in the "monstruous" XP from USB thread:
http://www.911cd.net/forums/index.php?showtopic=14181
this is just one of them:
http://www.911cd.net/forums//index.php?sho...181&st=2044
Maybe a new pair of eyes, with the knowledge of a programmer, and specifically that of a programmer with experience in filesystem drivers, could connect some bits and pieces together.

Apart from the above, since you state that is possible to "assign" a RAM address to IMDISK, could we use a setup like this (just a sketch):
1) boot from grub4dos
2) boot in a DOS of some kind
3) use hmload.com (part of the grub4dos release) to copy an image file to a determinate RAM address:

*** About the DOS utility `hmload' ***
This program was written by John Cobb (Queen Mary, University of London).

John Cobb's note:

To make use of the ram drive feature I wrote a program `hmload' to load
an arbitrary file to an arbitrary address in high memory. The program
is not very sophisticated and relies on XMS to turn on the A20 line.
(Also one must be very careful to steer clear of any areas of memory
already in use).

Under Linux we generated a disk image `dskimg' (with the kernel and
Initrd and a partition table).

Using this our boot procedure looked something like this:

hmload -fdskimg -a128
fixrb
<unload network drivers>
grub

map --ram-drive=0x81
map --rd-base=0x8000000
map --rd-size=0x400000
root (rd,0)
kernel /kernel root=/dev/ram0 rw ip=bootp ramdisk_size=32768 ...
initrd /initrd
boot

See http://sysdocs.stu.qmul.ac.uk/sysdocs/Comm...GrubForDOS.html for details.

4) access again grub4dos through grub.exe
5) boot to a PE/2K/XP to the (rd) and then through IMDISK connected to the image already loaded to memory

jaclaz

This post has been edited by jaclaz: Jun 16 2008, 05:18 AM

[euhenio]

cdob
I think that only patch for ramdisk.sys the resolve of this problem

Olof Lagerkvist
first imdisk should support boottime (start=0) loading