Post install Grub on separate partition

Hi Mike! The mbr2gpt tool was new to me when @LorenDB bought it to light, but your first screenshot shows that it worked, or mostly worked. It says both the validate and conversion were successful. The error is about Windows Recovery Environment (WinRE) and there is some stuff available about that with Google... but I don't know enough about it to make recommendations.

Your Disk Management screenshot also shows you have an EFI partition on Disk 2, Partition 2... and I'm guessing that was not there before. So I'm not sure at all why it would not boot when you switched the BIOS to full UEFI mode. While in full UEFI, did you try to use the BIOS boot menu? For Windows and for Ubuntu?

Have you used GParted (or Windows tool) to confirm that the disk type was, in fact, changed from "msdos" to "gpt"? I would guess that it was changed, from the success reports in your first screenshot.

If @LorenDB's suggestion above does not fix it, I'd probably research the Google articles about reagent.xml and the steps to disable/enable the WinRE manually, as the error describes.

A wild guess... I wonder if your new EFI partition should be Disk 2, Partition 1, instead of Partition 2? I don't know if Windows is sensitive to the EFI placement on the drive, but it is pretty deep behind the large Win 10 C: partition, which I assume to be Partition 1.
 
Last edited:


This also doesn't work @LorenDB . I get this error message and even the validation doesn't work :(.

ERROR MSG
01.jpg


In the first screenshot, there is a message while converting to gpt in #post 79 the operations tried to shrink the OS. Maybe this is the problem. I don't know :rolleyes:

Hi @stan
Have you used GParted (or Windows tool) to confirm that the disk type was, in fact, changed from "msdos" to "gpt"? I would guess that it was changed, from the success reports in your first screenshot.
I have used the disk management utility from windows but the problem is that the conversion has changed something which doesn't let you validate any more. I don't know how to fix that. Yes, you're right why partition 1 and not 2 that was something that I found also strange. Another suspicious thing is why X:\ and not C:\. The windows folder is on the C drive.
 
Last edited:
In the first screenshot, there is a message while converting to gpt in #post 79 the operations tried to shrink the OS. Maybe this is the problem.
No, I don't think so. In the next line after that, it says something like, "Creating the EFI system partition." So it had to first shrink the OS partition to make room for EFI, even though it is quite small. This seems normal, and again, that operation also reported, "Conversion completed successfully." Your error here was related to WinRE.


I have used the disk management utility from windows but the problem is that the conversion has changed something which doesn't let you validate any more. I don't know how to fix that.
Googling a little tells me that the EFI partition is not required to be first on the disk, but it is rather common to see it first anyway. I don't know how to fix this either. Googling also showed some Microsoft tools (DISM and SFC) that may find/fix problems for you... or not. I don't place much trust in Microsoft either.


Another suspicious thing is why X:\ and not C:\. The windows folder is on the C drive.
I don't think this is suspicious either, but I am very rusty with anything Windows. I think (guess) that the X:\ is just a temporary drive assignment, possibly a RAMdisk, used by Windows recovery tools for troubleshooting and possible repairs. Besides a RAMdisk, the X:\ may be temporarily assigned to the Windows Recovery partition instead.

Drive letter assignments in Windows have little meaning anyway. If you have a D:\ drive... is that a second physical hard drive? Or a second partition on the first hard drive? It could be either one!

So, what's next, Mike? Pursue the WinRE error? Check out the DISM and SFC (or other) tools? Check Windows forums for further advice? Maybe the education is worth all the time you are spending. If it were me, I would have already formatted the drive as GPT, enabled UEFI only, and done a fresh install of Windows 10. And then, still... it may not fix your original problem of wanting GRUB to boot first and give you a Windows option. That unknown problem may be something else, maybe related to NVMe, or maybe something else entirely.

Did you run sudo os-prober and/or sudo update-grub from Ubuntu after the conversion? While still in UEFI only mode?
 
https://superuser.com/questions/1377951/cannot-convert-from-mbr-to-gpt says:

The MBR2GPT documentation says that in order to convert the drive to GPT all the following conditions must be met

  • The disk is currently using MBR
  • There is enough space not occupied by partitions to store the primary and secondary GPTs:
    • 16KB + 2 sectors at the front of the disk
    • 16KB + 1 sector at the end of the disk
  • There are at most 3 primary partitions in the MBR partition table
  • One of the partitions is set as active and is the system partition
  • The disk does not have any extended/logical partition
  • The BCD store on the system partition contains a default OS entry pointing to an OS partition
  • The volume IDs can be retrieved for each volume which has a drive letter assigned
  • All partitions on the disk are of MBR types recognized by Windows or has a mapping specified using the /map command-line option
https://docs.microsoft.com/en-us/windows/deployment/mbr-to-gpt

I'd like to look at the line "There is enough space not occupied by partitions to store the primary and secondary GPTs". The second screenshot that @mike_linux posted on #9 shows no free space on the Windows disk. I'd suggest shrinking either one of the two partitions on the disk. The Windows partition would probably be a fine one to do.

I think that your disk meets the rest of the requirements; however, the lack of un-partitioned space could be the snag that you've been hitting.
 
Let me quote more of that from Microsoft (Bold, Italic, and Underline is mine):

Disk Prerequisites

Before any change to the disk is made, MBR2GPT validates the layout and geometry of the selected disk to ensure that:


  • The disk is currently using MBR
  • There is enough space not occupied by partitions to store the primary and secondary GPTs:
    • 16KB + 2 sectors at the front of the disk
    • 16KB + 1 sector at the end of the disk
  • There are at most 3 primary partitions in the MBR partition table
  • One of the partitions is set as active and is the system partition
  • The disk does not have any extended/logical partition
  • The BCD store on the system partition contains a default OS entry pointing to an OS partition
  • The volume IDs can be retrieved for each volume which has a drive letter assigned
  • All partitions on the disk are of MBR types recognized by Windows or has a mapping specified using the /map command-line option

If any of these checks fails, the conversion will not proceed and an error will be returned.

Following the primary and secondary GPT space requirements you are suggesting, Mike would need free space at BOTH ENDS of the drive to begin. I don't think that is correct. My take on this is that the tool worked as it should, shrinking as needed on the fly, and reported the conversion as successful. Otherwise, as it states, if the checks failed, it would not proceed.

But I have been known to be wrong... a lot. (Ask my wife!) ;):D
 
