Remote Boot server and disk numbering

[Desi]

I have a target with two physical hard drives. I can use the following
command line to cause SDIMGR to write to the first hard disk:

sdimgr image.sdi /writedisk:0 /yes

If I use Remote Boot Server and PXE boot to an image on a RAMdisk, does
that RAMDisk count as drive 0? Are my other disks numbered 1 & 2, then?

What tool(s) can I use to find out the answer?

Thanks in advance for your help,
Desi

 

[KM]

Desi,

/writediskEST
This command writes the contents of a DISK blob to the specified destination.
The destination must be a *physical* disk number.

This means RAMDisk should not be indexed there and you will have your physical disk numbers started from 0.

The "close" tool should be diskpart but not seeing the code for sdiaut.dll it is still a guess.

However, I recall Microsoft comments about diskpart being accessing the disk 0 from running RAMDisk image. RAMDisk masks the first
partition of HDD and assigned with hardcoded C:.

Just in case, test it quickly and you will see if the HDD gets wiped out or you get an error about accessing boot drive.
In latter case, you will need to delete [HKLM\System\Setup],"SystemPartition" key from your SDI image.

 

[Desi]

I don't see any errors if I boot to the RAMDisk image, then use sdimgr
to write SDI images to drives 0 and 1, but right now I'm doing it with
scripts, and the command windows close right away if there is an error.
I'll do it manually and see what I get back.

After the scripts run, Windows continues to operate, however when I try
to access the drives in Explorer they are no longer accessible.

If I try to reboot to the RAMDISK image again, it never successfully
finishes (It gets to a blank desktop and sits there for 5-10 minutes,
then puts up the "Loading your personal settings" screen and stays
there for at least 20 minutes) - Which implies that the SDI image that
I'm booting to in RAM has some dependency upon what is on drive 0... I
don't understand how.

 

[KM]

Desi,

I don't see any errors if I boot to the RAMDisk image, then use sdimgr
to write SDI images to drives 0 and 1, but right now I'm doing it with
scripts, and the command windows close right away if there is an error.
I'll do it manually and see what I get back.

You may want to have CMD in your SDI image and do all the steps manually for debugging purposes. When it works you can capture the
steps in a batch file to automate the procedure.

After the scripts run, Windows continues to operate, however when I try
to access the drives in Explorer they are no longer accessible.

If I try to reboot to the RAMDISK image again, it never successfully
finishes (It gets to a blank desktop and sits there for 5-10 minutes,
then puts up the "Loading your personal settings" screen and stays
there for at least 20 minutes) - Which implies that the SDI image that
I'm booting to in RAM has some dependency upon what is on drive 0... I
don't understand how.

I am not sure what exact procedure you are doing over there. Can you list all the steps?

Specifically, why do you reboot to RAMDisk again? You probably realize that when you play with the sdimgr /writedisk command you do
not change anything within the SDI file that is on the server side, right?

Or are you saying that you wrote disk image to the local HDD, reboot, remotely loaded up the RAMDisk image again and that was where
you saw the blank desktop and etc.?
Just in case, make sure that the MountedDevices key is cleaned up in your SDI image (clean up the key just before you capture the
image into SDI file).

 

[Desi]

You may want to have CMD in your SDI image and do all the steps
manually

for debugging purposes. When it works you can capture the
steps in a batch file to automate the procedure

That's what I meant by "do it manually". I have CMD in the image. I'll
report back here with the results.

Or are you saying that you wrote disk image to the local HDD, reboot, remotely
loaded up the RAMDisk image again and that was where
you saw the blank desktop and etc.?

That is what I am saying - Rebooting to the RAMdisk image from the
server should work every time, but it doesn't if I write the SDI images
to the drives. The Remote boot image will no longer boot. It loads over
the network, starts to boot, but then seems to sit at the blank desktop
for a looong time, and then sits at the "Loading your personal
settings" screen even longer.

I'll re-create the ramdisk SDI file and remove any MountedDevices keys
that are in the registry prior to shutting down.

The other thing that is occurring is that I used fbreseal manually on
the image prior to capturing the ramdisk SDI image, so that machines
get a unique name when they boot to the remote boot image. I
originally thought that this is what was slowing down the system on the
boot after writing the disks, but 30 minutes seemed too long for a
post-fbreseal operation...

 

[KM]

Desi,

I'll re-create the ramdisk SDI file and remove any MountedDevices keys
that are in the registry prior to shutting down.

The other thing that is occurring is that I used fbreseal manually on
the image prior to capturing the ramdisk SDI image, so that machines
get a unique name when they boot to the remote boot image. I
originally thought that this is what was slowing down the system on the
boot after writing the disks, but 30 minutes seemed too long for a
post-fbreseal operation...

30 minutes is unbelievably long and should be unacceptable.

Please test the image without the MountedDevices and SystemPartition keys (especially if you FBA'ed the image on that HDD) and let
us know the results.

 

[Desi]

I will. You should expect an answer by Noon tomorrow, Eastern Standard
time (I don't know what time zone you are in, but I'm in GMT -5:00.)

Desi

 

[Desi]

I finally had an opportunity to recreate the Remote boot image without
any value pairs under the HKLM\SYSTEM\MountedDevices key, and I deleted
the value that was in HKLM\SYSTEM\Setup - SystemPartition.

This allowed me to remote boot to the image and use SDIMGR /writepart
to write the full images to my two compact flash modules.

When I reboot, however, the target stops at a blank screen with a
flashing cursor in the upper left corner. I suspect that the MBR is
corrupted somehow, but I don't know what is doing it, or how to easily
fix it...

If I boot to a WinPE CDROM and burn the images, then they work as they
ought to...

Anyone have any more ideas? Is there a way to fix the MBR without
re-imaging?

I should add that the compact flash modules are marked as fixed disks,
and are formatted to NTFS with compression in the image that is written
to them.

 

[KM]

Desi,

When I reboot, however, the target stops at a blank screen with a
flashing cursor in the upper left corner. I suspect that the MBR is
corrupted somehow, but I don't know what is doing it, or how to easily fix it...

SDIMgr /writedisk may write wrong disk geometry parametrs in MBR or PBR on your target.

You can write an application that will change those parameters in boot sector (e.g., the number of tracks per disk side).
(or hack the PBR section in the SDI file to change the parameters to match your target)

If I boot to a WinPE CDROM and burn the images, then they work as they
ought to...

Anyone have any more ideas? Is there a way to fix the MBR without
re-imaging?

You can try to use a bit different approach:
- partition the target media with diskpart
- format it with fomat tool passing the right /T and /N values
- write partition content with SDIMgr /writepart commands to every partition

I should add that the compact flash modules are marked as fixed disks,
and are formatted to NTFS with compression in the image that is written to them.

Well.. You don't seem to get to boot to the image yet and you mentioned you stuck with boot sector yet.
But just in case, make sure to have non-zero timeout in your boo.ini file of the expanded sdi file so that you know for certain if
ntldr gets loaded or not.

KM