Deploying dual boot XPe C:\ partitions on target with disk overlay EWF

[jimt]

We are considering the following scenario, and would appreciate any feedback
on
this approach. One hard disk drive contains two bootable partitions and a
disk
based EWF partition with an EWF volume and up to 9 EWF disk overlays.
Either
of the first two partitions could be booted, each as C:\, and the other
partition would be D:.

For the first case, partition #1 is C: and partition #2 is D:

multi(0)disk(0)rdisk(0)
...partition(1) XPe w/Disk-EWF, mounted as C:,
bootvolume
...partition(2) XPe w/Disk-EWF, mounted as D: Data
volume
...partition(3) EWF Partition (EWF Volume + Overlays)

And for the alternate boot case partition #2 is the boot volume at C:\ and
partition #1 is a data volume at D:...

multi(0)disk(0)rdisk(0)
...partition(1) XPe w/Disk-EWF, Data drive, D:\
...partition(2) XPe w/Disk-EWF, Boot volume, C:\
...partition(3) EWF Partition (EWF Volume + Overlays)

The dual-boot target would permit our installers to back up to the prior
install if the primary install fails. This scenario is:

[a] Partition #1 is running XPe + app, with EWF protection + disk overlays.

Time to upgrade; format Partition #2; install new XPe+APP onto
Partition #2
[c] Change Partition #2 to be primary active partition with it's own
boot.ini

[d] Partition #2 is booted as C:\ with same EWF partition as "the" new os
[e] Operator observes that the Partition #2 upgrade has failed horribly.

[f] Operator reverts back to booting Partition #1 with it's old overlays

Questions:

1. Can both boot partitions be known as C:\ using just one XPe image?
Seems like \WINDOWS, \Program Files, and \Documents and Settings would
all be C:\ from their TD settings. Should work?

2. Will partition #1's EWF disk overlays still be there to revert back to
in
step [f] of the scenario?

3. Any other issues come to mind?

Thank you,

 

[JustinH]

We are considering the following scenario, and would appreciate any feedback
on
this approach. One hard disk drive contains two bootable partitions and a
disk
based EWF partition with an EWF volume and up to 9 EWF disk overlays.
Either
of the first two partitions could be booted, each as C:\, and the other
partition would be D:.

For the first case, partition #1 is C: and partition #2 is D:

multi(0)disk(0)rdisk(0)
...partition(1) XPe w/Disk-EWF, mounted as C:,
bootvolume
...partition(2) XPe w/Disk-EWF, mounted as D: Data
volume
...partition(3) EWF Partition (EWF Volume + Overlays)

And for the alternate boot case partition #2 is the boot volume at C:\ and
partition #1 is a data volume at D:...

multi(0)disk(0)rdisk(0)
...partition(1) XPe w/Disk-EWF, Data drive, D:\
...partition(2) XPe w/Disk-EWF, Boot volume, C:\
...partition(3) EWF Partition (EWF Volume + Overlays)

The dual-boot target would permit our installers to back up to the prior
install if the primary install fails. This scenario is:

[a] Partition #1 is running XPe + app, with EWF protection + disk overlays.

Time to upgrade; format Partition #2; install new XPe+APP onto
Partition #2
[c] Change Partition #2 to be primary active partition with it's own
boot.ini

[d] Partition #2 is booted as C:\ with same EWF partition as "the" new os
[e] Operator observes that the Partition #2 upgrade has failed horribly.

[f] Operator reverts back to booting Partition #1 with it's old overlays

Questions:

1. Can both boot partitions be known as C:\ using just one XPe image?
Seems like \WINDOWS, \Program Files, and \Documents and Settings would
all be C:\ from their TD settings. Should work?

2. Will partition #1's EWF disk overlays still be there to revert back to
in
step [f] of the scenario?

3. Any other issues come to mind?

Thank you,

