1

*This is my 1st post/question - I believe it's a very similar problem/challenge as isipro at --

Get boot-partition to recognize a second operating system

but it seems I'm directed to ask my own question vs replying or expanding theirs.

My scenario:

base.0 = 1st Drive Snapshot image of win.7x64sp1 Ultimate, drivers only + minimal utilities

base.1 = 2nd Drive Snapshot image of same [win.7x64sp1 Ultimate], 75% all apps installed

base.2 = 3rd Drive Snapshot image of same [win.7x64sp1 Ultimate], 100% all apps installed

..... *base.2 is installed to C:\ as the boot drive --
I have a 100 MB System Reserved partition w/ BCD.

I have no problem re-imaging C:\ in order to change between & update the different DS images,
but I want to be able to native-boot into an instance of any image on a 2nd partition,
with the choice available at boot-time.

Using an already-prepared image obviously saves time
by not having to invest the setup/tweak time again.

I want to native-boot vs. virtual machine OR vhd -- though I do use these for other purposes.

My Goal:

I want to install my image of base.0 to a partition B:\, for the purpose of native booting
(no virtual machine desired for this) into a separate instance of a minimal OS
for app-testing purposes.

This separate instance will persist across re-boots until I desire to re-image & "start over"
from an unchanged baseline.

  • I've followed the steps to configure the BCD as outlined by Jamie Hanrahan in isipro's thread, and I get success at the CMD, as well as a separate entry upon boot,
    so it would seem that everything looks/appears good.

**Problem:

-- when i select the new boot entry, the machine boots up into the desired partition B:\,

-- as evidenced under Disk Management's "Status" column:

B: = (Healthy, Boot, Crash Dump, Logical Drive)
C: = (Healthy, Primary Partition)

-- but it's the base.2 INSTANCE of the OS which is actually booted -- NOT the base.0 that I intend,

-- as evidenced by the presence of base.2 desktop, Start Menu, apps, etc.

I'll greatly appreciate the help to understand what/how other internal components need to be changed - in addition to the new BCD entry, for this type of procedure to be successful.

Thank You

Community
  • 1
newsome
  • 11

3 Answers3

0

I had a similar problem, where I cloned a drive, but couldn't operate from it. My problem was that the Registry Editor coded the old volume letters. So when I booted to a different target, the 'C' volume letter which is the primary booting letter, remained on the old drive. So it is necessary to either clear the Registry Editor assignment of volume letters before you clone your partition to a new section of the disk, or clear them after, but before you boot into the new partition.

These are the steps you would go through if you wanted to clone one partition to a different part of the same drive:

  1. Open the registry editor (Windows key + R, then type regedit)
  2. Delete all the keys in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices except the default key. (WARNING: This will remove all the letters assigned to your various partitions. If you have a complicated setup, you might have to reassign drive letters afterwards. In this case, you may want to use the alternative to change registry keys of the NEW patition only after having created it. The instructions for doing so are below.)
  3. Use a tool to copy the partition to a new part of your drive (AOEMI Partition Assistant (free version) is what I used, but there are a variety of tools that will do the job)
  4. Open an admin Windows Shell (right click on the windows button, then click on "Windows Powershell (admin)"
  5. Determine the drive letter of the NEW partition. Enter the command bcdboot e:\windows where e is the drive letter of the NEW partition
  6. Verify that it has been added by using the command bcdedit /enum to verify the partition was added to the windows boot menu. You should see something like
...
Windows Boot Loader
-------------------
identifier    {random uuid}
device        partition=E
...
  1. Reboot into your new partition. Launch the "Disk Management Tool to verify that the "C" drive is the correct partition of your hard drive. You can also use the same to to reassign other partitions different letters to meet your needs.

Changing Windows Registry on a Different Partition.

  1. Open regedit on working drive. This could be any partition that you can use to boot, or even a bootable windows USB drive (navigate to command prompt and enter regedit )

  2. Select HKEY_LOCAL_MACHINE

  3. Select File>Load Hive (this option will be greyed out until you have completed step 2)

  4. Navigate to target drive and following file path E:\Windows\System32\config\SYSTEM where E represents your NEW target partition. (If using a bootable USB use the command DISKPART and then list volume in command prompt to determine the correct letter to use)

  5. Enter any string for the key name i.e. 'Ehive'

  6. Drop-down the new 'Ehive' key and select 'Mounted Devices'

  7. Delete all entries except 'Default'

  8. Continue the process at 'step 5' above

Kit
  • 135
0

Every Window Vista, Windows 7/8/10 loader specifies two drive letters for its target (the OS to be booted) - "device" and "osdevice".

You can use bcdedit /enum all /v to view all present loaders in BCD.

bcdedit /set ...

can be used to change every parameter of a loader.

For easier to viewing and changing complete BCD contents use Visual BCD Editor.

Version 0.9.3.1 of tool can also create automatically loaders for Windows 7 installations which do not have an entry (loader) in BCD. Look for "Create missing Windows loaders" option on right-click.

snayob
  • 4,500
0

AT LAST !! Success after several years of wondering/experimenting/failing !!

Maybe this thread should be retitled --

"native boot 2 (identical or differential) clones from the same lineage, on the same disk (from different partitions, of course)"

Short Description: ASS-uming you understand, & correctly implement, a proper BCD

[which just might be a HUGE ASS-umption for many peeps],

then this whole quest doesn't involve the BCD at all, per se --

it involves stripping out specific identifiers and registry configurations within the OS install itself -- which brings me to the .....

Short Solution: Sysprep the install !

(warning: you may be in for a steep learning curve whilst solving the particular problems YOUR master install image presents)

This is what finally worked -- what finally allowed the [sysprepped] clone to be installed to a different partition on the same disk as its parent, and boot independently without any references or over-writes to/of its parent.

Medium-Short Solution: Use Virtual Machines or VHDs -- possibly much quicker to deploy, & offering several options regarding How they're created, etc.

Medium-Long Solution: Resign yourself to manually install & config the OS all over again - BUT !!

using as many Portable apps as you can -- either 3rd party, or create your own w/ [$$$] VMWare-Thinapp, Spoon-Xenocode, Cameyo, etc.

Then, as you invest time in preparing your own Custom Gold Master, make a careful log file [+ screen caps] of the order of installs, tweaks, etc. to guide you and reduce the time it takes for future deployments.

I find Nir Sofer's "MyUninstaller" an indispensable tool, as it has columns to show install Date - Time - Version - App Name - etc., which I make a screencap of & use as my reference of What was done When, etc.

Long Solution/Long Answer: Invest time in studying & learning the Microsoft documentation of the FREE Deployment tools !

I firmly believe People like me post these kinds of questions searching for Ease-of-Use methods, because we really want Nuhi to reincarnate nLite/vLite with a point-and-click/no-THought-involved method of dealing w/ Windows 7 --> 8 > 10 > future OS's!

... oh, and throw in a little of the DAZ Loader or KMSPico while we're at it, eh?

[just to take care of that pesky concept of ..... "I know I technically CAN, but legally - MAY I?"]

Listen - there are LEGAL methods for EXTENDED tryouts [re-Arms] of Windows OS's, plus, what do you think Nuhi, et. al., based/base their GUI deployment methods on??

-- the underlying Microsoft "api" if you will, which is just as available to you and me to bust our ass studying and learning from, as it was to Nuhi, et. al. -- which they apparently paid the time/price to Master!

And if all that's too much, then at the very least take advantage of VHDs, which are a nice compromise between --

"Yeah, we'll legally allow you to do it -- but only w/ these Editions [Enterprise/Ultimate]".

peace, and Happy Deploying!

newsome
  • 11