A Digital Age Deserves A Digital Leader

Can Dual Boot Pro clean up my Boot Loader?

Forum rules
Please start your own topic for support with problems you experience. Even if it appears to be exactly the same as someone else's problem, system configurations differ significantly. Thank you.

It may take our support staff between 24-48 hours to respond to your problem. We are a small business and strive to answer your questions as soon as possible. We appreciate your patience.

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby John Campbell » Mon Apr 26, 2010 7:01 am

jbullard wrote:Okay, now this is all starting to make a little bit more sense. :yesnod:

There is no correlation between the identifiers (GUID) in the bootloader and signatures (DWORD | GUID) found in diskpart. This is a typical boot loader entry which you should be seeing as well.

Code: Select all
Windows Boot Loader
-------------------
identifier              {current}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  fr-FR
inherit                 {bootloadersettings}
recoverysequence        {c28af51d-2bbb-11df-92e8-fcb60c6c8734}
recoveryenabled         Yes
osdevice                partition=C:
systemroot              \Windows
resumeobject            {c28af51b-2bbb-11df-92e8-fcb60c6c8734}



Now, as you can see the above entry as an identifier of {current} because it is the default operating system to boot to if no selection is made on the boot menu. This is known as a well-known identifier. However, the true identifier of the entry above is actually {f123f741-167f-11df-98c6-ffdf61365e5f} which would be displayed using verbose mode.

There are also two options showing a setting of partition=c: - device and osdevice. The device is the operating systems partition. The osdevice is the operating systems system root. There is a reason for this; however, it is too much to explain.

Code: Select all
Windows Boot Manager
--------------------
identifier              {bootmgr}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-US
inherit                 {globalsettings}
default                 {current}
resumeobject            {c28af51b-2bbb-11df-92e8-fcb60c6c8734}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30


Here is the kicker. This is the boot manager entry which will change your bootloader settings. Notice the device partition=\Device\HarddiskVolume1. This is the location of the bootloader. This value is found through diskpart. I know that my bootloader would be located within the first partition on my first hard disk.

But, the entire synopsis of my ramblings are that this problem could be fixed easily. Just remember that the identifiers shown in bcdedit have no correlation with what disk and/or partition you are on. :yesnod:

Hopefully this made some sense and if not I can try to explain further in detail.

The reason that I did not explain how to bring the disk online within the disk management console is because diskpart is much better. Command line programs normally have more arguments than your typical graphical interface. Aside from that, in the disk management console there is no method of changing a disk's unique identifier.


It certainly looks like you've got it nailed, but at this point you're too far in for me. Going into the specifics of making the changes is going to encompass two different issues. The first of course is getting the ID to work properly, but then comes the job of making it either automated or so simplistic that I can handle it each and every time I paste an image across and expect to boot to it afterwords.

One other question: Did you happen to look at the serial of your drive just out of the off chance that there might be a match or correlation to the ID? (Thinking out load)


The second problem is getting Windows 7 to accept it as right now it seems the anti piracy effort is also tied up in the ID. It would seem that if Windows 7 is generating the ID it's method for doing so would have to be based in the backup drive somehow instead of the main (RAID) drive in order to include that backup drive. I think. Yes? No? Way off base?
PRO Level 2
Posts: 26
Joined: Thu Apr 22, 2010 5:01 am

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby jbullard » Mon Apr 26, 2010 4:49 pm

I just looked at my disk serial number and they do not match. However, I did do some more research on this issue and it looks as if there is a solution....an easy one at that as well.

From what I can see you are doing is a sector-by-sector image of the current setup which is why you are having a signature duplicated. In order to prevent this from happening you have to generalize the BCD prior to creating the image. Here is how you do that:

This is all run from within an elevated command prompt

Step 1: Create a backup
bcdedit -export "c:\bcd_backup\specialized.bcd"

Step 2: Enumerate entries
bcdedit -enum

See what identifier is listed for your current OS. It will most likely be {current}.

