Post install Grub on separate partition

So when he made Debian boot first, he had both Debian and Windows options.

So does Mike with his Ubuntu, if I understand it, correctly.

Mike, can you clarify for us:

When you go into BIOS Setup to boot Windows or Ubuntu, are both options listed in the same boot order tab, or do you have to switch between UEFI and MBR mode and back again to see and pick one over the other.

Can you take a picture of the boot order choices and post it here?

Thanks

Wizard.
 


So does Mike with his Ubuntu, if I understand it, correctly.
Oops, maybe I am confused then. If so, it won't be the first time! o_O:)

My understanding is that Mike wants Ubuntu to boot first (which I think he is able to do with BIOS boot order settings). But he wants GRUB to allow a Windows boot also, which GRUB has so far failed to provide. Mike forced GRUB to be visible and installed GRUB Customizer (post #26), but it also failed to detect Windows. Thus the BIOS Boot Menu has been the only method to select which OS to start.
 
Hi guys,

My understanding is that Mike wants Ubuntu to boot first (which I think he is able to do with BIOS boot order settings). But he wants GRUB to allow a Windows boot also, which GRUB has so far failed to provide. Mike forced GRUB to be visible and installed GRUB Customizer (post #26), but it also failed to detect Windows. Thus the BIOS Boot Menu has been the only method to select which OS to start.
@stan that is correct :).

When you go into BIOS Setup to boot Windows or Ubuntu, are both options listed in the same boot order tab, or do you have to switch between UEFI and MBR mode and back again to see and pick one over the other.
@wizardfromoz No, there is an option which lets you have both at the same time UEFI and Legacy OPROM, but to give you a better overview of my UEFI bios settings I have listed below some images I have taken.

1. My boot order of all the devices - I changed the boot order from the 970 to 860 device (Ubuntu)
01.jpg


2. Boot device control setup
02.jpg


Based on the 2nd picture, when I switched the option of the Boot Device Control to UEFI only, my first nvme disc got not recognized anymore, but Ubuntu booted without showing any entry of Windows (sounds logic). After that, I switched it back to UEFI and Legacy OPROM but the 1st drive got still not detected. That is why I had to enable all the SATA ports because I believe that the nvme support got disabled when I switched to UEFI mode. Nevertheless, It still got not detected and I had to choose the drive from the boot menu manually the first time (I don't know what ASUS was thinking of that).

3. SATA port configuration
03.jpg


BTW I have the ASUS DELUXE 2 X99 board, but the logo at start time takes more than a minute before it disappears and boots either Ubuntu or Windows (based on the UEFI bios settings). That is not the quality of ASUS.
 
Last edited:
Asus has a pretty expansive UEFI/BIOS setup utility, much more that I am used to seeing with my old junk. :eek::)

In your Boot section, to start Windows... you probably need "Launch CSM" to be enabled as well as the Legacy option shown with UEFI. This seems a bit redundant as CSM and Legacy are basically the same thing. But one or both of these allow your Windows to boot on the "msdos" partition instead of GPT. If you choose to do the MBR-to-GPT conversion, you may be able to leave these settings alone, or you could try to change one or both of them to be UEFI only after the conversion.

Keep in mind that if you do the MBR-to-GPT conversion, GRUB may still fail to detect Windows to achieve your goal. Changing one or both of those Boot settings might help GRUB (and sudo update-grub) to work, but we can't predict for sure that it will. There may be other things that are the real problem, while we have been chasing GRUB as the culprit.

The problem may be with the difference(s) between the NVMe and SSD drives. If the MBR-to-GPT conversion (and Boot section tweaks) still fail to make GRUB detect Windows, it may work to switch the drives: putting Ubuntu on the NVMe and Windows on the SSD. That is a lot of effort, and it is only another guess. It may still fail to do what you want.

Another guess... if you do the MBR-to-GPT conversion, both drives will have their own independent ESP (EFI System Partition) where each of their bootloaders is stored. You wanted to keep them independent, I know. But, you may could follow Wizard's directions in post #30 and instead put the Ubuntu bootloader on the same drive as Windows. This is actually how dual-boot setups are done on a single drive, but you would lose some of that "independence" and it could give you trouble later if you decide to make changes again. (Not as much trouble as you're having now, probably!) With the bootloaders physically stored on the same drive (and everything UEFI compliant), I would hope that sudo update-grub from Ubuntu would finally see Windows. But I can't promise that. If it does work, the question then is if your BIOS Boot section can tell them apart on the same drive, so that you could make Ubuntu the first in the boot order. But if BIOS can't do it, there is another way to make GRUB first. Warning: this is a scenario where a Windows Update may someday break this configuration. It can be restored again, but it will be good to remember how to make GRUB first in case you have to do this again.