@stan, I see what you're coming from, but I still think it's worth a shot. What could go wrong? (Famous last words)
 
My take on this is that the tool worked as it should, shrinking as needed on the fly, and reported the conversion as successful.
Note that the screenshot in #82 says that layout validation failed.
 
Note that the screenshot in #82 says that layout validation failed.
@LorenDB, I'm definitely open to anything that might help Mike solve this. :)

But his screenshot in #79 says both validation successful and conversion successful. If that report is true, then his disk is now GPT and not MBR, and that would cause the failure in #82.

I'm pretty stumped over the WinRE error, and why (or if) that is the cause that he could not boot Windows in UEFI mode after the conversion.

I routinely and regularly reinstall operating systems on numerous computers. It is often faster and easier (for me) than intense troubleshooting. I would fall back on my "ideal world" scenario in #36 and start over, if it were me, although my scenario might need tweaking along the way. With a bare install of Windows on one drive, and a bare install of Ubuntu on another drive... if sudo update-grub failed to detect Windows... I would reinstall AGAIN and switch the drives so that the NVMe gets the other OS. Before installing both Windows and Ubuntu, both drives would be set at GPT, the BIOS would be set to UEFI only, and Secure Boot would be enabled on both, even Ubuntu unless it fails as it did before for Mike. I have installed Ubuntu with Secure Boot before, so I know that it is possible at least sometimes. But if it has to be disabled for Ubuntu, Windows won't complain about that. I'm kind of hung up on considering NVMe as a possible culprit with this problem, but it may not be at all. It seems that I've seen Linux issues with NVMe before, and with "combo" drives that are part SSD and part HDD.

If, after reinstalling both OS'es TWICE (if needed), it turns out the GRUB will still not detect Windows, then I would finally give up, and just continue to use the BIOS Boot Menu to choose which OS to start up each time. I don't like to admit defeat, but I have to sometimes. :oops:o_O
 

Members online


Latest posts

Top