Step 3: Generalize the Boot Manager and OS Loader
bcdedit -set {current} osdevice boot
bcdedit -set {current} device boot
bcdedit -set {bootmgr} device boot
bcdedit -set {memdiag} device boot

Step 4: Create a generalized backup
bcdedit -export "c:\bcd_backup\generalized.bcd"

Step 5: Proceed with your imaging process

I am not sure of the process so I do not know if you have to reboot into a non-GUI environment or you can do it from within the Windows environment. If you have to reboot make sure you do not reboot into Windows. This will cause the above to be undone. Sysprep will automatically correct a generalized BCD. If you can run it from within the Windows environment, then once you are done you can simply run bcdedit -import "c:\bcd_backup\specialized.bcd. If you make any changes to more advanced settings for an entry I would recommend always creating a backup prior to generalizing a BCD. This will ensure that all settings are maintained prior to an image being made.

Now that you have a specialized and generalized version of your BCD you can either keep using the import function shown above or use DBP to import. It would be nice if Ghost offered some sort of feature where you can create custom commands to run pre- and post-image. :yesnod:
VP - Software
User avatar
Posts: 3653
Joined: Sun Jun 06, 2004 10:17 pm
Location: Utah
Real Name: Jason Bullard

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby ryerke » Wed Apr 28, 2010 7:32 pm

I would like to know more about sysprep. I am a friend of Mr. Campbell and it looks to me that you are on to something. My question is what will sysprep do with a generalized BCD? The goal in this case will be to have a unique identifier on the cloned system disk that is truly unique, that is, different from the unique identifier on the source disk. I'm somewhat new to Windows 7 and this whole boot process is providing an unexpected learning curve for me. If I understand correctly, sysprep will correct the generalized BCD on the original upon reboot and will do something similar upon first boot of the cloned system. Would I be correct in assuming that the cloned system will ultimately end up with a new unique identifier? If this is the case, then, problem solved. If the UID is, in fact created from the hash resulting from the product key, this could be a problem. Without a working copy of Ghost, I can't try this out, but if the UID depends on the product key it would stand to reason that the Windows validation will depend on the UID. Therefore, the new UID created at first boot will be the same as the UID of the other drive or the copy of Windows will be determined to be not authentic. Barring these two potential problems, you, sir, are a genius.
Bert
PRO New Member
Posts: 4
Joined: Wed Apr 28, 2010 6:55 pm

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby ryerke » Wed Apr 28, 2010 7:58 pm