Similar to the above... instead of putting the Ubuntu 18.04 GRUB bootloader on the Windows drive (after a conversion), you could do a fresh install of Ubuntu 20.04 and during the installation tell it to install the GRUB bootloader on the Windows drive. I don't know if you're ready to use 20.04 yet, or not.

GRUB is a very capable bootloader and can easily boot older MBR and newer GPT both... usually. The trouble here is still confusing. Wizard boots 30-40 (or more) distros on a single computer, on a single hard drive I think, so he knows GRUB way better than I ever will. Ah, but I don't think he has Windows on there! :oops::D

Before you decide, let Wizard chime in on these suggestions, and maybe he can offer other alternatives. It's beer time here! o_O:)
 
Last edited:
:) I agree with all you have said @stan

No Windozer on this rig, but Elaine's computer in the study has Win 10 and a Linux Mint 19.0 'Tara' Cinnamon on it.
 
Good evening guys,

Similar to the above... instead of putting the Ubuntu 18.04 GRUB bootloader on the Windows drive (after a conversion), you could do a fresh install of Ubuntu 20.04 and during the installation tell it to install the GRUB bootloader on the Windows drive. I don't know if you're ready to use 20.04 yet, or not.
At present, I do not want to upgrade to 12.04. because there are some problems with the CUDA drivers which I need. Maybe in the middle of the next year, I will do that :).

But, you may could follow Wizard's directions in post #30 and instead put the Ubuntu bootloader on the same drive as Windows. This is actually how dual-boot setups are done on a single drive, but you would lose some of that "independence" and it could give you trouble later if you decide to make changes again. (Not as much trouble as you're having now, probably!) With the bootloaders physically stored on the same drive (and everything UEFI compliant), I would hope that sudo update-grub from Ubuntu would finally see Windows. But I can't promise that. If it does work, the question then is if your BIOS Boot section can tell them apart on the same drive, so that you could make Ubuntu the first in the boot order. But if BIOS can't do it, there is another way to make GRUB first. Warning: this is a scenario where a Windows Update may someday break this configuration. It can be restored again, but it will be good to remember how to make GRUB first in case you have to do this again.
@stan @wizardfromoz: I believe this solution from @wizardfromoz of installing the Grub bootloader after converting the windows 10 partition to gpt is the best to try at present. But I would like to ask you some questions:

1. What as you said if I need to do a reinstallation of Windows 10 or an update, how can I fix the broken loader again?

2. What if I want to partition or change the nvme drive in future, will I be able by switching the discs (like now) in the bios to boot Ubuntu?. In my opinion, this would be like I didn't install any bootloader so I believe that Ubuntu partition would be recognized by the bios as only one drive like it is now. Or am I wrong?
 
1. What as you said if I need to do a reinstallation of Windows 10 or an update, how can I fix the broken loader again?
It is pretty simple really, using "bcdedit" in the Windows command prompt (run as Administrator). A quick Google should always find something like this article to help. This uses Ubuntu as an example, so it should work perfectly as is. If you switch to a different Linux, it may need some tweaking to the path, but many Ubuntu derivatives also use \EFI\ubuntu\. I think Debian would use \EFI\debian\ .... you get the idea.


2. What if I want to partition or change the nvme drive in future, will I be able by switching the discs (like now) in the bios to boot Ubuntu?. In my opinion, this would be like I didn't install any bootloader so I believe that Ubuntu partition would be recognized by the bios as only one drive like it is now. Or am I wrong?
Partitioning the nvme would be okay as long as you don't change the boot partition. If you reformat that drive, or remove it, or change the boot partition... you will probably need an Ubuntu Live USB to boot on in order to restore GRUB (to whatever new location will be needed). Again, Google will find many articles to help with this, such as this one. The graphical "Boot Repair" option in that article may not always work. You might would try it, but I usually go straight for command line fixes myself. The command line method is very similar to Wizard's method in post #30.

