Problem with restored image using BARTPE

After restoring a system image using Acronis' TI 8 plug in for BARTPE, the new drive logs off right after entering the password for my userid. It then returns to the logon screen and logs off again after I put in the password.

I'm a little concerned that BARTPE assigned a drive letter letter to the drive [other than C:].

In any case, any idea of what's going on?

Thanks

 

New drive? Please explain.

 

BartPE would not change the drive letter. That is not the problem.

How did you create the backup in the first place? If you made the image with TI8 and only chose to image the system partition (not the entire disk), you did not backup the MBR. Including the MBR in a partition only backup is a feature that was introduced in TI9. Try repairing the MBR. See the fix Master Boot Record section in the Read Before you Post sticy thread.

 

I created the image using the TI 8 plug [from Acronis' site] into BARTPE.
The image was created on a USB drive. The source is on a Gigabyte SATA controller with AHCI enabled. The drivers for the Gigabyte SATA controller are in a subfolder in the SCSIAdapter folder.
When choosing which drive to restore to, the drive [a blank test drive] on the Gigabyte SATA controller shows Interface 'unknown'. Even so, the restore completed successfully.

Thanks

 

OK. So, now we know you restored the image to a drive without a MBR. Now you need to answer my question. Did you image the full disk or just the system partition?

In either case your next step should be to repair the MBR. Did you try that?

 

The disk has two partitions - I imaged the partition with WinXP.

Also, have created a BartPE with TI 9 plug in from your site.
Created new image and restored. When restoring, options only let you chose either the partition or the MBR. After restoring the partition, I restored the MBR.

Works fine.

Thanks.

 

Hi mustang,

I find this an interesting topic. Jelenko's original problem was failure to boot around the Welcome screen stage. This is well past the MBR stage of the boot process. I've tested numerous restores (to a different HD) from the Acronis TI CD and with your plugin on a Reatogo CD and I've deliberately not ticked restore MBR. All restores have worked and I was using a partition image of the C: drive. Before each restore I zeroed Absolute Sector 0 with a disk editor so there was no MBR. Naturally there was a MBR after the successful restore so TI is writing a generic MBR. It's not your original MBR but that doesn't matter unless you need a special MBR for a boot manager etc. Ghost works the same way. It writes a generic MBR if you don't tick Restore MBR. Partitioning tools create a generic MBR as well.

Jelenko's second restore worked but he used a different image and software. I believe it would have worked even if he hadn't restored the MBR. Mine always do.

Any comments?

 

jelenko,

We experienced the same symptoms when restoring a Drive SnapShot image to a new HD in a friend's laptop a few months ago. We even reset the password but it just kept returning to the logon screen. I cleared the DiskID with Clear Sig (from BING) and the OS booted properly on the next attempt.

We see this boot problem frequently with bad cloning technique but it's unusual with image restoring.

 

Hi Brian,

I don't know exactly how TI handles the MBR. I have seen a few cases where the restored system fails somewhere around the Welcome screen. In all the cases I've seen, doing a MBR fix has worked. Doing the fix is so fast and easy, I always try it first. I'm sure there is more than one way to fix such problems.

Hi jelenko,

Glad to hear you got it sorted out. Just so you know, you can restore a partition image and the MBR in the same operation with TI9. First, you pick the partition. Then one or two screens later you are asked if you want to restore another partition. If you say yes, you will then be able to pick just the MBR. This will get it done in one operation.

 

That's interesting, Mustang. How did you fix the MBR? If you used fdisk /mbr then that clears the DiskID as well. If you used fixmbr then I have no answer.

 

Hi Brian,

I've been using XFDISK. It is the version that Acronis links to in the Read Before You Post Thread. I like it because they give you an ISO image that boots from a CD. It probably does clear the DiskID just as fdisk /mbr does.

 

Mustang, thanks for that. I used it from a floppy and ran xfdisk /mbr. I then checked Sector 0 with a disk editor and you are correct. It does also zero the DiskID. This is important as it may explain why fixmbr doesn't work in this situation because it doesn't clear the DiskID. In my post above I fixed the problem with Clear Sig which doesn't change the boot code.

In summary my tests indicate that you don't always need to restore the MBR and I accept that xfdisk and fdisk /mbr can correct a non booting OS. But this may have nothing to do with a MBR error as clearing the DiskID is a fix for partition signature problems.

 

Hi Brian,

Thanks for the info. Every bit of knowledge helps.

 

Mustang, it’s becoming more interesting. I can now demonstrate that the MBR is not involved in the non booting scenarios described in this thread.

My test computer had two HDs. WinXP and a data partition were on the first HD and a primary partition (empty) was on the second HD. Using ReatogoXPE and your ver 9 TI plugin I created an image of the C: partition, written to the data partition. Without shutting down I restored this image to the second HD which was designated E: drive. I didn’t restore the MBR or Track 0. I chose “I do not want to assign a drive letter” because the other alternative of D: onwards was inappropriate. I couldn’t choose C: as a drive letter as there already was a C: drive. After the restore I shutdown, removed the first HD and set the second HD as Master.

About 30 seconds into the boot process WinXP froze on the blue screen with the WinXP logo. (I don’t use a Welcome screen) I have seen this screen many times before with deliberately failed clones. Repeated boot attempts were the same. This time I wanted to avoid all tools which alter the MBR so I booted to ReatogoXPE and used Registry Editor PE to delete the entries from [MountedDevices]. This was a convoluted Method #2 in reverse.

http://www.goodells.net/multiboot/partsigs.htm#method2

Guess what. The next boot was successful.

I repeated the whole test but this time I did restore the MBR and Track 0. The same thing happened. WinXP froze at the blue WinXP logo screen. WinXP booted after using Registry Editor PE as described above.

I realize my imaging/restoring scenario is artificial but I thought that it might cause problems and it did. In retrospect I had similar problems with Ghost 9 from ReatogoXPE last year but I didn’t follow it up. Something strange is happening in ReatogoXPE which I don’t fully understand but the explanation must be related to drive letter assignments in ReatogoXPE.

http://www.goodells.net/multiboot/partsigs.htm Dan's page is about cloning rather than imaging.

I’d be grateful for other thoughts.

 

Hi Brian,

I'll play with this and see if I can figure out what's going on. In the meantime, would you please try doing the same restore procedure from the Acronis Linux Recovery CD. Let me know if you get the same results.

 

Hi Brian,

I really don't understand the relationship between the DiskID, MBR and assigned drive letters under HKLM\Mounted Devices. Take a look at Method 3. Dan mentions "One way of doing this is to delete or alter the DiskID in the MBR." To me, this implies the DiskID is included as part of the MBR. This explains why using fdisk /mbr works. Method 3 seems to be the easiest way out of trouble once this situation occurs. To explain it to people, all you have to do is refer them to the MBR section of the Read Before You Post thread.

I don't think BartPE or Reatogo XPE does anything that would affect the DiskID, MBR or the assigned drive letters in Windows. I know we saw that Ghost 10 does attempt to use the assigned drive letters (and fails miserably), based on Night Owls work. Again I'm interested if you get the same results from the Acronis Linux environment. If you don't, it may be because Acronis handles things differently in the Linux and Windows versions. Keep in mind under BartPE we are using the Windows version. Even though True Image looks the same under Linux and Windows, it is based on different programs and could yield different results.

 

Mustang, I'll do your test this afternoon. Archery this morning.

Just briefly, I think I understand what went wrong in ReatogoXPE. Even though I restored an image the final result was a partition copy. A clone, and I broke Dan's first rule of cloning. "Do not let old-XP see the new partition before cloning."

http://www.goodells.net/multiboot/partsigs.htm

This rule certainly applies to Ghost 9/10 but not to TI used from WinXP as Dan explains in a Radified post. If you clone into a partition with Ghost 9/10, rather than unallocated space, the clone won't boot. The easiest way to fix this problem is to do what you already do. Method #3. xfdisk clears the DiskID as a side effect of writing new boot code. In my previous post I certainly wasn't suggesting that anyone follow my registry edits. You have always used the best way.

 

I repeated the test with the HDs and partitions the same as yesterday. Using the TI CD I restored the image to the partition on the second HD and I didn't tick Restore MBR and Track 0. WinXP booted normally as expected.

As Dan Goodell points out, this failure to boot is a WinXP problem if you don't follow the rules of "cloning". It's not the fault of the imaging application although some apps handle the variables better than others.

I hope this information helps other to avoid or to recover from this type of boot failure. I set out to demonstrate that it's not from failing to tick Restore MBR and Track 0.