Drive partitions are very different between two different computer OS drives: is one "broken"?


Drive partitions are very different between two different computer OS...
Author
Message
c3k
c3k
Junior Member
Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)
Group: Forum Members
Posts: 50, Visits: 125
Folks,
Two of the computers I have Macrium installed on have very similar drive layouts. Hey, I built 'em the way I like 'em. Wink

Both had Samsung 850 Evo SSD drives as the C drive with the OS (Windows 10) installed on them. I cloned one of the SSD drives to an NVMe drive, a Samsung 960, but the drive partitions remained the same between the clones. That's why you'll see one listed as an 850 and the other is a 960. The setup has these drives as standalone OS drives, the C drive, in their respective computers. But something seems amiss... (They both seem to work fine.)

Two computers: KenII and Kids.
Here are images of them as seen by Macrium. 
First, KenII:​

and next, Kids:

​​
​​
I am stunned at the VERY different architecture shown between them. Both have some over-provisioning space. That's the grey.

​1. KenII has​ the OS partition in position 4. Kids has it in position 1.
2. ​Both have the over-provisioning right after the OS partition. Good. There must be a reason for that.
3. KenII has a Recovery sector (called "none"??) as an NTFS partition in position 1. Kids does not have labeled recovery sector, but does have a sector as an NTFS partition in position 3, its last position. (I assume these are the windows recovery partitions?)
4. KenII has a partition, position 2, called "No Name" which is a FAT32 (LBA) partition. What's with that?
5. KenII also has another partition, position 3​​​, which is an unformatted primary of 16MB. Huh???