Things change, and over time these fixes may need tweaking. Whenever you Google for info on how to do something, or how to fix something, try to find the most recent articles that you can. A lot of old and outdated information stays on the internet forever. One of the articles I linked to is already 3 years old, but it looks okay right now. (Famous last words. :))

Continuing to use the BIOS Boot Menu isn't really a bad method either though, especially if you mostly just use one of systems. Set that one to be your first in the BIOS boot order, and you don't often have to intervene to change it.
 
Last edited:
Hi guys, @stan Yes, you're right when I encounter in the future one of the problems then I will try to find the most recent solution to the problem (to be honest I do it for every problem I have).

Continuing to use the BIOS Boot Menu isn't really a bad method either though, especially if you mostly just use one of the systems. Set that one to be your first in the BIOS boot order, and you don't often have to intervene to change it.
That wouldn't be tedious if I only used one of the OS a day, but I switch from one to the other every because I do different things on one OS and others on the other :(. Nevertheless, I will try soon the conversion from mbr to the gpt solution of windows 10 and we will see if that fixed the issue (wish me luck).
 
That wouldn't be tedious if I only used one of the OS a day, but I switch from one to the other every because I do different things on one OS and others on the other :(. Nevertheless, I will try soon the conversion from mbr to the gpt solution of windows 10 and we will see if that fixed the issue (wish me luck).
Well, you have to reboot to switch them every time! That is your biggest delay by itself. But GRUB should work, regardless. It would be a little faster than using the BIOS Boot Menu, but only for half of your reboots... when you need to switch to the non-default OS. When rebooting to the default OS, then GRUB doesn't save you anything. I hope that with the MBR-to-GPT conversion that you will find success. I very much do wish you good luck! :)

Have you ever considered using a Virtual Machine instead? With a VM, you could have BOTH Ubuntu and Windows running at the same time... no more rebooting to switch systems, and no bootloader issues or problems. There are trade-offs, of course, and a VM may not suit your needs with CUDA or for other reasons. It's just a thought.

Again, good luck!
 
Have you ever considered using a Virtual Machine instead? With a VM, you could have BOTH Ubuntu and Windows running at the same time... no more rebooting to switch systems, and no bootloader issues or problems. There are trade-offs, of course, and a VM may not suit your needs with CUDA or for other reasons. It's just a thought.
That's a good thought, Stan. As a bonus, Virtualbox includes support for integrating the VM's windows into your host's desktop.

If Mike decides to follow the VM route, I'd suggest using one hard drive fire the host and the other solely for the VM.
 
Hi guys, I had running on windows the virtual box VM but I am not a fan if you need hardware access or performance the VM slows down. BTW how is it possible that grub does not detect the windows partition at startup but Ubuntu does as shown in the following screenshot:

Ubuntu Files explorer
Selection_002.png
 
if you need hardware access or performance the VM slows down.
Yes, this is often true. It may help to give the VM more RAM, but I did say it may not suit your needs. I like VirtualBox to test new distros, and some of them I keep and use as a "sandbox" to be isolated from the host. It works pretty well for me.


BTW how is it possible that grub does not detect the windows partition at startup but Ubuntu does as shown in the following screenshot:
Hmmm, I may describe this poorly, sorry. Your "msdos" partition table configuration starts its boot process from the MBR (Master Boot Record). This is very old school. The MBR is restricted and invisible to most things, like a file manager... but GRUB should see it and use it. In your case, it doesn't, and it fails to boot Windows. UEFI is done differently, and you can see the boot partition, a real partition, usually (maybe always) FAT32, even on Linux, and usually about 250-500 MB in size. Converting your Windows to GPT will create a UEFI boot partition, but it being "visible" is not what will help GRUB. It is more a hope that it will work when both drives are configured as normal UEFI, a hope that some unknown conflict might be resolved. If the problem is NVMe versus SSD, then the conversion to GPT may not help GRUB. For a much better explanation of the BIOS/MBR boot process, please take a look at this article.