An interesting situation. We have a similar requirement that we are
approaching in a slightly different way. I think that the drive
letters are already assigned by the time Boot.ini is executed, since
alternative boot paths canbe specified as C:\ rather than using and ARC
path. However, it is possible that XP changes that according to the
settings in the 'MounteDrives' registry entry. No doubt someone more
knowlegable with clarify/correct this.
Our approach currently is to have two different versions of XPe in each
partition. The main working version targeted by TD at D:, but booting
through C:, and a greatly reduced (65Mb) command line shell version
residing on C.
Under normal conditions boot.ini boots the Windows on D: and apps run
normally. For (an unattended) upgrade, an upgrade DVD is inserted and
a batch file on it is initiated which replaces the boot.ini with one
that boots the Windows on the C: drive. The command line here is
adequate to run a batch file which will format or replace any necessary
files on the D: partition, finally replacing the boot.ini with one that
defaults to booting D: (after doing suitable verifications) and then
causes a reboot to the new system. If anything goes wrong along the
way then a reboot will boot tot he C: parttion and the upgrade process
will be restarted.
What we would like to have is the upgrade version of Windows on the DVD
(not as an el torito, but just having the Windows Directory pointed to
be the boot.ini on C: on the DVD. But I haven't yet worked out how to
build a version that will FBA on the hard drive but run from the DVD.

 

[jimt]

# I think that the drive letters are already assigned by the time Boot.ini
# is executed, since alternative boot paths can be specified as C:\ rather
# than using and ARC path. ...

I guess the trick is "which boot.ini runs". Since the first partition
is not an active partition, the first partition will not assume the roll
of system volume. That means boot.ini won't run from that partition, as
I understand it. In this case of booting partition #2, the #2 partition
is set to be the active partition. Since the MBR (Master boot record) code
scans each partition looking for an active partition, it should find and
use partition #2 as the system volume and run it's boot.ini. As long as
I set C: for the various paths in TD it should work. In theory.

# ... However, it is possible that XP changes that
# according to the settings in the 'MounteDrives' registry entry. ...

I could edit the gold image registry before it is deployed. I would
clear the C: entries from under HLM\SYSTEM\MountedDevices and
HLM\SYSTEM\MountedDevices\DosDevices and then deploy the image. When it
boots it won't know anything about a prior drive.

# Our approach currently is to have two different versions of XPe in each
# partition. The main working version targeted by TD at D:, but booting
# through C:, and a greatly reduced (65Mb) command line shell version
# residing on C.
#
# Under normal conditions boot.ini boots the Windows on D: and apps run
# normally. For (an unattended) upgrade, an upgrade DVD is inserted and
# a batch file on it is initiated which replaces the boot.ini with one
# that boots the Windows on the C: drive. ...

I like your plan, and would use it myself if not for our requirement of
being able to back up to the prior runtime if the new update doesn't
work out. That decision point could be a week after the install, so I
really need to keep the old image around. In your case it probably is
fine since you can always run the reinstall again.

 

[JustinH]

# I think that the drive letters are already assigned by the time Boot.ini
# is executed, since alternative boot paths can be specified as C:\ rather
# than using and ARC path. ...

I guess the trick is "which boot.ini runs". Since the first partition
is not an active partition, the first partition will not assume the roll
of system volume. That means boot.ini won't run from that partition, as
I understand it. In this case of booting partition #2, the #2 partition
is set to be the active partition. Since the MBR (Master boot record) code
scans each partition looking for an active partition, it should find and
use partition #2 as the system volume and run it's boot.ini. As long as
I set C: for the various paths in TD it should work. In theory.

# ... However, it is possible that XP changes that
# according to the settings in the 'MounteDrives' registry entry. ...

I could edit the gold image registry before it is deployed. I would
clear the C: entries from under HLM\SYSTEM\MountedDevices and
HLM\SYSTEM\MountedDevices\DosDevices and then deploy the image. When it
boots it won't know anything about a prior drive.

Having separate boot.ini files is OK, and I guess the drive letters get
sorted out, but personally I would not like to go round fiddling with
the MBR on a 'live' system. If an error occurs during the process you
are in an irrecoverable situation. I would prefer to have a third
'boot' partition, containing the ntldr, ntdetect, boot.ini suite, (can
be very small) and then two big partitions for the running systems.
Then you just need to replace the boot.ini to switch from one system to
the other.
I think that whichever partition is booted to the partition with
\Windows will be D:. If not, then there is a more complex, but doable
way to get there. Build each of the target systems as D:, and FBA them
on a real D:, then edit the registry MountedDevices so that the correct
drive letters are forcibly assigned for the real 3-partition
destination. The just copy all the files from the FBA disks to the
real target disks. A bit of a fiddle, but I think it should work and
should be reasonably slick once the development setup is configured
that way.