Booting directly from D partition

  • Thread starter Thread starter Doug Gordon
  • Start date Start date
D

Doug Gordon

For various reasons, our end system must be configured so the C drive is
available for the user's files and can't be EWF-protected. So I have always
configured XPE to run off the 2nd partition in such as way that the system
drive is the D drive with EWF protection. So far, so good -- almost.

However, there is still one critical component that remains on the C drive,
and that is the boot loader. The C partition is the one that is set
"active", so NTLDR runs from there, Boot.ini is there, etc. This means that
it is possible for the user to corrupt the C partition and prevent the
system from booting, and this has apparently happened a few times. If I set
the 2nd partition active, the system will boot directly from the protected
drive, but then that becomes the C drive, and the user's partition is now D.

Is there any way to boot directly off of the 2nd partition, but have the
drive letters come up so the system drive is D and the 1st, non-active
partition is C?

Doug G
 
Hi Doug,

Fortunately for you C:, D: are logical link that represent some volume access point and they are automatically assigned by PnP is
they are not already assigned.
Why I say fortunately.
Regardless of number of partitions that you have or their order you can assign arbitrary volume letters for each partition in TD
much before you put your image on target platform.

So you can say that OS partition is D: in TD by following my tip:
http://msdn.microsoft.com/embedded/community/community/tips/xp/rtpartin/default.aspx

And PnP will assign C: for your second partition that can be unprotected, and I guess programs that have hardcoded path
C:\SomeCoolProgram\start.exe will be fooled and will work on second partition with volume letter C:.

Regards,
Slobodan
 
Slobodan:
Since our image must be deployed to multiple targets (identical hardware,
but would probably vary in low-level serial numbers?), I have a concern
about this technique. Mainly, what is in the binary data that is the value
of the DosDevices keys? I can see that they vary from PC to PC, so I am
wondering if they represent something that is going to be seen differently
on different specific PCs, even if the PCs are "identical" in their
configurations. What is it that XP is matching up when assigning the drives
based on these keys?

Doug G
 
Hi Doug,
Since our image must be deployed to multiple targets (identical hardware,
but would probably vary in low-level serial numbers?), I have a concern
about this technique. Mainly, what is in the binary data that is the value
of the DosDevices keys?
Click to expand...

No problems there because those numbers are hardware independent.
First four bytes represent DiskID that is stored in MBR sector (first 512 bytes on disk).
Next 8 bytes represent offset on disk to partition start.

So if you do full cloning of disk content you will not have a problems since both DiskID in MBR and partition start will be same for
all disks.
What is it that XP is matching up when assigning the drives
based on these keys?
Click to expand...
Bacialy it check whether key exist that describe disk/partition and if not it will create it and autoassign volume letter.
If you put it manualy there then it will use your value.

Regards,
Slobodan
 
Back
Top