Several GPT partitions on internal SATA HDD spinner not showing up in "This PC"


Several GPT partitions on internal SATA HDD spinner not showing up in...
Author
Message
DSperber
DSperber
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 6, Visits: 37
Very strange.

Using WinPE 10 rescue media with latest 7.1.2801 Macrium Reflect on it, on a machine with four internal SATA hard drives, all HDD spinners.  Three (including the boot drive) are 2TB or smaller and partitioned with MBR.  The fourth is 6TB, is partitioned with GPT, and contains three "data" partitions following the special GPT placeholder 128MB partition:

(1) other - GPT placeholder 128MB
(2)  I - 6GB NTFS
(3)  F - 39GB NTFS
(4)  H - 5.5TB NTFS

When booted to the rescue media only partition I on this 6TB drive shows up under "This PC" when clicking on the "browse for an image file..." link.  The other two partitions F and H do not appear.  All other partitions on the three other internal MBR drives show up just fine.

Curiously, I discovered this while trying to help a user on a Lenovo Thinkpad forum site, who is using Macrium Reflect Free.  His Thinkpad P71 laptop is running Win10 and has two internal drives, one a 256GB M.2 NVMe SSD which is the system boot drive, and the other a 1TB SATA HDD spinner for "data" which I believe contains just one partition.  I am guessing the drive was partitioned using GPT (but I'm waiting to confirm that).

Anyway, his Macrium Reflect system image backups are being written to the 1TB HDD spinner.  When booting to the WinPE 10 rescue media he created the SATA HDD spinner partition is not showing up in "This PC".  So he can't select an image backup to restore.

This is essentially identical to my own situation, except that I cannot see two of the three GPT partitions on my 6TB drive.  He can't see what is probably the only GPT partition on his 1TB drive.  And both of these stories involve WinPE 10 and the latest version of Macrium Reflect.

Any thoughts?  Anything about my (or his) situation you'd like to know more about?  Any pictures or diagnostic info you'd like me to gather?

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
Does the Reflect interface that shows all of your disks show the 6TB disk’s partition map accurately? If so, it sounds like these partitions might simply not have drive letters assigned. I remember seeing the same thing when I first started using Reflect under 6.3.xxxx — a 3TB drive didn’t get a drive letter assigned in my WinPE 10 Rescue Media. I just opened Command Prompt from the taskbar and used the diskpart utility to assign a letter, and then it showed up under This PC. To try that, in Command Prompt enter the following:
Diskpart
List disk
Select disk X (substitute the correct number based on the output of list disk)
List partition
Select partition X (same substitution)
Assign

Does that work? If so, I don’t know why a drive letter wouldn’t have been assigned automatically if these are just regular data partitions, and in my case I was never able to reproduce this behavior after that one case, so I didn’t pursue it.
Edited 2 January 2018 3:39 PM by jphughan
DSperber
DSperber
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 6, Visits: 37
Well, truly remarkable.  You are a gentleman and a scholar.

Sure enough, using the recipe you provided for using Command Prompt from the taskbar within WinPE running from rescue media (actually, to be honest I was running WinPE from "Macrium Reflect Recovery" off of Boot Manager menu and hard drive as it loads much faster) I was able to assign letters F and H to those two partitions.  And then when I re-opened "This PC" sure enough now those previously missing partitions were present.

I then closed the program and re-booted once more, because I was curious to know if I would have to repeat this process every time I booted to the rescue media.  Astonishingly, now the previously invisible partitions F and H were now visible, same as all the other partitions which had always been visible!  As if something had been updated physically and permanently in the disk's Partition Table by the ASSIGN done earlier through the DISKPART technique.  Remarkable.

So I guess I won't have to do this every time I need to use rescue media.  Looks like whatever was initially responsible for the two missing partitions has been permanently corrected and repaired on the disk itself.  No more invisible partitions.  You live and you learn, I guess.

Can't thank you enough for this insight.

I will now provide this same suggested recipe for success to that user over on the Lenovo Thinkpad Forum. He did respond that the 1TB SATA HDD spinner (a) was partitioned GPT as I suspected it would be, and (b) does in fact only have one large partition allocated to the entire drive, following the standard 128MB GPT placeholder partition at the front.  Based on my own success I imagine his D-partition on the HDD spinner will also spring to life for WinPE and Macrium Reflect.  I'll be back here if it fails, but I'm guessing it will work.

Thank you again.

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
You’re welcome! And it sounds like you’ve had the same experience I did. I had to assign it once, and never again, even though the assign command doesn’t make permanent changes to the partition that received the drive letter or the WinPE environment that’s actually read-only anyway. I can’t account for the behavior, but I’m glad I discovered it rather than the non-tech people I set up Reflect for, because they definitely would not have known how to assign a drive letter to access their backups!
Edited 30 December 2017 8:21 PM by jphughan
DSperber
DSperber
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 6, Visits: 37
Turns out this DISKPART/ASSIGN workaround worked successfully for the other guy on the Lenovo Forum.  He was able to see the invisible partition and assign drive letter D to it, and then it did show up in "This PC".  So in that sense he had success in resolving his problem.

However not really surprisingly to be honest, his situation was NOT permanent.  After re-booting the partition was once again invisible, and he had to repeat the DISKPART/ASSIGN trick. This of course makes sense since the DISKPART/ASSIGN is a read-only temporary gimmick during the lifetime of WinPE and Macrium Reflect, and really shouldn't be accomplishing anything permanently.  But he's still satisfied he at least has a way to see his backup image folder on the HDD spinner even if he has to do it each time he runs from rescue media.

And of course that really does leave our own mysterious results, which is why/how performing the identical sequence of theoretically read-only steps on our system the results WERE seemingly permanent.

Now the real mystery (to hopefully be answered by Macrium in response to the support ticket I opened yesterday) is why this is happening at all!!  Why are any of these GPT partitions actually not showing up initially in WinPE version of Macrium Reflect?  What makes these invisible partitions unique from at least one other GPT partition on the very same drive which is visible??  I don't know if Macrium is aware of this symptom before now, reported by other users?  We'll find out.



jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
Interesting about the Lenovo forum guy. As you say, that normally WOULDN’T be interesting since that’s what you’d expect, but in this case it’s different from our observed behavior. And yes the fact that it’s happening at all even though drive letters are assigned properly in real Windows is strange.

In fairness, this may be a WinPE issue rather than a Reflect issue, unless maybe.... @Nick is it possible that the Rescue environment's mechanism that tries to carry over drive letter assignments from "real" Windows into Rescue could be causing this?  Perhaps when using Rescue Media made on one PC to boot another PC?  Or might Reflect ever try to assign a letter that WinPE has already allocated to another volume and fail, leaving that volume with no letter at all?  Or would it ever try to change the letter of a volume that already received a "default" letter from WinPE, in which case it might occasionally end up removing the originally assigned letter and somehow failing to assign the replacement letter?

Edited 31 December 2017 5:43 AM by jphughan
Nick
Nick
Macrium Representative
Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)Macrium Representative (2.6K reputation)
Group: Administrators
Posts: 1.5K, Visits: 8.3K

