Possible bug, writing image or cloning MBR OS to a former GPT disk


Author
Message
Rootman
Rootman
Talented Member
Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)
Group: Forum Members
Posts: 83, Visits: 1.2K
I just swapped a small home server to new hardware.  It went pretty well.  I posted about my adventure a few days ago on this forum.  Because it was fairly difficult to set back up I elected to image the current old hardware's Windows 10 64 OS that was up to date and restore it to the new hardware's SSD.  It went fine with one exception.  The main OS partition was not marked active to the new SSDs image when applied.   The OLD hardware was still running MBR / GPT because this was updated from Windows 7 years ago.  The new server's SSD was set for GPT.  Not a biggy, maybe just a glitch. I fixed it with a partitioning software I have.  

While clearing out some junk I found an SSD I had in a former laptop, it was a better SSD and larger than the one I had in the new server.  I elected to use it on the new server.  This new SSD was also a GPT disk, so once again it had to be converted to MBR / CSM.  So I popped it into one of the drive slots and ran Macrium on it to clone it from the present MBR / CSM to this new SSD.  Afterwards I downed the server, pulled both SSDs and swapped the new larger SSD for the former one in the SATA 1 slot.  I was not really surprised that when I tried to boot to it it came up with a NO BOOT DEVICE.  Yep, same issue, the OS partition was not marked active during the writing of the image from the older MBR / CSM drive to the new formerly GPT drive.  Just like when I did the swap of the servers OS via a backup the first time.  

So, twice in a row, once during a restoration of a MBR / CSM backup to a new drive that was formerly a GPT drive.  And secondly again when cloning the fixed and working MBR / CSM drive to the second larger and former GPT drive.  Both times it failed to make the OS partition active.  So I see a pattern here. Am I missing an option or a step?

This should not happen again because I converted the new SSD to GPT / EFI, which in itself was an adventure.  MS's own mbr2gpt wouldn't do it, first because there was already 4 partitions on it, then after I removed one, it could not find the OS partition. Luckily I had my trusted copy of MiniTool Partition wizard that converted it just fine.  

So, just in case I am faced with doing a MBR drive to a former GPT drive again, is there some step I need to take in order to assure the new drive's OS partition is marked active?  
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
There is no concept of marking a partition as "active" on a disk initialized as GPT.  That concept only exists for MBR.  Your post is a bit confusing because you say the old hardware was running MBR / GPT (a given disk can only use one or the other) and that you had to convert to MBR / CSM (MBR is a partition layout scheme, while CSM is a UEFI compatibility boot mode).  Those terms are not interchangeable.  But if you restore a Windows partition from an MBR disk onto a GPT disk and want to be able to boot from it in UEFI mode (which for Windows 7 will indeed require enabling UEFI CSM), then you have to create a boot entry for it.  UEFI systems don't boot the same way as Legacy BIOS systems at all.  On Legacy BIOS systems, your boot order lists any available disks in your system, and if the system selects that disk to boot from, then it boots from the active partition.  UEFI's boot options for local storage are actually paths to a specific bootloader file on a specific partition of a specific disk.  That path has to be registered into the UEFI firmware.  This is typically handled by OS installers like Windows Setup, but if you clone a disk, then that won't happen -- although Fix Boot Problems should address this as long as your Rescue Media was booted in UEFI mode and therefore knows to attempt that particular fix.  (If you're wondering how it's possible to boot in UEFI mode from flash drives and how some UEFI systems do that without any further effort, it's because the UEFI spec defines a default path of \EFI\Boot\Bootx64.efi for a bootloader file, so if a given disk has a partition that contains that file at that path, then the system can look for that.  However, Windows Boot Manager doesn't use that path even though that file does exist on EFI System Partitions of GPT disks set up by Windows.  And Dell systems for example will only show boot options discovered by scanning for that path when using the one-time boot menu.  The boot options shown in the BIOS Setup interface that can be reordered only include options registered into the firmware.)

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Fyi Macrium has a KB article specifically focused around restoring an OS image from an MBR disk in a Legacy BIOS system onto a GPT disk for UEFI booting here, in case that is ever helpful.

Rootman
Rootman
Talented Member
Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)
Group: Forum Members
Posts: 83, Visits: 1.2K
jphughan - 22 June 2020 1:47 PM
There is no concept of marking a partition as "active" on a disk initialized as GPT.  That concept only exists for MBR.  Your post is a bit confusing because you say the old hardware was running MBR / GPT (a given disk can only use one or the other) and that you had to convert to MBR / CSM (MBR is a partition layout scheme, while CSM is a UEFI compatibility boot mode).  Those terms are not interchangeable.  But if you restore a Windows partition from an MBR disk onto a GPT disk and want to be able to boot from it in UEFI mode (which for Windows 7 will indeed require enabling UEFI CSM), then you have to create a boot entry for it.  UEFI systems don't boot the same way as Legacy BIOS systems at all.  On Legacy BIOS systems, your boot order lists any available disks in your system, and if the system selects that disk to boot from, then it boots from the active partition.  UEFI's boot options for local storage are actually paths to a specific bootloader file on a specific partition of a specific disk.  That path has to be registered into the UEFI firmware.  This is typically handled by OS installers like Windows Setup, but if you clone a disk, then that won't happen -- although Fix Boot Problems should address this as long as your Rescue Media was booted in UEFI mode and therefore knows to attempt that particular fix.  (If you're wondering how it's possible to boot in UEFI mode from flash drives and how some UEFI systems do that without any further effort, it's because the UEFI spec defines a default path of \EFI\Boot\Bootx64.efi for a bootloader file, so if a given disk has a partition that contains that file at that path, then the system can look for that.  However, Windows Boot Manager doesn't use that path even though that file does exist on EFI System Partitions of GPT disks set up by Windows.  And Dell systems for example will only show boot options discovered by scanning for that path when using the one-time boot menu.  The boot options shown in the BIOS Setup interface that can be reordered only include options registered into the firmware.)