My questions, point by point:
1. Should the OS be in the same position on the drive?
2. No question.
3. Should this sector (the presumed windows10 recovery sector) be in the same place? What place should that be? (I think it should be after the OS partition, but I'm not positive.) How do I tell if that's what it is for Kids? Is there a way to relabel/rename or verify these partitions? Should they be the same size? (One is 450MB, the other is 785MB.) Can I wipe them and reinstall them?
4. What should I do with this?
5. Same question: what should I do with this?

Thanks for taking the time to look at these things. I'm puzzled and hoping for some @jphughan or other expert help. Wink

Regards,
Ken​​​​​​​​​
​​​​​​​​
Nick
Nick
Macrium Representative
Macrium Representative (3K reputation)Macrium Representative (3K reputation)Macrium Representative (3K reputation)Macrium Representative (3K reputation)Macrium Representative (3K reputation)Macrium Representative (3K reputation)Macrium Representative (3K reputation)Macrium Representative (3K reputation)Macrium Representative (3K reputation)
Group: Administrators
Posts: 1.7K, Visits: 9.2K
c3k - 28 February 2018 8:16 PM
Folks,
Two of the computers I have Macrium installed on have very similar drive layouts. Hey, I built 'em the way I like 'em. Wink

Both had Samsung 850 Evo SSD drives as the C drive with the OS (Windows 10) installed on them. I cloned one of the SSD drives to an NVMe drive, a Samsung 960, but the drive partitions remained the same between the clones. That's why you'll see one listed as an 850 and the other is a 960. The setup has these drives as standalone OS drives, the C drive, in their respective computers. But something seems amiss... (They both seem to work fine.)

Two computers: KenII and Kids.
Here are images of them as seen by Macrium. 
First, KenII:

and next, Kids:



I am stunned at the VERY different architecture shown between them. Both have some over-provisioning space. That's the grey.

1. KenII has the OS partition in position 4. Kids has it in position 1.
2. Both have the over-provisioning right after the OS partition. Good. There must be a reason for that.
3. KenII has a Recovery sector (called "none"??) as an NTFS partition in position 1. Kids does not have labeled recovery sector, but does have a sector as an NTFS partition in position 3, its last position. (I assume these are the windows recovery partitions?)
4. KenII has a partition, position 2, called "No Name" which is a FAT32 (LBA) partition. What's with that?
5. KenII also has another partition, position 3, which is an unformatted primary of 16MB. Huh???

My questions, point by point:
1. Should the OS be in the same position on the drive?
2. No question.
3. Should this sector (the presumed windows10 recovery sector) be in the same place? What place should that be? (I think it should be after the OS partition, but I'm not positive.) How do I tell if that's what it is for Kids? Is there a way to relabel/rename or verify these partitions? Should they be the same size? (One is 450MB, the other is 785MB.) Can I wipe them and reinstall them?
4. What should I do with this?
5. Same question: what should I do with this?

Thanks for taking the time to look at these things. I'm puzzled and hoping for some @jphughan or other expert help. Wink

Regards,
Ken

The text 'none' means that there is no drive letter, it isn't a partition name. 

The first is a GPT/UEFI booting system, the second is Legacy MBR. That is why there is a completely different disk layout. 

See here for detailed explanation of the different partitions:
https://knowledgebase.macrium.com/display/KNOW7/Windows+Partitions



Kind Regards

Nick - Macrium Support

c3k
c3k
Junior Member
Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)
Group: Forum Members
Posts: 50, Visits: 125
Nick - 28 February 2018 8:38 PM
c3k - 28 February 2018 8:16 PM
Folks,
Two of the computers I have Macrium installed on have very similar drive layouts. Hey, I built 'em the way I like 'em. Wink

Both had Samsung 850 Evo SSD drives as the C drive with the OS (Windows 10) installed on them. I cloned one of the SSD drives to an NVMe drive, a Samsung 960, but the drive partitions remained the same between the clones. That's why you'll see one listed as an 850 and the other is a 960. The setup has these drives as standalone OS drives, the C drive, in their respective computers. But something seems amiss... (They both seem to work fine.)

Two computers: KenII and Kids.
Here are images of them as seen by Macrium. 
First, KenII:

and next, Kids:



I am stunned at the VERY different architecture shown between them. Both have some over-provisioning space. That's the grey.

1. KenII has the OS partition in position 4. Kids has it in position 1.
2. Both have the over-provisioning right after the OS partition. Good. There must be a reason for that.
3. KenII has a Recovery sector (called "none"??) as an NTFS partition in position 1. Kids does not have labeled recovery sector, but does have a sector as an NTFS partition in position 3, its last position. (I assume these are the windows recovery partitions?)
4. KenII has a partition, position 2, called "No Name" which is a FAT32 (LBA) partition. What's with that?
5. KenII also has another partition, position 3, which is an unformatted primary of 16MB. Huh???

My questions, point by point:
1. Should the OS be in the same position on the drive?
2. No question.
3. Should this sector (the presumed windows10 recovery sector) be in the same place? What place should that be? (I think it should be after the OS partition, but I'm not positive.) How do I tell if that's what it is for Kids? Is there a way to relabel/rename or verify these partitions? Should they be the same size? (One is 450MB, the other is 785MB.) Can I wipe them and reinstall them?
4. What should I do with this?
5. Same question: what should I do with this?

Thanks for taking the time to look at these things. I'm puzzled and hoping for some @jphughan or other expert help. Wink

Regards,
Ken

The text 'none' means that there is no drive letter, it isn't a partition name. 

The first is a GPT/UEFI booting system, the second is Legacy MBR. That is why there is a completely different disk layout. 

See here for detailed explanation of the different partitions:
https://knowledgebase.macrium.com/display/KNOW7/Windows+Partitions


Nick,
Thanks. Now, I'm off to see about how to change my legacy OS drive (Kids) to a GPT/UEFI system. That seems like it will be complex, fraught with danger, and a bit fun. Wink
I would have thought that, at some point, during the Windows10 upgrade and the various OS drive formatting, that I would've made it a GPT drive.

Ken​​​​
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)
Group: Forum Members
Posts: 4K, Visits: 29K
You rang? BigGrin

Short answer:
KenII is set up for UEFI booting and Kids is set up for Legacy BIOS booting, and those are the appropriate partitions for each case.  The "None" you see pertains to the drive letter assigned (note that the corresponding location on your OS partition shows "C:" there), and it's normal for those partitions not to have a drive letter assigned.

Long answer (settle in!):
UEFI calls for using the GPT disk partition layout (note it's called a "GPT Disk") and by default uses those partitions in that layout by default, whereas the older Legacy BIOS mechanism calls for an MBR disk partition layout (as you'll notice) and by default uses the partitions you see there, although not normally in that order (more on that later).  If you're curious why the UEFI setup has 2 extra partitions, the Unformatted Primary partition is called the MSR partition (Microsoft Reserved) and stores partition layout information for GPT disks.  On GPT disks NOT used to store an OS, that's normally a 128MB partition that exists at the beginning of the disk, but Microsoft's recommendation (and default behavior) is to place that partition immediately after the EFI partition -- which brings me to that FAT32 partition.  It's the EFI/System partition, and it contains the Windows bootloader that turns around and loads Windows from the OS partition.  Basically, UEFI works completely differently from Legacy BIOS.  On Legacy BIOS systems, your BIOS had a boot order that consisted of devices (hard drives, CD/DVD drives, NICs, etc.), and when the BIOS attempted to boot from a specified hard drive, it would read the Master Boot Record that contained the partition map to find a partition marked as "active", i.e. bootable.  That partition would in turn have a boot sector, which was allowed to contain executable code, and that's what allowed the system to load the OS.  UEFI does not work like that when booting from hard drives and flash drives, because the GPT disk layout does not have this concept of "active" partitions or a partition boot sector containing executable code.  Instead, UEFI's boot list consists of specific bootloader files on specific partitions of specific devices.  That however means that the UEFI firmware must be able to actually read the file system where the bootloader files are stored.  But the UEFI spec only mandates support for FAT and FAT32; NTFS support is optional, and relatively uncommon.  Consequently, the bootloader files need to be stored on a FAT32 partition, which then knows how to interpret the NTFS file system where Windows is located.  Incidentally, I consider not mandating support for NTFS to be a massive annoyance of UEFI, because FAT32 doesn't support files larger than 4GB, so if you want to boot a Windows installation environment in UEFI mode (which is necessary if you want the Windows installation you're performing to set itself up in UEFI mode), then the Windows image file you're working with can't be larger than 4GB.  Windows 10 is already pushing that limit today, even before accounting for situations where users want to build custom images with additional applications and such, and although there are workarounds to this quandary (one of which I've implemented), none are particularly convenient, especially for users know enough to perform a clean install but not too much more.

For that partition at the end of the Kids disk, based on its size and amount of space used, it's a safe bet that it is indeed the Windows Recovery partition.  Default Windows installations since Vista have created the Recovery partition before the C drive, but there's no reason it can't be placed elsewhere.  Ironically, that layout persists in Windows 10 despite that fact that Microsoft's own guidance published on TechNet specifies that the Recovery partition should be be placed directly after the C drive so that future Windows 10 releases can upsize it as needed by shrinking the C drive, which was never a need with previous versions of Windows.  But with the default layout, the first time this need arises, Windows shrinks your C drive by the full amount required to create a new Recovery partition of the necessary size and then just leaves your old Recovery partition as dead weight at the beginning of the disk, since that capacity is not in a position to be easily reclaimed for other purposes.  Using the layout Microsoft recommends (but doesn't implement in the Windows installer....) avoids that problem, which is why nowadays when I perform a clean install of Windows, I use the diskpart script that Microsoft provides to set up the disk as recommended (Recovery partition immediately after C) in order to avoid that happening.  Other side effects of this Recovery partition resizing specific to Reflect users are covered here.

I don't think it really matters where the SSD's over-provisioning area exists on disk.  I've never used that feature, but if it ends up after the OS partition, it's probably because it shrinks the OS partition by the amount you wish to allocate to over-provisioning.  I admit I'm surprised to see the Recovery partition on the far side of it though, especially with no previous Recovery partition at the beginning of the disk.  But I honestly wouldn't worry about it because it doesn't really matter.

In terms of Recovery partition sizes, Windows will manage that, so don't worry about it.  And don't worry about where they exist on disk later.  You're actually likely to create problems trying to move it, because Windows may lose track of where it is.  And for anyone using Reflect, the Recovery partition is basically unnecessary anyway.  The only exception is for people using BitLocker, since if a Recovery partition exists, then it stores the files necessary to prompt for a BitLocker PIN/password/Recovery Key in order to decrypt the OS partition.

Leave the FAT32 and Unformatted partitions alone.  Windows will manage those as appropriate.  But you may as well back them up.  They're small and although their contents can be manually recreated, it's much easier if they're just included in your image so they can be to be restored automatically.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)
Group: Forum Members
Posts: 4K, Visits: 29K
Nick beat me to it.  If you really want to convert your system from Legacy BIOS to UEFI, first make sure that your system actually supports UEFI, then you can use the MBR2GPT utility in order to achieve that.  You can find documentation about that here.  It is NOT as simple as the "convert gpt" command in diskpart when dealing with disks that contain an OS.  But basically, you'd run that tool, and if it says your disk layout allows conversion (sometimes it won't), then you tell it to do so, and then you have to reboot into your BIOS and enable UEFI booting, because your Windows installation won't boot again until you do so.

Hopefully needless to say, but make sure you have a good backup before you attempt this.  And if MBR2GPT says that your disk isn't correctly laid out at the moment, you can perform a customized Reflect restore to achieve the same end result (guide here), although it's a bit more work and frankly I'm not sure it's worth the effort.  UEFI can often boot a bit faster and it allows Secure Boot to be enabled, but that's often not enough to justify the hassle for people

Edited 28 February 2018 8:59 PM by jphughan
c3k
c3k
Junior Member
Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)
Group: Forum Members
Posts: 50, Visits: 125
jphughan - 28 February 2018 8:49 PM
You rang? BigGrin