@Nick is it possible that the Rescue environment's mechanism that tries to carry over drive letter assignments from "real" Windows into Rescue could be causing this?


We'll take a look and report back. 

Kind Regards

Nick - Macrium Support

DSperber
DSperber
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 6, Visits: 37
Nick - 2 January 2018 3:36 PM

@Nick is it possible that the Rescue environment's mechanism that tries to carry over drive letter assignments from "real" Windows into Rescue could be causing this?


We'll take a look and report back. 

I just replied on my Macrium Support Ticket #14151, so there's additional detail in that email.

I'm still puzzled as to why for both of use here the effect of the diskpart trick was "permanent" even though it really should have only been "temporary" within that WinPE session if there was something on the GPT disk itself which was causing the invisibility of partitions (F and H in my case, even though I was visible).  And in contrast, for the user on the Lenovo Thinkpad laptop forum the change was always only "temporary", as you'd expect it should have been.

I am running Win7 as my operational Windows, and my desktop machine has three MBR drives all of which are 2TB or smaller (including the Windows system drive) and one 6TB GPT drive (the one with three partitions, I, H and F, where only I was originally visible).  The Lenovo user has a much simpler setup, running win10 with only two drives in his laptop (both partitioned GPT), with only the Windows-C partition on the SSD and the invisible D on the second SATA HDD spinner. 

Regarding your comment regarding the desire/attempt for Rescue Media to carry over the identical partition lettering technique as "real operating Windows" had, I hadn't thought anything about that until you mentioned it.  That certainly is an interesting notion, as in my own case the 12 partition letters are scattered all around non-consecutively across the four drives.  So if creation of the Rescue Media while operating under real Windows also creates some type of partition letter roadmap that gets stored within the Resuce Media itself, then that would suggest the "fault" of missing F and H for me had actually occurred during the creation of the Rescue Media itself.

And it might also suggest that the reason F and H became so-called permanently visible after I used the diskpart trick just once, perhaps that means the Rescue Media session may have actually updated itself (rather than the GPT partition table on disk), to now properly show the two new F and H partitions ever after.  However this speculatoin is contradicted by the fact that while I had run the diskpart recipe while running from the Boot Manager Recovery Option version, making F and H visible there, when I later used the standalone bootable USB WinPE Rescue Media the two F and H partitions were once again still visible, even though they had not been visible much earlier when I booted to the USB version to see if that would make F and H appear.

I suppose I could recreate the bootable USB media, as well as deleting and recreating the Boot Manager version, to see if I can reproduce the original symptom of F and H being invisible, suggesting something got touched in the rescue media itself to make F and H permanently visible ... or if they now are always visible, suggesting something got touched on the GPT disk itself.  I'm going to give this a try.

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
I believe the drive letter mappings are stored in a file that is embedded into the Boot.wim file of the Rescue Media -- so it would be read-only in the Rescue environment.  If you wanted to experiment again though, you would have to not just recreate but fully rebuild your Rescue Media, since that operation builds a new Boot.wim file.  To do that, go through the Create Rescue Media wizard, and when you get to the final step where you specify a target, click the Rebuild button, then click Next, and after that process completes, THEN update your actual USB media.  Also note that this of course means that Rescue Media will only carry over drive letter assignments for the system on which it was built (and the drive letter configuration that existed at the time this rebuild occurred).

Edited 2 January 2018 4:19 PM by jphughan
DSperber
DSperber
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 6, Visits: 37
Will follow your directions, and "rebuild" the rescue environment completely so as to get a fresh Boot.wim.  And for convenience I will only recreate the Boot Manager recovery version, hoping to recreate the original failure using that boot method.

If I can recreate the original failure using Boot Manager, but using my existing standalone bootable USB it still now shows F and H, this would be very informative.  And if I then recreate a brand new standalone bootable USB and it once again fails, then I think we really have evidence that points to the problem originating with the creation of the Rescue Media partition letter table itself (imbedded in Boot.wim as you describe).

I will play with this today.

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