OLD DISK I backed up from was MBR / CSM.

NEW DISK I restored to was originally GPT / EFI in whatever device it resided in a while back.  It wwould not boot from the disk after I restored the OS even though all the layout for the MBR / CSM disk was there.  I used a utility to mark the OS partition ACTIVE and it booted fine.

LATER I scrounged up a larger, better SSD and decided to use it in the new hardware.  I CLONED the disk this time, from the last SSD I had just setup in the step above to the SSD I just dug up. After the clone it too would not boot until I used a utility to mark the OS partition active.

Something is not completing the process when it involves imaging MBR / CSM to disks previously used as GPT / EFI. In the past I've use Macrium to clone and restore MBR / CSM systems to new disks before, it worked wonderfully. For these systems the new disks I was prepping were either brand spanking new or had previously been used as MBR / CSM.  The difference I can see here is the 'new' disks I experienced the boot failures on were previously used in GPT / EFI systems rather than MBR / CSM.   The clone and restore both 'failed' to create a bootable OS because the OS partition was not marked active. .  .  

I threw in the conversion of the final SSD drives system from MBR to GPT as an extra.  It has nothing to add to the above situation and only serves to point out that MS's mbr2gpt is woefully inadequate and something like Minitool Partition Wizard works great where mbr2gpt fails. . 
Rootman
Rootman
Talented Member
Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)
Group: Forum Members
Posts: 83, Visits: 1.2K
jphughan - 22 June 2020 1:50 PM
Fyi Macrium has a KB article specifically focused around restoring an OS image from an MBR disk in a Legacy BIOS system onto a GPT disk for UEFI booting here, in case that is ever helpful.

Thanks, I was trying to just do a straight clone of the older systems MBR / CSM OS.  It failed to make a bootable OS disk using 2 different methods. A backup and restore of the complete disk and a clone of the disk.  On both the backup and restore to 'new' SSD #1, and then again when doing a disk clone from SSD #1 to a larger SSD #2. 

For some reason the resulting OS partition was not marked active and the boot would not proceed.  In both cases the used SSDs were previously setup GPT / EFI  and were being reimaged as MBR / CSM.  I merely point out the failure because I can imagine someone without as much experience might not realize they have to fix it by marking the partition active. It happened doing a disk switch using 2 different methods, so I suspect Macrium is not doing the partition activation correctly using either method.     

I did the GPT conversion AFTER getting the second SSD up and running, primarily so that it was done with.  I suspect the next hardware I swap to will not support MBR / CSM booting.  This way it's done and ready in any case. 
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
I'm not sure what your utility did or precisely what state your disk was in when you used it, but as I said, there is no concept of marking a partition "active" on a disk initialized as GPT.  It simply isn't a thing.  Here is an example of attempting to do that using Diskpart:

DISKPART> list disk

Disk ### Status   Size  Free  Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0  Online    238 GB  0 B   *
Disk 1  Online    10 GB 1024 KB   *

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> select partition 1

Partition 1 is now the selected partition.

DISKPART> active

The selected disk is not a fixed MBR disk.
The ACTIVE command can only be used on fixed MBR disks.


This is not a Macrium oversight.

However, the way in which you perform a clone or image restore can affect the partition layout scheme of the target disk after that operation.  If you choose to restore/clone an entire MBR disk onto a target that starts as GPT, then the target disk will be MBR afterward.  If on the other hand you only clone/restore certain partitions, then the partition layout scheme of the target will be preserved.

You cannot perform a simple MBR to GPT conversion of a disk that contains an OS.  In order to boot an OS in UEFI mode from a GPT disk, you need an EFI System Partition.  A simple MBR to GPT conversion will not create that.  Microsoft has a utility that DOES take all necessary steps to convert an MBR disk set for Legacy BIOS mode into a GPT disk that is properly configured to boot in UEFI mode -- which they confusingly just named MBR2GPT -- but that is more involved than the conversion process that would be used to convert a data disk.  Documentation of MBR2GPT is here.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Ok, I think I see what you're saying.  Am I correct in my understanding that if your finding is that if you start with a target disk initialized as GPT, clone/restore an entire MBR disk onto that disk, then afterward the target will be initialized as MBR but will not have a partition marked as active?  If so, I'm curious about that so I'll test it out to see if I can reproduce, but that wasn't entirely clear because you described a bunch of different scenarios.  It's a lot easier to follow if a problem report just lists the starting conditions (e.g. MBR source disk/image, GPT target), steps to reproduce, and observed vs. expected results rather than writing it as an "adventure", as you put it.