Short answer:
KenII is set up for UEFI booting and Kids is set up for Legacy BIOS booting, and those are the appropriate partitions for each case.  The "None" you see pertains to the drive letter assigned (note that the corresponding location on your OS partition shows "C:" there), and it's normal for those partitions not to have a drive letter assigned.

Long answer (settle in!):
UEFI calls for using the GPT disk partition layout (note it's called a "GPT Disk") and by default uses those partitions in that layout by default, whereas the older Legacy BIOS mechanism calls for an MBR disk partition layout (as you'll notice) and by default uses the partitions you see there, although not normally in that order (more on that later).  If you're curious why the UEFI setup has 2 extra partitions, the Unformatted Primary partition is called the MSR partition (Microsoft Reserved) and stores partition layout information for GPT disks.  On GPT disks NOT used to store an OS, that's normally a 128MB partition that exists at the beginning of the disk, but Microsoft's recommendation (and default behavior) is to place that partition immediately after the EFI partition -- which brings me to that FAT32 partition.  It's the EFI/System partition, and it contains the Windows bootloader that turns around and loads Windows from the OS partition.  Basically, UEFI works completely differently from Legacy BIOS.  On Legacy BIOS systems, your BIOS had a boot order that consisted of devices (hard drives, CD/DVD drives, NICs, etc.), and when the BIOS attempted to boot from a specified hard drive, it would read the Master Boot Record that contained the partition map to find a partition marked as "active", i.e. bootable.  That partition would in turn have a boot sector, which was allowed to contain executable code, and that's what allowed the system to load the OS.  UEFI does not work like that when booting from hard drives and flash drives, because the GPT disk layout does not have this concept of "active" partitions or a partition boot sector containing executable code.  Instead, UEFI's boot list consists of specific bootloader files on specific partitions of specific devices.  That however means that the UEFI firmware must be able to actually read the file system where the bootloader files are stored.  But the UEFI spec only mandates support for FAT and FAT32; NTFS support is optional, and relatively uncommon.  Consequently, the bootloader files need to be stored on a FAT32 partition, which then knows how to interpret the NTFS file system where Windows is located.  Incidentally, I consider not mandating support for NTFS to be a massive annoyance of UEFI, because FAT32 doesn't support files larger than 4GB, so if you want to boot a Windows installation environment in UEFI mode (which is necessary if you want the Windows installation you're performing to set itself up in UEFI mode), then the Windows image file you're working with can't be larger than 4GB.  Windows 10 is already pushing that limit today, even before accounting for situations where users want to build custom images with additional applications and such, and although there are workarounds to this quandary (one of which I've implemented), none are particularly convenient, especially for users know enough to perform a clean install but not too much more.

For that partition at the end of the Kids disk, based on its size and amount of space used, it's a safe bet that it is indeed the Windows Recovery partition.  Default Windows installations since Vista have created the Recovery partition before the C drive, but there's no reason it can't be placed elsewhere.  Ironically, that layout persists in Windows 10 despite that fact that Microsoft's own guidance published on TechNet specifies that the Recovery partition should be be placed directly after the C drive so that future Windows 10 releases can upsize it as needed by shrinking the C drive, which was never a need with previous versions of Windows.  But with the default layout, the first time this need arises, Windows shrinks your C drive by the full amount required to create a new Recovery partition of the necessary size and then just leaves your old Recovery partition as dead weight at the beginning of the disk, since that capacity is not in a position to be easily reclaimed for other purposes.  Using the layout Microsoft recommends (but doesn't implement in the Windows installer....) avoids that problem, which is why nowadays when I perform a clean install of Windows, I use the diskpart script that Microsoft provides to set up the disk as recommended (Recovery partition immediately after C) in order to avoid that happening.  Other side effects of this Recovery partition resizing specific to Reflect users are covered here.

I don't think it really matters where the SSD's over-provisioning area exists on disk.  I've never used that feature, but if it ends up after the OS partition, it's probably because it shrinks the OS partition by the amount you wish to allocate to over-provisioning.  I admit I'm surprised to see the Recovery partition on the far side of it though, especially with no previous Recovery partition at the beginning of the disk.  But I honestly wouldn't worry about it because it doesn't really matter.

In terms of Recovery partition sizes, Windows will manage that, so don't worry about it.  And don't worry about where they exist on disk later.  You're actually likely to create problems trying to move it, because Windows may lose track of where it is.  And for anyone using Reflect, the Recovery partition is basically unnecessary anyway.  The only exception is for people using BitLocker, since if a Recovery partition exists, then it stores the files necessary to prompt for a BitLocker PIN/password/Recovery Key in order to decrypt the OS partition.

Leave the FAT32 and Unformatted partitions alone.  Windows will manage those as appropriate.  But you may as well back them up.  They're small and although their contents can be manually recreated, it's much easier if they're just included in your image so they can be to be restored automatically.

Hmm, I was looking for more of an in-depth answer. Wink
Thanks for taking the time and effort to explain all that. I is much clearer now. Whereas there is evidently no need to change from an MBR to a GPT (especially/specifically) for a drive of that size, I think I'll give it a shot, anyway.

Regards,
Ke​​​​​
c3k
c3k
Junior Member
Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)
Group: Forum Members
Posts: 50, Visits: 125
Okay...remember that "fun" part? Sigh.
@Nick and @jphughan  sorry to be a pest.
I looked at the MBR2GPT utility found in the Win10 systems file. A bit of reading, a youtube video, and I became an expert. Wink
I shutdown my machine after having assimilated all knowledge. Then, I disconnected all drives except my C drive.
​I booted into the Macrium Rescue environment, selected the WinPE command window, copied mbr2gpt from my c drive to the x drive (the rescue disk).​
Next, I just tried to /validate my disk. I got a "failed to retrieve geometry" error. I shutdown, reattached all drives, rebooted normally.

Hmm, I'd better run another backup before I do anything else. Since I'd run a full backup this morning, I selected my backup xml file, run now, differential.
This is what I got:

Edited to remove a picture.​

Sorry for the size, but I wanted to show it all. Down there, in red, at the bottom? That MFT error. Pshaw. What's a "Master File Table" and does anyone use such a thing anymore?  Wink

Ouch, right?

As stated there, I opened an elevated command prompt, entered the chkdsk parameters, rebooted (as needed), and in a VERY short time was told there was no errors and was back at my desktop. For grins, I ran an "sfc /scannow" and there were no integrity violations.​

The second time I ran the Macrium backup, I got the ​​same error, hence my post.

I think I'll forego any mbr to gpt conversions and focus on fixing this new error. The machine seems to work fine...but red ink is scary. Very scary.

As you can see, I have a full backup from this morning. I'm thinking the best bet would be to restore from there. Would that overwrite my MFT? (The earlier backups are not valid for this drive.)

Sorry for the pestering, but this new nvme drive is fun.​

Ken​​​​​​​​​​​​​​​​​​​

UPDATE: the SECOND chkdsk c: /r (and reboot) resulted in a much longer delay before booting. In fact, it held at 15% for so long I thought it was stuck. Then it zoomed to 100%, booted, and now Macrium works without an MFT error. So...all fixed. Until the next time I delve into the OS drive. Smile Thanks guys​​
Edited 1 March 2018 10:50 AM by c3k
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)
Group: Forum Members
Posts: 4K, Visits: 29K
The likely reason MBR2GPT failed when you tried to use it with your Rescue Media is that the newest version of WinPE that Reflect supports is WinPE 10 1607, and MBR2GPT was introduced in Windows 10 1703, so it may require at least WinPE 10 1703.  However, you can it within full Windows if you add the "/allowFullOS" switch.  Did all your reading and YouTubing not mention that? It was in the link I provided in my earlier post. Wink