Okay, I'm shooting my mouth off before getting prepared. I saved the output of bcdedit -enum and bcdedit -enum -v and subsequently generalized the BCD. I then re-booted Windows and, lo and behold, several of the ID numbers (I don't know what each of them mean) have changed and the description now says "Windows 7 (recovered)". The thing that strikes me is that Windows started without complaining about "not being and authentic copy" or anything like that. I did get a delay in start-up while (I'm assuming) sysprep was doing it's thing. I want to add that the recovered addition to the description alters the original rather than adding a new entry in the boot selection. I verified this by doing a second reboot and Windows started without a boot selection screen.
One other thing; I noticed many references to the 100MB System Reserve partition. As I understand, if you create and format (or maybe just create) a partition and then install Windows to it, you will not end up with the extra partition. If you install Windows to an non-partitioned hard drive, Windows setup will create the extra partition and may ask if you would like to do that during the setup interview. My opinion would be that backing up or cloning a system would have to be simpler without the extra partition. If anyone has experience contrary to this, I would like to know. Evidently, the System Reserve is recommended in order to have an environment to boot to in the event that the system refuses to start.
PRO New Member
Posts: 4
Joined: Wed Apr 28, 2010 6:55 pm

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby jbullard » Wed Apr 28, 2010 8:02 pm

The thing to remember is that there are two parts to this cloning process. Before I get into that let me see if I can't explain some processes that might help.

The very first thing you need to do is to see if the disk signatures are the same. It is a very common thing for this to happen during cloning but you want to make sure that this is the case. I would open up an elevated command prompt and type in diskpart.

1. list disk
2. select disk 0
3. detail disk - Signature will be listed as Disk ID
4. select disk 1
5. detail disk - Signature will be listed as Disk ID

If both the disk id's match then you will simply need to change the disk id for the single SATA. This can only be done by diskpart but it also can be scripted. I do not know if norton ghost allows custom scripts to be run but it might be something to check in to.

The Windows Activation/Validation would not need to be re-accomplished. Windows normally goes off of MB/CPU because an HDD is something that can be easily swapped out. The activation key for Windows also has nothing to do with the unique identifier for your disk.

BCD uses a GUID 'Globally Unique Identifier' or UUID 'Universal Unique Identifier'. These can also come in the form of a well-known identifier such as {current}, {bootmgr}, {default}, and/or {ntldr}, etc.

Disk ID is actually considered a disk signature but has two different values. One can be a DWORD value which indicates a MBR and a GUID for GPT. These have nothing to do with BCD or Windows Activation/Validation.

Now, when you are talking about sysprep generating a new UID, are you talking about the boot entry or the disk signature? As stated above there are two different identifiers being discussed here and I want to make sure we are both on the same page. The BCD GUID would not have a new identifier generated as there is no need to do so. That is the reasoning behind a generalized BCD store. :yesnod: But yes, sysprep would scan through the disks and update the BCD store accordingly.

However, if the disk signatures are being cloned and both match then you will have to generate a new signature for the single SATA. It is no big deal and will not result in reactivation or any type of problems. I have changed mine several times with no adverse reactions. :yesnod:

Hopefully, this all makes sense. I know I kind of skipped between two different things but with the new BCD store it is required. Diskpart and a generalized BCD store are the two key factors here. Get these straightened out and I think you may be able to accomplish this. :yesnod:
VP - Software
User avatar
Posts: 3653
Joined: Sun Jun 06, 2004 10:17 pm
Location: Utah
Real Name: Jason Bullard

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby ryerke » Wed Apr 28, 2010 8:25 pm

It sound very do-able. I will have to leave the disk signature identification as an exercise for Mr. Campbell since it is his machine that we are working with. This should be no problem since we are simply retrieving information and not making changes to anything. I have a 32 bit system running on VirtualBox and he has a 64 bit running on some space aged machine he just built so I have the MBR and he <should> have the GPT. Regardless, he can take a peek to see if they match. Let me know if I'm off track. It seems as though generalizing the BCD serves to prevent the disk signature from being cloned in the first place. If the signatures match because the cloning was done without generalizing then that can be corrected with diskpart. However, I could be going in totally the wrong direction. Reading your two most recent posts and combining information, it looks like one would use one method or another but both should not be necessary, correct?
PRO New Member
Posts: 4
Joined: Wed Apr 28, 2010 6:55 pm

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby jbullard » Wed Apr 28, 2010 9:43 pm

You are a little off track. Generalizing the BCD only has to do with the boot process. So instead of having a drive letter (i.e. C:) assigned to the device or osdevice setting, it would be labeled as BOOT. This flags sysprep during boot to scan all the drives and take the value BOOT and change it to the correct drive letter. Disk signatures have nothing to do with this and are a separate part of the cloning process.

Both generalizing the BCD store and re-assigning a disk signature are required. So the process might be something like this:

1. Generalize the RAID BCD store
2. Clone the RAID setup
3. Transfer image to single SATA
4. Use diskpart and change disk signature on single SATA
5. Boot into single SATA (sysprep corrects generalized BCD store)

It is definitely easier said than done. One thing you might also have to consider is using bootsect to move the bootloader from the RAID to the single SATA. In fact, this is going to be necessary. So a modified process would look like:

1. Generalize the RAID BCD store
2. Clone the RAID setup
3. Transfer image to single SATA
4. Use diskpart and change disk signature on single SATA
5. Use bootsect to install bootloader to single SATA
6. Boot into single SATA (sysprep corrects generalized BCD store)

As a side question, is there a reason for not using something that is known to work much better, such as a Windows Recovery Environment??
VP - Software
User avatar
Posts: 3653
Joined: Sun Jun 06, 2004 10:17 pm
Location: Utah
Real Name: Jason Bullard

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby John Campbell » Thu Apr 29, 2010 3:09 am

jbullard wrote:You are a little off track. Generalizing the BCD only has to do with the boot process. So instead of having a drive letter (i.e. C:) assigned to the device or osdevice setting, it would be labeled as BOOT. This flags sysprep during boot to scan all the drives and take the value BOOT and change it to the correct drive letter. Disk signatures have nothing to do with this and are a separate part of the cloning process.

Both generalizing the BCD store and re-assigning a disk signature are required. So the process might be something like this:

1. Generalize the RAID BCD store
2. Clone the RAID setup
3. Transfer image to single SATA
4. Use diskpart and change disk signature on single SATA
5. Boot into single SATA (sysprep corrects generalized BCD store)

It is definitely easier said than done. One thing you might also have to consider is using bootsect to move the bootloader from the RAID to the single SATA. In fact, this is going to be necessary. So a modified process would look like:

1. Generalize the RAID BCD store
2. Clone the RAID setup
3. Transfer image to single SATA
4. Use diskpart and change disk signature on single SATA
5. Use bootsect to install bootloader to single SATA
6. Boot into single SATA (sysprep corrects generalized BCD store)

As a side question, is there a reason for not using something that is known to work much better, such as a Windows Recovery Environment??



Well, I see my best Friend has been here. Many thanks. Glad to have Mr. Yerke aboard. ^*^

To give a little more update to this situation, I've been in contact with Microsoft and it seems the entirety of this issues does in fact stem from the Vista/7 boot-loader and being designed around, among other things, an anti piracy effort. After trying to explain that this has nothing to do with one of the drives being a RAID-0 for the umpteenth time I finally lost my composer and came unglued with their supervisor who also tried the same stunt with me. No, I did not use any colorful metaphors, but suffice it to say that for the tongue lashing they got I might as well have.

After I cooled down I called them back and got yet another tech, same department, but at least he seemed better versed in the situation and has passed the info on to development. So he says. Simply put, if Windows is recognizing the identical ID signatures and putting the drive to an offline state, and since Windows knows that when the drive is manually toggled to the on-line state it still has the ID issue, it also stands to reason that Microsoft knows that the two drives are on the same machine, thus it's a dual boot for a main drive and a cloned image of the main drive, on the one and the same machine. Anti piracy at this point is pointless. Good ole fashion reasonable deduction and common sense. (A commodity not found natively in the middle east apparently)

It then stands to reason that since the only way to get the "collision" is by having identical ID's on the same machine there should be built into it the ability to alter the ID built in as well to accommodate such a setup. In example, adding an additional character to the ID mark (or sub character) or changing the ID by one character automatically. No, that was too easy. Got to have that anti piracy thing going on. We shall see if they get on the ball. :roleeyes

The there's Symantec, who is more likely at this point to find a way to correct the issue in an automated fashion. I'm still pending a call with them as I fell asleep today and missed the call. Better luck tomorrow.

In the mean time there's the folks at DBP, who seems to be onto something that could make this issue history at least for one machine and possibly incorporate something into DBP to make it fully automated thus beating Microsoft to the punch.

I'm getting the gist of your method and I'm hesitant to do things just yet because of limited resources. I'm a little short of hard drives and I want to be able to keep an image on hand that can be used to undo any foul ups along the way as a 'just in case'. However, I'm setting up to give this idea a test run. Also, I believe Ghost does in fact have full ability to run commands in an automated fashion that includes before the image creation, after the image creation, and after the recovery point finalization. After that point we're relying on sysrep to make it whole again, if I'm understanding this correctly.

I'm not skilled enough to add the scripting to Ghost, but with yourself and Mr. Yerke I'm confident that this likely will not be a problem. All it calls for is writing the correct script in a txt document, placing it someplace to make sure it's not going to be disturbed, then linking to it via a browse feature that already exists for this purpose in Ghost. If this proves successful there in may lie the answer and a benefit to DBP to incorporate as a toggle option for the DBP software.

In regard to the Windows recovery environment question, the effort there has been done several times, if we are talking about the same thing, and each time the result has been that Windows 7 recognizes the bogus entries sometimes made during the process of forming the "collision" report and subsequent offline status change. However, Windows sees the correction process with both remaining entries being accurate entries and leaves them as is. The net effect is no matter which drive you attempt to boot to you will end up on the drive that the image was originally made from. In this case the RAID drive. By physically removing the RAID you can boot to the single SATA drive, but the boot loader is now the one contained on the single SATA. Reinstalling the RAID results in not being able to boot to either drive. Just the reverse issue from before comes into play when using the Windows Recovery disk to repair the boot loader. Now you can only boot to the single SATA drive. Attempting to switch drives in the BIOS, as would normally be the case in Windows XP, fails to work. The only way to get back onto the RAID drive is to disconnect the single SATA and reboot accordingly. What made good sense with XP doesn't seem to apply with "7".
PRO Level 2
Posts: 26
Joined: Thu Apr 22, 2010 5:01 am

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby jbullard » Thu Apr 29, 2010 5:08 am

Wow. You have definitely been through a lot trying to get this all worked out but I am confident that this is easily fixable. It is a matter of having the resources available in case something doesn't go as expected. If you are hesitant and want to wait until this weekend I have a PC with a RAID setup 2+0 (I believe) that I can go through all the steps. I have a lot of experience in this area so I have no problem wrecking my PC to help out. :yesnod: That's what we do!!

I think you are mostly running into the fact that Microsoft nor Symantec want to claim responsibility for the matter. It would not surprise me if each one of them said that it was the other's fault. Unfortunately, that is the run around most people get.

I still do not see how the Windows 7 activation would come in to play. If Microsoft told you that this would happen then I think they are mistaken. It would be no different than doing a sector-by-sector copy to a larger HDD - no re-activation required. So they are probably just saying that because they really have no idea.

I think the Windows Recovery Environment is for those that are only looking to create an image that can be booted to in order to restore back to a certain time. What you are trying to accomplish would not work.

Again, if you don't want to run through the process I can try it out this weekend, most likely Saturday. :yesnod:
VP - Software
User avatar
Posts: 3653
Joined: Sun Jun 06, 2004 10:17 pm
Location: Utah
Real Name: Jason Bullard

Re: Can Dual Boot Pro clean up my Boot Loader?

Postby John Campbell » Thu Apr 29, 2010 10:02 am

jbullard wrote:Wow. You have definitely been through a lot trying to get this all worked out but I am confident that this is easily fixable. It is a matter of having the resources available in case something doesn't go as expected. If you are hesitant and want to wait until this weekend I have a PC with a RAID setup 2+0 (I believe) that I can go through all the steps. I have a lot of experience in this area so I have no problem wrecking my PC to help out. :yesnod: That's what we do!!

I think you are mostly running into the fact that Microsoft nor Symantec want to claim responsibility for the matter. It would not surprise me if each one of them said that it was the other's fault. Unfortunately, that is the run around most people get.

I still do not see how the Windows 7 activation would come in to play. If Microsoft told you that this would happen then I think they are mistaken. It would be no different than doing a sector-by-sector copy to a larger HDD - no re-activation required. So they are probably just saying that because they really have no idea.

I think the Windows Recovery Environment is for those that are only looking to create an image that can be booted to in order to restore back to a certain time. What you are trying to accomplish would not work.

Again, if you don't want to run through the process I can try it out this weekend, most likely Saturday. :yesnod:


Are you sure you don't mind doing this? I know if anything went wrong with my current setup now they'd be calling an ambulance for me due to the impending heart attack.

By the way, I apparently misunderstood what you were referring to regarding the "recovery environment". I thought you meant the Repair option on the Windows 7 install disk. Yes, you are correct, the recovery environment is only for restoring back to an earlier time.

Also, at present, so long as it stays that way, I seem to have gotten past the problem with the imaged copy being shown as not a "Genuine" copy of Windows. Now it's back to the original boot loader problem. I'm not 100% certain how I got past the pirated copy claim so I'll hold off on commenting on that one. Suffice it to say both Microsoft and Symantec where scratching their heads on that one too.

If I'm reading my Ghost software correctly what you've proposed can be fully automated via their control panel ("control panel" is refernceing the Ghost initial setup screen before making the image) after the commands are typed/pasted into a text document and saved to a location I can later browse to from that control panel. I can then select from the list as to when I want the various commands to be executed by having those commands placed in seperate text documents built around the timing of when I want them to occur.

For example, I can tell it to work on what is to be done before the snapshot is taken. That information would be contained in one text document and browsed to during the initial optioning. Then I can select what I want to be done after the snapshot is taken, but before it goes to creating the image. This contained in another text document and browsed to. Finally, I can select what I want executed after the image is created, and again, that contained in yet another text document. Easily managed in this kind of a format.

The trick is to get the right commands in there without errors. This is the area that I'm going to be shut down in as I'm not skilled in command prompt usage. :pc
The best I can do right now is copy/paste what someone else tells me should be entered after the command prompt and hit the enter key. Then it's pray a lot. Spaces and everything else has to be exact or I'll make a mess of it. Right now I'm lucky that I can actually change the drive name via the BCDEDIT. After that forget it. :uhhh

Once all this is done and working I suspect that this is the valuable part to not only Symantec, but also DBP. The ability to produce and automated dual boot interface designed around user friendliness via something such as DBP that contains a toggle for an image created drive, something that apparently is not yet on the market, might be as simple as packaging the product with a pre-setup for changing the ID mark on the imaged OS copy. If we can do this you may have the only Boot Loader interface that can do it currently on the market. Sort of a DBP exclusive.

Keep in mind that I am working with Norton Ghost software for this, but that will not change what needs to be done by others generally for the ID if Ghost is not the image software being used. It alleviates the additional work to be done by the average user who isn't going to know what to put into that control panel area of Ghost anyway. Additionally, even if they have preset Ghost or any other imaging software to complete the scripting it seems to me that inadvertently using a DBP toggle to select an imaged copy of the same OS only becomes a redundancy that really changes nothing since the end result is to change the ID mark in either case. You're just doing it twice. The object of DBP is the ease of understanding and use as an interface.

I'm more than happy to not get rushed if you think you'd like to tackle this Saturday. I thank you for the interest and effort. I just hope you don't find yourself in a mess and then decide to take it out on me. :whistle

Right now Symantec is looking at the issue because this problem leaves a crippling affect on some of their capabilities. The average user simply has one hard drive, nothing more. Many only dual boot a different OS entirely. For the rest of us though a dual boot with the imaged copy being the second boot is the mainstay and likely a market chunk they don't want to lose over this. The more user involved though it becomes the less likely they will garner sales for what users will have to have the know-how to manually effect. Up until today Windows XP didn't require the additional scripting nor much of any manual work beyond altering the boot.ini for naming drives as they would appear in the dual boot selection list and assigning their defaults. With Windows Vista/7 that changed.

People like me who have great difficulty keeping some things strait in their minds find returning to command prompt days an utter nightmare. If you want to feel sorry for me now, keep in mind that I was doing this back in the 70's with MS-Dos 1.1. There is NO WAY I would want to return to writing script like we did back then and today I couldn't begin to remember it, much less handle it. Who was it that said something about the "good ole days"? MY BUTT! :yesnod:
PRO Level 2
Posts: 26
Joined: Thu Apr 22, 2010 5:01 am

PreviousNext

Return to Windows Boot Problems

Who is online

Users browsing this forum: No registered users and 5 guests

cron
cron