Edited 22 June 2020 2:53 PM by jphughan
Rootman
Rootman
Talented Member
Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)Talented Member (115 reputation)
Group: Forum Members
Posts: 83, Visits: 1.2K
jphughan - 22 June 2020 2:46 PM
I'm not sure what your utility did or precisely what state your disk was in when you used it, but as I said, there is no concept of marking a partition "active" on a disk initialized as GPT.  It simply isn't a thing.  Here is an example of attempting to do that using Diskpart:

DISKPART> list disk

Disk ### Status   Size  Free  Dyn Gpt
-------- ------------- ------- ------- --- ---
Disk 0  Online    238 GB  0 B   *
Disk 1  Online    10 GB 1024 KB   *

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> select partition 1

Partition 1 is now the selected partition.

DISKPART> active

The selected disk is not a fixed MBR disk.
The ACTIVE command can only be used on fixed MBR disks.


This is not a Macrium oversight.

However, the way in which you perform a clone or image restore can affect the partition layout scheme of the target disk after that operation.  If you choose to restore/clone an entire MBR disk onto a target that starts as GPT, then the target disk will be MBR afterward.  If on the other hand you only clone/restore certain partitions, then the partition layout scheme of the target will be preserved.

You cannot perform a simple MBR to GPT conversion of a disk that contains an OS.  In order to boot an OS in UEFI mode from a GPT disk, you need an EFI System Partition.  A simple MBR to GPT conversion will not create that.  Microsoft has a utility that DOES take all necessary steps to convert an MBR disk set for Legacy BIOS mode into a GPT disk that is properly configured to boot in UEFI mode -- which they confusingly just named MBR2GPT -- but that is more involved than the conversion process that would be used to convert a data disk.  Documentation of MBR2GPT is here.

Nope, I was doing a MBR to MBR disk clone, first my doing a total disk recovery from a backup, second on a DIFFERENT SSD by doing a clone.  This is something that I have done dozens of times in the past although every time was to NEW disks that were previously used as MBR disks, or brand new disks right out of the package. Both methods I used this time worked and booted but ONLY AFTER I manually marked the OS partition as activate.  After doing the activation using a different tool both SSDs booted MBR in the same server just fine.  

The NEW sever I was prepping WAS set to MBR / CSM boot.  The resulting new images on the disks would not boot until I manually activated the proper partition.  This is something that had worked fine for me in the past when doing a MBR to MBR disk swap.  The only difference is that in both cases for this NEW server of mine the disks I was swapping TO had both previously had GPT / EFI systems on them.  These 'old' GPT / EFI systems were totally wiped during the restore / clone process.  

AFTER I had it all fixed up from the lack of active partition in the MBR / CSM system I then used Minitool Partition Wizard to do the GPT conversion.  I flipped the boot mode in the computers setup to EFI, rebooted and it works fine.  This part has actually NOTHING to do with the above MBR boot failure above.  I just threw it in to let people know to NOT rely on MS's mbr2gpt tool to actually work.  
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Ok, first you said you were doing an MBR to MBR disk clone.  Then in your next paragraph you said that the disks were "previously" GPT.  Are you saying that before you started the image restore/clone process, the disk was still GPT, and the image/clone job involved imaging/cloning the entire MBR disk to the destination?

Again, it would be helpful to summarize the exact start state of all relevant items, the exact steps you performed, and the end result -- in a simple list form -- rather than writing paragraphs and providing a bunch of additional background on unrelated tasks, etc.  In addition to being clearer and more efficient to read, it makes it much more likely that someone else will be able to accurately reproduce what you actually did, and therefore identify and address the problem if it's reproducible.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Ok, I just tried to reproduce what I thought you were describing -- and I succeeded.

Below is a concise problem report for @Nick or whoever else might be appropriate to work this.

Summary
When cloning an entire MBR disk onto a target that is initialized as GPT, the partition marked as "active" on the MBR source is not marked as active on the target, even though the target has been switched to MBR as a result of the operation.  (I did not test an image restore scenario, but I suspect this might occur in that setup as well.)

Starting setup
  • Reflect 7.2.4971, running on Win10 2004
  • Source disk initialized as MBR with two partitions formatted as NTFS, with Partition 1 marked as Active.
  • Target disk initialized as GPT with one partition formatted as NTFS.
Steps to reproduce
  • Select the MBR disk and click "Clone this disk".
  • Select the GPT disk as the target.
  • Click Next, ensuring that "Copy selected partitions when I select 'Next'" is checked.
  • After the clone, the target disk will be MBR as expected, but the active partition from the source will not be active on the destination.
Screenshots for reference
Pre-clone setup. Note that Partition 1 on Disk 3 is indicated as "NTFS Active".


Post-clone setup. Note that Partition 1 on the destination is indicated only as "NTFS Primary", not "NTFS Active".


Edited 22 June 2020 3:36 PM by jphughan
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search