But to answer your other question, yes a full restore would definitely overwrite your MFT.  Also, if you need to include a log, it's generally easier to right-click the white space, click "Select All", then copy/paste it as text here.  Make sure to remove your license key from the bottom though.  With the screenshot you embedded, the red text at the bottom was cropped from the default zoomed view, and the regular thumbnail in the post was way too small to be read that way.

Edited 1 March 2018 2:52 AM by jphughan
c3k
c3k
Junior Member
Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)Junior Member (73 reputation)
Group: Forum Members
Posts: 50, Visits: 125
jphughan - 1 March 2018 2:50 AM
The likely reason MBR2GPT failed when you tried to use it with your Rescue Media is that the newest version of WinPE that Reflect supports is WinPE 10 1607, and MBR2GPT was introduced in Windows 10 1703, so it may require at least WinPE 10 1703.  However, you can it within full Windows if you add the "/allowFullOS" switch.  Did all your reading and YouTubing not mention that? It was in the link I provided in my earlier post. Wink
​​​
But to answer your other question, yes a full restore would definitely overwrite your MFT.  Also, if you need to include a log, it's generally easier to right-click the white space, click "Select All", then copy/paste it as text here.  Make sure to remove your license key from the bottom though.  With the screenshot you embedded, the red text at the bottom was cropped from the default zoomed view, and the regular thumbnail in the post was way too small to be read that way.

Lol... Yes, my instant internet expert status did confer the knowledge that I could run mbr2gpt in windows with the /allowfullOS switch. I was hesitant to do that. (I thought it could be analogous to trying to flash a BIOS from a Windows utility. Lots of horror stories from that.) In the event, that's what I did.  I ran mbr2gpt from windows and am now the proud owner of a GPT nvme OS drive.

As to your second point; egg on my face. I'm off to delete the image, since it may be possible to pull a key from it. Rookie move...​​

Thanks again!​​

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)Macrium Evangelist (5.9K reputation)
Group: Forum Members
Posts: 4K, Visits: 29K
Congrats! Smile By the way, expect that your next backup of that system will be a Full since you just changed your disk layout, which means you can’t create an Inc/Diff from any backups that were captured while your disk was using the old layout.
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search