PDA

View Full Version : Inserting new partition


Earthling
April 21st, 2008, 04:29 AM
If a new primary partition is created Windows will assign it a new drive letter which precedes any logical partition lettering, all of which then have to bump up one letter. This then stops lots of things from working properly afterwards - all those reg entries pointing to the wrong place.

I seem to remember when I had PM8 under XP that it had a utility bundled with it (Drive Mapper I think) that could sort this mess for you if you gave it the old and new drive letters that had been affected.

Is there anything comparable for DD10 in Vista?

K0LO
April 21st, 2008, 08:33 AM
Earthling:

DD10 does not have an equivalent to DriveMapper. There was some discussion of this issue here about a month ago; here is a link (http://www.wilderssecurity.com/showthread.php?t=203410).

As long as your system partition's drive letter does not change then you can use Windows Disk Management console to change the other drive letters to whatever you'd like to have and, once stored in the registry, those new drive letter assignments will be persistent.

Earthling
April 21st, 2008, 01:23 PM
Mark

Cutting a rather long story short, could the fact that my VistaPE partition on the eSATA is positioned right at the end of a 320GB drive cause it not to boot?

Or could the fact that to avoid the problem referred to in #1 I have used Disk Management to assign it the letter J instead of the D that both Windows and VistaPE prefer also be the cause of it not booting?

K0LO
April 21st, 2008, 01:29 PM
Earthling:

Is the main problem that your VistaPE partition is no longer bootable?

If so, it will have nothing to do with the drive letter -- drive letters are a Windows "thing" and only have meaning when Windows is running. At boot time, drive letters are meaningless. There is low-level assembly language code running that is unaware of drive letters.

What caused VistaPE to stop booting? Is it still in a primary, active partition? Did you move or relocate the VistaPE partition?

Earthling
April 21st, 2008, 01:51 PM
Mark

Yes, that is the problem. In the aftermath of losing Vista a week ago I removed the VistaPE partition, determined that I would never again use anything labelled Acronis after losing Vista doing nothing more than a test disk backup and restore.

I've since reconsidered that, and although after our earlier efforts I'm confident that I fully understand the process of creating the VistaPE partition it persistently fails to boot and I'm really scratching my head as to why this should be. It is in a primary, active partition identical as far as I can see to the one it was in when it did boot.

K0LO
April 21st, 2008, 03:59 PM
What differences, if any, are there between the working VistaPE partition and the non-booting one? Same hard disk as before? Is the disk the BIOS disk #1 as before? Same slot in the partition table as before? Same format? Any specifics would be helpful in identifying a cause.

I am unfamiliar with your failed Vista restoration attempt but with multiple hard disks each with active partitions then the chances are that Windows reassigned drive letters at first reboot. Then again, that's another topic...

Earthling
April 21st, 2008, 05:25 PM
This what is so puzzling. Apart from setting up a 2GB partition v. 4GB before everything else is identical, same disk, no BIOS changes, both FAT32, both positioned at end of disk. DD confirms partition is Primary, Active, and the bootsect.exe command is being executed onto a freshly DD formatted partition using the Command Line in the Repair Computer option when booting from a Vista DVD.

It's a puzzle.

K0LO
April 21st, 2008, 05:49 PM
From one of your previous threads in the TI forum, I thought that you only were able to boot VistaPE when the partition was formatted as NTFS:

http://www.wilderssecurity.com/showthread.php?t=204580&page=2, posts #26-30.

Two other thoughts come to mind:

1. A screen shot of your disk partition layouts from DD running in Windows, manual mode, may be helpful.
2. Perhaps it's worth a try to boot VistaPE from Grub4DOS - one advantage is that you can locate the partition anywhere on either disk. For example, if you locate it on IDE-1 then Grub4DOS can do a drive map to fool VistaPE into thinking that it is running from IDE-0.

Earthling
April 21st, 2008, 06:14 PM
Here's the view from DD

K0LO
April 21st, 2008, 07:39 PM
Earthling:

Would you mind doing a test? Install Grub4DOS as a boot manager on Disk 2. You can follow the instructions in MudCrab's VistaPE guide (http://www.purviancecs.com/vistapeflashdrive.htm) starting at step 3. Be sure to select Disk 2 as the destination when installing Grub4DOS to the MBR.

I'm curious to see if using a boot manager will allow VistaPE to start. Often, a boot manager will overcome some of the limitations of a PC BIOS.

If you can boot from Disk 2 and see the Grub4DOS menu come up but VistaPE still does not start, then insert the following two lines into the VistaPE boot stanza of GRUB's menu.lst file and try again:

title VistaPE
map (hd0) (hd1)
map (hd1) (hd0)
chainloader /bootmgr

MudCrab
April 21st, 2008, 08:30 PM
On my internal backup drive, I have VistaPE installed to a small FAT32 Primary/Active partition at the end of the drive. Grub4DOS is installed into the MBR of the drive. To boot the drive I just select it as the boot drive in the BIOS. No mapping was needed.

K0LO
April 21st, 2008, 08:45 PM
Paul:

Agreed. That's the way it should work. But if it doesn't, then I was suggesting to swap disk order with GRUB.

Because of the problems Earthling had (described in this thread (http://www.wilderssecurity.com/showthread.php?t=204580&page=2)), I suspect that his BIOS does not enumerate the booting disk as Disk 0 (80h). One of the posts stated that VistaPE would only boot if the disk was physically connected to the primary IDE cable on his problematic PC. If that is indeed the issue then the disk order swap with GRUB should fix it.

MudCrab
April 21st, 2008, 09:06 PM
It will be interesting to see what works. VistaPE may work with the drive mapping, but there have been cases with OSS and using the Disk Order feature (which does the same type of thing) where Vista won't boot properly if it's swapped. VistaPE may be a little less sensitive.

Perhaps dropping to the GRUB command prompt and doing a find to find out how it sees the drives. It may not be what we think.

Earthling
April 22nd, 2008, 06:00 AM
Mark

The thread you have been studying, and which you linked to in your last post, related to trying to get a VistaPE partition booting on my old XP comp, so is not really relevant to the newer Vista + XP comp in the pic above.

Right now I'm not going to tamper any more with the boot setup, as during my efforts to persuade VistaPE to boot I went into BIOS and disabled Disk 1, the system disk. Even having done that VistaPE still would not boot from Disk 2, but when I re-enabled Disk 1 it then failed to boot automatically to the boot order. I'm having to use F8 atm to tell it which disk to boot from. Nothing at all happens if I just leave it to the BIOS. After having lost Vista just last week this is making me a bit nervous.

I will come back to your suggestions when I am happy that everything is stable and booting normally.

K0LO
April 22nd, 2008, 08:25 AM
Earthling:

OK, I got confused about which computer you were describing.

It may be worthwhile to take a good look at the disk order choices in your BIOS. There may be more than one or two screens with selections. Some PCs have a disk order screen (which disk in considered disk 0, disk 1, etc) and a separate boot order screen (which device boots the PC).

Earthling
April 22nd, 2008, 12:25 PM
We've got a bloke just like you Mark on the Tiscali forum in the UK. Always puts his finger on the problem when everyone else is scratching their head.

Booting normally from BIOS again, so now when I've got a spare hour or two I can start to look at your other suggestions.

Thanks :)

Earthling
April 22nd, 2008, 01:23 PM
Mark:

Grub4DOS has sorted it, no mapping necessary. Well done.

When you have nothing better to do - ha - would you please take a look at this short thread please? I would like to know what may have gone wrong and how I ensure it doesn't happen again.

http://www.wilderssecurity.com/showthread.php?t=206513

K0LO
April 22nd, 2008, 02:11 PM
Earthling:

Glad to hear that you have VistaPE booting again.

For the Vista restore with TI 11 problem:
-{ Quote: "Booting from VistaPE -

1. Created and validated a new whole of disk image of the internal SATA
2. Created an incremental of the XP partition only
3. Used DD to clear the internal SATA completely
4. Restored just the XP partition and MBR from 2
5. Rebooted - XP fired up
6. Restored all remaining partitions from 1, including Vista
7. System failed to boot - missing \windows\system32\winload.exe

A Vista repair also failed to resolve matters." }-Whenever the error mentioned in item 7 occurs it means that Vista's Boot Configuration Database (BCD) is not pointing to the correct location on the drive. I suspect that all you would have needed to do was to repair the BCD to make Vista bootable. But I don't understand why the Vista automatic repair was unable to do so.

Here is a little conjecture on my part. We don't know (or should I say I don't know) how TI 11 is able to move a partition upon restoration and avoid the "winload.exe is missing" error message. Acronis is doing something behind the scenes to avoid this, but I suspect that they have only worked this out for a plain-vanilla Vista installation that boots and runs from the same partition.

In your case you have a dual-boot system with the Vista boot files in the XP partition and Vista in another partition. So my guess is that however TI 11 handles this, it does it incorrectly for your dual-boot setup.

Since you have experience with running the Vista DVD, it would be a simple matter to do a manual repair of the BCD. Again, the automatic repair should have sorted this, but you could certainly do it manually.

If you don't mind, could you boot into Vista and copy the output of the command bcdedit and post it back here? The details might let us make a more-educated guess as to what went wrong.

Earthling
April 22nd, 2008, 02:48 PM
Here you go


Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=D:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {b339c4d1-f144-11dc-92e2-ce65acb18766}
displayorder {ntldr}
{current}
toolsdisplayorder {memdiag}
timeout 30

Windows Legacy OS Loader
------------------------
identifier {ntldr}
device partition=D:
path \ntldr
description XP SP2

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Vista SP1
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {b339c4d1-f144-11dc-92e2-ce65acb18766}
nx OptIn

K0LO
April 22nd, 2008, 03:52 PM
-{ Quote: "
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=D:
description Windows Boot Manager
locale en-US
inherit {globalsettings}
default {current}
resumeobject {b339c4d1-f144-11dc-92e2-ce65acb18766}
displayorder {ntldr}
{current}
toolsdisplayorder {memdiag}
timeout 30

Windows Legacy OS Loader
------------------------
identifier {ntldr}
device partition=D:
path \ntldr
description XP SP2

Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \Windows\system32\winload.exe
description Vista SP1
locale en-US
inherit {bootloadersettings}
osdevice partition=C:
systemroot \Windows
resumeobject {b339c4d1-f144-11dc-92e2-ce65acb18766}
nx OptIn
[/color]" }-
Thank you. All you have to watch out for if you run into this problem again is that the four entries highlighted in red come out properly. If any of the partitions are moved or relocated during the TI restore then the above entries will instead be listed as "unknown". From your described symptoms, the two pointers to D: were correct because the boot manager started and XP was able to be booted. But the two pointers to the C: partition must have been "unknown".

To fix it's a simple matter of:

1. Booting from the Vista DVD
2. Starting a command prompt
3. Typing "bcedit" to see what condition the BCD is in
4. Fixing any "unknown" entries to point to the correct partition. See the "bcdedit set" command. Type bcdedit set /? for the help file.

Earthling
April 22nd, 2008, 04:01 PM
Great, but let's hope I never need it!

All the same I think it might be quite some time before I stop also taking a Ghost image of Vista from XP from time to time, after all it saved me this time.

Anyway atm everything seems to be just as it should be, largely thanks to you.

K0LO
April 22nd, 2008, 05:17 PM
Earthling:

I have a strong suspicion of the underlying cause. If you've got some time tomorrow, run DD and view sector 0 "as partition table". Post a screen shot here. Make sure your window is enlarged enough horizontally to view all of the window contents.

If my hunch is correct I can tell you how to permanently fix it so that TI will do the restore without needing any repairs after restoration.

Earthling
April 22nd, 2008, 05:37 PM
No time like the present -

K0LO
April 22nd, 2008, 07:13 PM
In the above figure there is an "Enter" button to the left of the extended partition entry (second "slot" in the partition table). Press it to display the parameters of the first logical partition.

The first line at the top of the next screen will be an entry for your Vista partition. Is "Relative Sectors" set to 63 or 1024?

Earthling
April 23rd, 2008, 01:04 AM
It's 63

K0LO
April 23rd, 2008, 08:32 AM
Well, there goes that theory. :-\

I had suspected that your Vista partition was created by Vista and had a 1024-sector offset, but that's not the case. If it had been the case then it might have explained the behavior you saw when you restored the Vista partition -- TI would have relocated the starting sector of the partition from an offset of 1024 sectors to an offset of 63 sectors. This action would have caused the GUID (Globally Unique Identifier) of the Vista partition to change, and thus led to the loss of the pointer in the BCD file (it would have had "unknown" for an entry), causing the "Winload.exe is missing or corrupt" error message.

The restore should have worked. I can't see a reason for it not working. So what happened? I can only return to my hunch about the behavior of TI 11 and its behind the scenes modifications to ensure that Vista will boot properly, even after a 1024-offset partition gets relocated to 63-sector offset. Without knowing exactly what it does, I can only speculate that it must not do the right thing for an installation like yours, where Vista boots from partition #1 but runs from a different partition.

Dual boot installations like yours done "The Microsoft Way" are kind of delicate beasts. With tangled partitions (boot files in the XP partition, Vista in another) and each partition visible to both operating systems, restoration of a partition without triggering drive letter changes or other problems is tenuous at best. You may not be aware of this, but did you know that Windows XP will delete all of the restore points on the Vista partition if it is able to "see" the Vista partition when it is running?

If you really want to make a dual boot system robust then any OS that is not running should be hidden from the one that is running and a boot manager (like Grub4DOS or GRUB) should be used to switch between them. Then each OS can be independently deleted and restored with no effect on any other OS. Again, that's another issue and it still does not explain why your Vista restore attempt failed, but at least you know how to fix it should it happen again.

Earthling
April 23rd, 2008, 10:08 AM
Mark:

What I have been doing this morning is repeating the process in the other thread to see if it replicates. I have used TI 11 to create a full disk image, and simply restored it booting from the VistaPE CD.

Once again XP has restored successfully, as have the other partitions except for Vista. Vista looks as if it's booting normally, but when it gets to selecting a user it goes haywire. I have checked the state of the BCD and the drive letters have been changed about.

I am not confident I understand bcdedit well enough yet to correct things that way, so again I have used Ghost in XP to restore Vista and that is OK.

So you are right, ATI simply can't handle a dual-boot situation set up the Microsoft way, not if it contains Vista anyway.

I think we can leave it there, but for a programme whose only purpose is backup it's not very clever is it?

K0LO
April 23rd, 2008, 10:32 AM
Earthling:

Then that is a different issue; one where Windows reassigns drive letters when rebooting. If you were able to boot into Vista then the BCD is OK. If, when booting into Vista, you were unable to start your existing user profile then that is caused by the drive letter of the Vista partition changing. That's another problem that can crop up with a multiboot disk when the different operating systems can see each other's partitions.

Apparently Ghost can work around this by itself.

This might work. Before restoring the Vista partition, use DD 10 to hide the XP partition. Then restore only the Vista partition. Reboot with XP still hidden. Vista should assign itself the drive letter C. Then unhide the XP partition and reboot.

Earthling
April 23rd, 2008, 11:33 AM
It's becoming quite clear that I cannot successfully restore the Vista partition with ATI 11, not so long as I have this Microsoft dual boot setup anyway. If I want to be certain of it working I shall just have to continue using Ghost from XP.

It's very disappointing.

But thanks for your efforts again. :)

K0LO
April 23rd, 2008, 12:17 PM
Earthling:

Seems to be so. Here is the part that still confuses me. There should be a persistent entry in the Vista registry that identifies the Vista partition's GUID as belonging to the drive letter C. When restored and Windows boots it should assign C as the drive letter of the Vista partition.

If it does not then it means that the Vista partition GUID got changed. I think we've ruled out a change caused by relocating the partition to 63-sector offset because you had that offset to begin with and you're restoring to the same location, and the BCD does boot Vista. That leaves only my hypothetical "TI 11 is monkeying around with something to avoid a BCD repair" theory. It must force a GUID change and then copy this change to the BCD but leave the registry's MountedDevices key alone.

If so this is another bad idea on the order of the way TI 10 changes locations in the partition table in order to avoid the need to edit boot.ini for Windows XP. I note that Acronis fixed this in TI 11. Perhaps they will rethink the Vista algorithm and fix it in TI 12.

I can understand wanting to stick with Ghost because it just works for you. However, if you ever want to restore your Vista partition with TI then this procedure should do it:

1. Boot to VistaPE. Start DD 10 and hide the XP partition.
2. Start TI and restore the Vista partition.
3. Reboot the machine into Vista
4. Confirm that Vista restored properly, then start DD 10 in Vista.
5. Unhide the XP partition

I'm fairly certain that this will work for you.

MudCrab
April 23rd, 2008, 12:37 PM
-{ Quote: "What I have been doing this morning is repeating the process in the other thread to see if it replicates. I have used TI 11 to create a full disk image, and simply restored it booting from the VistaPE CD." }-
In doing it this way, you are also "repeating" the problem. You are taking a system that works (your Ghost image) and creating a TI Full Disk Image backup. Then just restoring the Vista partition. You should get the same results every time.

-{ Quote: "This might work. Before restoring the Vista partition, use DD 10 to hide the XP partition. Then restore only the Vista partition. Reboot with XP still hidden. Vista should assign itself the drive letter C. Then unhide the XP partition and reboot." }-
I think this should work too. Another option is to boot into Vista and let it fail, then fix the MountedDevices entry in the Registry to point to the correct partition.

-{ Quote: "If it does not then it means that the Vista partition GUID got changed. I think we've ruled out a change caused by relocating the partition to 63-sector offset because you had that offset to begin with and you're restoring to the same location, and the BCD does boot Vista. That leaves only my hypothetical "TI 11 is monkeying around with something to avoid a BCD repair" theory. It must force a GUID change and then copy this change to the BCD but leave the registry's MountedDevices key alone." }-
I haven't run a lot of tests on this, but from reading posts and what I have done, TI does not handle multi-boot BCD systems very well. You're lucky if one of them boots.

----------

Earthling,

If you really want to test TI on the Vista Logical partition restore, you need to do the restore, fix it and then create a new Entire Disk Image. Then restore that (or the partition from it) and see if you still have the problem. If it's consistent with how TI normally works, once you've fixed the problem further restores work okay.

Earthling
April 23rd, 2008, 12:53 PM
Mark:

I couldn't just let that go after all your efforts!

It sort of worked. Vista did restore with the letter C, but XP moved from D to G and anything pointing at E, F, or G was then pointing in the wrong place. Of course I could fix all that with Disk Management, but overall it's a lot less faff just to do it in Ghost.

Makes me wonder if there aren't quite a few users out there religiously doing their backups but not actually having proved that they would restore correctly if they had to. Not really advocating they try it either - unless they've got another backup system they can use to rescue themselves if it goes pear shaped.

K0LO
April 23rd, 2008, 01:05 PM
Well, well ... this is getting really interesting.

Paul, I think Earthling did follow your advice and, once having a correctly functioning dual-boot setup, did create an image and restore from the new image.

Earthling, there is another clue in your last post when you said that all of the other drive letters as seen by Vista had changed. What that means is that all of the partition GUIDs changed. The only thing I can think of as a cause is that the entire DiskID (in sector 0) changed. Is that how TI 11 "monkeys" with the GUIDs, by forcing them all to be reassigned?

If so, that sure isn't going to play well with a multiboot setup because it will cause a whole bunch of drive letter reassignments.

Earthling
April 23rd, 2008, 01:10 PM
MudCrab:

I don't doubt there are ways of getting ATI to work in this situation, but they are tortuous, slow, and - to me anyhow - unpredictable. I do need something I can absolutely rely upon, and at present that can only be Ghost.

Earthling
April 23rd, 2008, 01:26 PM
Mark:

That is exactly what happened. When running normally this system has either XP or Vista on C, depending on which was booted to, with the other on D. Partitions E, F, an G are data partitions on the same disk.

After using your suggested method XP went up to G, and the old E, F, and G all dropped down one. So shortcuts, Favourites, Documents etc were all pointing incorrectly.

I've just done a final restore of my Ghost image of Vista, it's fine, and I ain't mucking about with any of this stuff any longer ;)

K0LO
April 23rd, 2008, 01:41 PM
Earthling:

Thank you for being a willing guinea pig. I've learned a lot.

For anyone who reads this and is setting up a multiboot PC - set it up so that each OS is hidden from the others. You won't regret it and will avoid a lot of these issues.

Earthling
April 23rd, 2008, 02:16 PM
-{ Quote: "Earthling:

Thank you for being a willing guinea pig. I've learned a lot..." }-
Me too :)