What your screenshot shows us is Ubuntu (not GRUB) looking at your Windows partition (not MBR). These are different things. But it brings up something you should know, if you don't already. If you want to mount your Windows drive from Linux and read/write files there, you may get errors about "filesystem in use" (or similar). The cause of this is that if you tell Windows 10 to "shutdown"... it doesn't. It goes into hibernation instead, meaning that Windows is still running. Linux senses that and is trying to prevent damage to Windows by refusing to use it in that state. If you "restart" Windows instead of "shutdown," you will be okay because Windows doesn't hibernate on a restart (thinking you will restart Windows). You can permanently disable hibernation if you find this to be a problem.

Going the other way, Windows will not normally be able to access your EXT4 Linux partition or be able to read/write files at all, yet things are changing. There may be some third party Windows tools that will work, but I don't have a need for that so I don't know what's current. I see on the web that WSL2 (Windows Subsystem for Linux) will let you mount EXT4, but again, I don't need or use anything like that. I very rarely ever boot Windows at all, actually. The less, the better. :cool:
 
If Mike decides to follow the VM route, I'd suggest using one hard drive fire the host and the other solely for the VM.
That scares me... we'll be back where we started, but in a VM! LOL :eek:o_O:D
 
On VMs, this from Mike's inxi -Fxz output

Code:
Memory: 1743.9/32024.0MB

That's 32 GB RAM.

Mike a Virtual Machine such as VirtualBox will allow you to allocate somewhere between 75% and 85% of the computer's memory to the Guest VM.

Of course, once the VM is closed, that RAM is redeemed for the Host.

If you have your Host and your Guest set up to share files (drag and drop, &c), then all you need is to have sufficient performance left in terms of RAM to keep running your Host.

Windows is a bigger memory hog than Linux, so in an example you could allocate 24 GB of RAM to running Windows under the VM as a Guest, with Ubuntu as a Host still having 8 GB to function.

I would probably split it 50 - 50, that is 16 GB to each.

Wiz
 
Good evening folks :),

I installed Ubuntu on the second drive because I didn't want to use any VM (like I did in Windows). Despite using a VM in Linux does not let someone access the GPU and generally limits the access to the hardware which I need to accomplish machine learning and computer vision tasks. Because of that VM is not a solution for me. I will try maybe in the weekend to convert windows to gpt and then we will see.
Nevertheless, I have opened another thread in the video section because I have also an issue with the resolution of my two monitors. Maybe you can also look after :). THX.
 
I have opened another thread in the video section because I have also an issue with the resolution of my two monitors. Maybe you can also look after :).
I've never used two monitors before, so I won't be any help with that. :(

But I will be watching for your report on the MBR-to-GPT conversion. I didn't even know that was possible until this thread, so I'm very interested in the outcome. Be sure to make a good backup! :)
 
I've never used two monitors before,

I have but not for a couple of years.

Brian has, so I'll flag him over there if he has not already seen it.

But I will be watching for your report on the MBR-to-GPT conversion

Ditto. Will be interested in how it goes.

Keep the faith, Mike :) - you have done very well with a very curly (difficult) problem, and at the very least are learning a lot.

Wizard
 
Brian has, so I'll flag him over there if he has not already seen it.
Thank you very much @wizardfromoz I appreciate that :).

But I will be watching for your report on the MBR-to-GPT conversion. I didn't even know that was possible until this thread, so I'm very interested in the outcome. Be sure to make a good backup! :)
Nice to read @stan, @wizardfromoz that you will look after when I did the gpt conversion. I hope that will fix my problem.

Keep the faith, Mike :) - you have done very well with a very curly (difficult) problem, and at the very least are learning a lot.
THX @wizardfromoz for your encouragement :).

I will do a report as soon as I have results, I'll promise :).
 
Hi guys, a long time ago. I Hope you are doing fine :cool:

Today I tried to work on the tutorial suggested by @LorenDB at #post 44, but this solution didn't work for me. After executing the mbr2gpt /convert command I got the following error:

ERROR
04.jpg


After I changed in the bios the boot option to UEFI only the system did not boot anymore, so I switched it back again. In the disk management of windows I didn't see any changes for the windows partition C after executing the command.

Disk Management
Capture.JPG


I don't know why this error happens but this shows me that you cannot trust microsoft.
 

Members online


Latest posts

Top