GRUB2 Minimal BASH-like line editing is supported ...

This sounds quite complex and I don't want to break something else. Can you provide me a tutorial for that please, in case the others have no better idea?
Hold off a bit and see where Chris is leading you. I'm glad to see that lsblk does, in fact, show your NVMe drive after all. And I'm glad to see that you have tidied up your drive partitions with your Windows and Ubuntu upgrades since last year.


I posted the wrong screenshots of gparted from my laptop instead of my PC where the problem is.
So my analysis about your situation is wrong... partly based on incorrect screenshots. It's a good thing you didn't delete any bootloaders with efibootmgr, don't you think? ;)

Your revised gparted screenshots does not show an Ubuntu boot partition (/boot/efi... with the boot,esp flags, as seen on your laptop). So the more likely case now is that the Windows drive is holding your grub bootloader for Ubuntu in its /boot/efi partition, and that is probably as it should be (even though it is not what you wanted). But I'll scratch my head a little more on that... and why you get the grub> error, yet it will boot from BIOS.
 
Last edited:


Your grub is on your Windows drive at /dev/nvme0n1p2 fat32 /boot/efi

So from what I am seeing you had the Windows drive plugged in and then tried to install Ubuntu to the second drive which Ubuntu assumed Dual booting not Dual drives and loaded the grub into Windows which caused your problem.

To fix it -
You will have to unplug all drives except the one you want Ubuntu on you will have to reinstall Ubuntu to that drive with all the other drives unplugged your grub will be on the same drive as Ubuntu - once Ubuntu has been reinstalled reboot and test Ubuntu it should boot up as normal - if it does shut down and unplug the Ubuntu drive and plug in the Windows drive only and see if it boots. If it boots you will have to use Windows Disk Manager and delete the /dev/nvme0n1p2 fat32 /boot/efi and add that space to ntfs Win 10, once completed reboot again to see if it boots normally - if it does then shut down and now you can plug in both drives - if not you will have to rebuild the Windows boot partition first before plugging in both drives

Whenever you use a dual drive system (not to be confused with dual boot system) you should unplug all drives except the the you want to install your OS to - with one drive plugged in install Windows once Windows is installed shut down and unplug that drive and connect the other drive and then install Ubuntu to that other drive - once Ubuntu is installed to the second shut down and plug in both drives - now boot to bios and change the boot order for Ubuntu to boot first - now make sure Ubuntu sees the Windows drive - if Ubuntu sees Windows, which it should, then update the grub which will allow you to select your OS at startup also make sure secure boot and fast boot are turned off
 
Last edited by a moderator:
Hold off a bit and see where Chris is leading you. I'm glad to see that lsblk does, in fact, show your NVMe drive after all. And I'm glad to see that you have tidied up your drive partitions with your Windows and Ubuntu upgrades since last year.



So my analysis about your situation is wrong... partly based on incorrect screenshots. It's a good thing you didn't delete any bootloaders with efibootmgr, don't you think? ;)

Your revised gparted screenshots does not show an Ubuntu boot partition (/boot/efi... with the boot,esp flags, as seen on your laptop). So the more likely case now is that the Windows drive is holding your grub bootloader for Ubuntu in its /boot/efi partition, and that is probably as it should be (even though it is not what you wanted). But I'll scratch my head a little more on that... and why you get the grub> error, yet it will boot from BIOS.
@stan
Windows drive is holding your grub bootloader for Ubuntu in its /boot/efi partition, and that is probably as it should be (even though it is not what you wanted). But I'll scratch my head a little more on that... and why you get the grub> error, yet it will boot from BIOS.
That is right for example the first screenshot shows this /boot/efi partition which is on my Windows 10 hard drive.

Hope scratching your head will bring you the AHA effect, so you can help me further :).
 
Your grub is on your Windows drive at /dev/nvme0n1p2 fat32 /boot/efi

So from what I am seeing you had the Windows drive plugged in and then tried to install Ubuntu to the second drive which Ubuntu assumed Dual booting not Dual drives and loaded the grub into Windows which caused your problem.

To fix it -
You will have to unplug all drives except the one you want Ubuntu on you will have to reinstall Ubuntu to that drive with all the other drives unplugged your grub will be on the same drive as Ubuntu - once Ubuntu has been reinstalled reboot and test Ubuntu it should boot up as normal - if it does shut down and unplug the Ubuntu drive and plug in the Windows drive only and see if it boots. If it boots you will have to use Windows Disk Manager and delete the /dev/nvme0n1p2 fat32 /boot/efi and add that space to ntfs Win 10, once completed reboot again to see if it boots normally - if it does then shut down and now you can plug in both drives - if not you will have to rebuild the Windows boot partition first before plugging in both drives

Whenever you use a dual drive system (not to be confused with dual boot system) you should unplug all drives except the the you want to install your OS to - with one drive plugged in install Windows once Windows is installed shut down and unplug that drive and connect the other drive and then install Ubuntu to that other drive - once Ubuntu is installed to the second shut down and plug in both drives - now boot to bios and change the boot order for Ubuntu to boot first - now make sure Ubuntu sees the Windows drive - if Ubuntu sees Windows, which it should, then update the grub which will allow you to select your OS at startup also make sure secure boot and fast boot are turned off
@Lord Boltar the listing looks very interesting but the process the reinstall all is very tedious for me at present because of work and other things. I will keep this suggestion in mind for the future to unplug the hard drive which get not used and install the OS first.

Whenever you use a dual drive system (not to be confused with dual boot system) you should unplug all drives except the the you want to install your OS to - with one drive plugged in install Windows once Windows is installed shut down and unplug that drive and connect the other drive and then install Ubuntu to that other drive - once Ubuntu is installed to the second shut down and plug in both drives - now boot to bios and change the boot order for Ubuntu to boot first - now make sure Ubuntu sees the Windows drive - if Ubuntu sees Windows, which it should, then update the grub which will allow you to select your OS at startup also make sure secure boot and fast boot are turned off
I totally agree with that, because you will be prevented from a headache while installing multiple OS systems :).
 
Is that what you need?

Yes, but just the G figure at bottom left, that will be the total in gibibytes, it could be 5, 15, 50 or other.

Back soon.
 
You will have to unplug all drives...

Have to totally disagree there, Your Lordship.

I have 70 Linux installed over 3 drives with this laptop setup and running for over 3 years and have not ever had to unplug a drive or go inside the laptop. Further, it shipped with Windows 10 on the /dev/sdb Micron 256 GB SSD, and I had installed maybe 20 - 30 Linux on the /dev/sda 2 TB SATA, as well as some on the /dev/sdb SSD, before I blew Windows away. When Windows was there, the Linux on the SSD shared its ESP, and I always had a separate ESP on the SATA.

Once Mike comes back with that du -ah figure, I can offer an alternative which would likely consist of:
  1. Moving Home to the Data drive, using the link to Dave McKay's article I provided here last March
  2. Using Windows Dis Management to reclaim the Ubuntu space and then create a new space in place of it
  3. Reinstall Ubuntu, using "Other" in Ubiquity, pointing it to the Home on the Data drive
BUT (and you know what they say about Wizard's butt), if Mike's Timeshift snapshot was taken BEFORE the troubles began, AND he has Home included in the snapshot options, Timeshift Restore is easiest solution (without having to move home) and still usable if Home is not included in the snapshot. Only if the snapshot was taken before the troubles.

Have to go for a couple of hours.

Wiz
 
Have to totally disagree there, Your Lordship.

I have 70 Linux installed over 3 drives with this laptop setup and running for over 3 years and have not ever had to unplug a drive or go inside the laptop. Further, it shipped with Windows 10 on the /dev/sdb Micron 256 GB SSD, and I had installed maybe 20 - 30 Linux on the /dev/sda 2 TB SATA, as well as some on the /dev/sdb SSD, before I blew Windows away. When Windows was there, the Linux on the SSD shared its ESP, and I always had a separate ESP on the SATA.

Once Mike comes back with that du -ah figure, I can offer an alternative which would likely consist of:
  1. Moving Home to the Data drive, using the link to Dave McKay's article I provided here last March
  2. Using Windows Dis Management to reclaim the Ubuntu space and then create a new space in place of it
  3. Reinstall Ubuntu, using "Other" in Ubiquity, pointing it to the Home on the Data drive
BUT (and you know what they say about Wizard's butt), if Mike's Timeshift snapshot was taken BEFORE the troubles began, AND he has Home included in the snapshot options, Timeshift Restore is easiest solution (without having to move home) and still usable if Home is not included in the snapshot. Only if the snapshot was taken before the troubles.

Have to go for a couple of hours.

Wiz
Well what I do know it that on my desktop I have 2 drives one with Windows 10 and the other with Mint and that is how I had to install them because I had a similar thing happen to me on my first install, so when I reinstalled everything the way I describe above it worked. both were 1TB drives and yes it was a little time consuming - also a 3rd 4TB usb drive attached for storage formatted to exfat - That is just how I fixed my machine
 
Yes, but just the G figure at bottom left, that will be the total in gibibytes, it could be 5, 15, 50 or other.

Back soon.

Yes, but just the G figure at bottom left, that will be the total in gibibytes, it could be 5, 15, 50 or other.
@wizardfromoz I don't know if this is the right screenshot for which you asked for, but I have posted the part you mentioned (bottom left). Hope that gives you a better overview :).

Issuing dh -ah /home/mikeubnt-pc/

Selection_047.png
 
I’m thinking out loud, so to speak, here, and clarifying what I have learned.

• Mike Posted this Thread at (Greek time) 3:57 PM Wednesday 8th December
• Earlier, at 11:17:30 PM Saturday 4th December he had taken a Timeshift snapshot of the system. Time shown is start time, finish will be a couple of minutes later (can be established if needed from Timeshift’s logs).
• From the GParted screenshot of (/dev/sda) the 4 TB hard drive, there is no EXT4 partition there for Timeshift (which is where it is best placed), nor on any of the other drives, so Mike has his Timeshift stored in a folder in (/home/mikeubnt-pc/)?


1. So I would ask Mike to check in his File Manager if there is an entry

(/home/mikeubnt-pc/timeshift/snapshots/2021-12-04_23-17-30) or similar?

2. From the output of du -ah Mike has given, the contents of his Home consume only 3.2GB of space. If he believes that before 4th December, the system was working OK (both Windows and Ubuntu on a Grub Menu), then I would advise running a Timeshift Restore action and see if it results favourably. It won’t hurt Windows.

3. If he chooses that option, I would first like to see a screenshot from his Timeshift of

Settings – Location

and

Settings – Users

I can tell him what will happen with the Timeshift Restore.

Cheers

Wiz
 
If he believes that before 4th December, the system was working OK (both Windows and Ubuntu on a Grub Menu)
The wired thing is that if I start into bios and change the boot order to boot from Ubuntu, then the loader starts properly. The same for when I want to run Windows. Only if I start without going into BIOS then this error occurs.
Ah, now I understand your thinking better, Chris. But I thought that this was the trouble... same as a year ago... that grub does not find his Windows, and that he has been changing the boot order in BIOS for all this time (to avoid the grub> failure to start properly). But he had a bigger mess a year ago, especially with Linux partitioning. Since then, Windows 10 was upgraded from Home to Pro, and Ubuntu was upgraded from 18.04 to 20.04, and the partitioning looks much better, but it lacks /boot/efi on the Ubuntu drive, which was his wish to keep these systems separate. Yet a clean reinstall of Ubuntu 18.04 a year ago did have /boot/efi, and still did not solve the problem.

So, which is it, Mike? Was your grub booting both operating systems properly until just recently? Or has this been a continuous problem for you?
 
Well what I do know it that on my desktop I have 2 drives one with Windows 10 and the other with Mint and that is how I had to install them because I had a similar thing happen to me on my first install, so when I reinstalled everything the way I describe above it worked.
By chance, was your Windows 10 drive also a NVMe with Linux on SSD, like Mike's setup? I keep getting drawn to Linux issues with NVMe drives (perhaps wrongly)... it seems that many people have troubles with them.

I bought a new Dell desktop about a month ago with Windows 11 on a NVMe drive. What I have done is to shrink the Windows volume and install Fedora Linux in the newly created space. Grub works fine in this dual-boot setup. But not all Linux distros would boot or install on the NVMe... explaining why these drives continue to concern me. I realize some of my own trouble is that (for now) I refuse to disable Secure Boot. I want to keep the UEFI BIOS settings at default, if I can. Fedora works, while many others do not.
 
I’m thinking out loud, so to speak, here, and clarifying what I have learned.

• Mike Posted this Thread at (Greek time) 3:57 PM Wednesday 8th December
• Earlier, at 11:17:30 PM Saturday 4th December he had taken a Timeshift snapshot of the system. Time shown is start time, finish will be a couple of minutes later (can be established if needed from Timeshift’s logs).
• From the GParted screenshot of (/dev/sda) the 4 TB hard drive, there is no EXT4 partition there for Timeshift (which is where it is best placed), nor on any of the other drives, so Mike has his Timeshift stored in a folder in (/home/mikeubnt-pc/)?


1. So I would ask Mike to check in his File Manager if there is an entry

(/home/mikeubnt-pc/timeshift/snapshots/2021-12-04_23-17-30) or similar?

2. From the output of du -ah Mike has given, the contents of his Home consume only 3.2GB of space. If he believes that before 4th December, the system was working OK (both Windows and Ubuntu on a Grub Menu), then I would advise running a Timeshift Restore action and see if it results favourably. It won’t hurt Windows.

3. If he chooses that option, I would first like to see a screenshot from his Timeshift of

Settings – Location

and

Settings – Users

I can tell him what will happen with the Timeshift Restore.

Cheers

Wiz


@wizardfromoz
• From the GParted screenshot of (/dev/sda) the 4 TB hard drive, there is no EXT4 partition there for Timeshift (which is where it is best placed), nor on any of the other drives, so Mike has his Timeshift stored in a folder in (/home/mikeubnt-pc/)?


1. So I would ask Mike to check in his File Manager if there is an entry

(/home/mikeubnt-pc/timeshift/snapshots/2021-12-04_23-17-30) or similar?
My Timeshift image was stored on /run/timeshift/backup/timeshift/snapshots/2021-12-04_23-17-30/localhost/, which I got via Right Click on sdb1 -> Browse Files.

Selection_048.png


Also Settings -> Users outputs this one
Selection_049.png
 
Ah, now I understand your thinking better, Chris. But I thought that this was the trouble... same as a year ago... that grub does not find his Windows, and that he has been changing the boot order in BIOS for all this time (to avoid the grub> failure to start properly). But he had a bigger mess a year ago, especially with Linux partitioning. Since then, Windows 10 was upgraded from Home to Pro, and Ubuntu was upgraded from 18.04 to 20.04, and the partitioning looks much better, but it lacks /boot/efi on the Ubuntu drive, which was his wish to keep these systems separate. Yet a clean reinstall of Ubuntu 18.04 a year ago did have /boot/efi, and still did not solve the problem.

So, which is it, Mike? Was your grub booting both operating systems properly until just recently? Or has this been a continuous problem for you?

@stan
So, which is it, Mike? Was your grub booting both operating systems properly until just recently? Or has this been a continuous problem for you?
No, this problem remains from last year, but I did everytime the reboot using the BIOS. Because I need to deal with a new project which requires both OS, it is very awkward for me to switch everytime via the BIOS. That is because I want to fix this problem. Before I was only working either on Win or on Linux, but this has changed recently.
 
OK, thanks Mike.

With that being the case, use of Timeshift (for now) is academic, as it would only restore the status quo, which does not work satisfactorily. :)

#7 on page 1 is therefore what I would use and recommend. The article I refer to there is one written by Dave McKay for How-To Geek and it is at https://www.howtogeek.com/442101/how-to-move-your-linux-home-directory-to-another-hard-drive/

Before following (part of) that article, I would use some of your 4 TB WD Data drive's extra, unallocated space.

Here is what you showed us it looks like

MdeJkG3.png

SCREENSHOT 1 - SPACE ALLOCATION, MIKE'S 4TB WD DATA DRIVE


You can see at the right, 396.76 GB space remaining, plenty for this purpose. I would use GParted to create a /dev/sda3 partition in EXT4 format, with say 10 GB space (you can use more), and then follow the relevant part of Dave McKay's article, to move your Home from the folder within your Ubuntu on /dev/sdb1, to the new partition on /dev/sda3.

At a later date, I would also use the space in the WD to create a partition /dev/sda4, in EXT4, of 50 - 100 GB (or size of your choice) for Timeshift snapshot storage, to replace your current Timeshift setup. We can talk about that in my Timeshift Thread.

I would then have a USB stick with Ubuntu Live on it, and either use Window's Disk Management to blow away the existing Ubuntu, or else use the GParted from the Live stick to at least reformat (and so remove the Ubuntu) /dev/sdb1.

Then I would continue on with the stick to launch the Ubuntu Installer (known as Ubiquity), and where it asks about install method (Install alongside Windows, Erase Disk and Install, Other) choose Other, get it to choose /dev/sdb (no number) for the boot installation, the new /dev/sdb1 for your root OS / , and point it to /dev/sda3 on the WD for Home.

When that's all finished, reboot, and see how you go.

So that's basically what I would do, but if you choose this method, I'll go through Dave McKay's article with you, because you likely won't need to do some of his stuff at the beginning, if you use GParted.

OR you may wish to use another of the methods described above, all we want is for you to have a properly working system.

Let us know.

Cheers

Wizard
 
By chance, was your Windows 10 drive also a NVMe with Linux on SSD, like Mike's setup? I keep getting drawn to Linux issues with NVMe drives (perhaps wrongly)... it seems that many people have troubles with them.

I bought a new Dell desktop about a month ago with Windows 11 on a NVMe drive. What I have done is to shrink the Windows volume and install Fedora Linux in the newly created space. Grub works fine in this dual-boot setup. But not all Linux distros would boot or install on the NVMe... explaining why these drives continue to concern me. I realize some of my own trouble is that (for now) I refuse to disable Secure Boot. I want to keep the UEFI BIOS settings at default, if I can. Fedora works, while many others do not.
my desktop machine has 2 western digital - 3.5in sata drives 1TB each - no NVMe - I had to use Windows for work and used Linux for everything else
 
Last edited by a moderator:
my desktop machine has 2 western digital - 3.5in sata drives 1TB each - no NVMe - I had to use Windows for work and used Linux for everything else
Okay, thanks Charlie. I'm going to try to follow your instructions above and see what kind of luck I have putting Ubuntu on SSD (with Windows NVMe disconnected) and then bringing them together. Maybe this will help guide Mike when he goes forward with his next reinstall.
 
OK, thanks Mike.

With that being the case, use of Timeshift (for now) is academic, as it would only restore the status quo, which does not work satisfactorily. :)

#7 on page 1 is therefore what I would use and recommend. The article I refer to there is one written by Dave McKay for How-To Geek and it is at https://www.howtogeek.com/442101/how-to-move-your-linux-home-directory-to-another-hard-drive/

Before following (part of) that article, I would use some of your 4 TB WD Data drive's extra, unallocated space.

Here is what you showed us it looks like

MdeJkG3.png

SCREENSHOT 1 - SPACE ALLOCATION, MIKE'S 4TB WD DATA DRIVE


You can see at the right, 396.76 GB space remaining, plenty for this purpose. I would use GParted to create a /dev/sda3 partition in EXT4 format, with say 10 GB space (you can use more), and then follow the relevant part of Dave McKay's article, to move your Home from the folder within your Ubuntu on /dev/sdb1, to the new partition on /dev/sda3.

At a later date, I would also use the space in the WD to create a partition /dev/sda4, in EXT4, of 50 - 100 GB (or size of your choice) for Timeshift snapshot storage, to replace your current Timeshift setup. We can talk about that in my Timeshift Thread.

I would then have a USB stick with Ubuntu Live on it, and either use Window's Disk Management to blow away the existing Ubuntu, or else use the GParted from the Live stick to at least reformat (and so remove the Ubuntu) /dev/sdb1.

Then I would continue on with the stick to launch the Ubuntu Installer (known as Ubiquity), and where it asks about install method (Install alongside Windows, Erase Disk and Install, Other) choose Other, get it to choose /dev/sdb (no number) for the boot installation, the new /dev/sdb1 for your root OS / , and point it to /dev/sda3 on the WD for Home.

When that's all finished, reboot, and see how you go.

So that's basically what I would do, but if you choose this method, I'll go through Dave McKay's article with you, because you likely won't need to do some of his stuff at the beginning, if you use GParted.

OR you may wish to use another of the methods described above, all we want is for you to have a properly working system.

Let us know.

Cheer

Wizard
@wizardfromoz For now, this all sounds very complex to me and you need a lot of time to deal with this solution which I don't have at present. All this previous staff, showed me that Linux is by far not the best solution like many say for software development or more precisely to run multiple OS in parallel. It lacks in a lot at present and I hope this will get improved in newer LTS versions. For now I leave it as it is. I didn't believed that this will be such a big problem to fix in less time. Nevertheless, thank you all for your help, I will come back when I will be proceed to fix this issue based on your suggestions.

Greetings from Greece :)
 
We'll still be here, Mike, and this Thread will still be here. :)

Wiz
 
If it boots you will have to use Windows Disk Manager and delete the /dev/nvme0n1p2 fat32 /boot/efi and add that space to ntfs Win 10, once completed reboot again to see if it boots normally - if it does then shut down and now you can plug in both drives - if not you will have to rebuild the Windows boot partition first before plugging in both drives
Previous disasters have taught me NOT to delete the Windows boot partition if I want to keep Windows. Grub does not contain a Windows bootloader, nor can it rebuild the Windows boot partition.... grub only "finds" an existing Windows bootloader and adds it to the grub boot menu. I have not found an easy way to restore a Windows bootloader on Windows 10 or 11... it was very easy in Windows 7 with bootrec.exe (/fixboot and /fixmbr), but I don't know if that is available with more modern Windows.

As a reminder to Mike, I said this a year ago working on this same problem:
First, let me say that every computer (and UEFI/BIOS) is different, and this is a constant struggle when folks cannot do what we think they should be able to do. Ubuntu should be able to install and work in UEFI mode, and even with Secure Boot enabled.
Back then, Mike was forced to boot Ubuntu in Legacy mode rather than UEFI. I think this was because his Windows was installed in Legacy/MBR. Windows and Ubuntu have both been replaced/upgraded since then.... but Mike's screenshot from Gparted does not tell us what partition table is being used. Please check on this Mike: Open Gparted, click on the View menu at the top, and tick the box for "Device Information." Confirm that both your Windows 10 Pro and your Ubuntu 20.04 show "gpt" as the partition table type. If either (or both) show "msdos"... you will want to correct this before your next reinstall. Mixing UEFI/GPT and BIOS/MBR operating systems is asking for trouble... maybe where all this trouble started. But I suspect you have them both as gpt correctly now.

Again, Mike, every computer and UEFI/BIOS is different. I was successful today and will describe my steps below, but that is not a guarantee that you will also be successful if/when you again choose to reinstall. Our motherboards are different, our NVMe drives are different, our UEFI/BIOS are different.... but we do have the same 860 EVO SSD for Linux. That won't save us! LOL ;)

To be honest, I don't know that this is worth all the effort to keep Windows and Linux each "separate" and more or less self-contained in it's own drive. Because they are not separated fully. When grub is updated so that it will show Windows on the boot menu, they are now linked. Future changes to either operating system may break this link. I don't think it's possible to make a dual-boot Windows/Linux "unbreakable"... they are very different systems, and the hardware makers greatly favor Windows. The best and safest thing is using separate computers for each OS.

I mentioned above that I had shrunk my NVMe Windows partition and installed Fedora Linux alongside it. This dual-boot arrangement worked fine. My UEFI/BIOS is set to defaults, so Secure Boot remains enabled... Fedora works with this, and so does Ubuntu. But you want the UEFI/BIOS settings correct before you begin... trying to change them after installing can again cause troubles.

To setup the dual-drive arrangement, I booted on a flash drive, deleted the entire NVMe drive with Gparted. I used my Windows 11 Recovery USB to restore Windows only on the NVMe, and rebooted a number of times to make sure it was all working correctly as a single Windows drive again. Then I removed the Windows NVMe from the computer.

Next, I installed the Samsung EVO 860... it had no OS and no partitions (unallocated space only). I booted on an Ubuntu flash drive, ran the full default install, and again rebooted a number of times to make sure all was working correctly. As the only OS, the grub menu is not really needed and was not displayed... it would boot straight into Ubuntu. I also did not choose "Install 3rd party software" when installing because it would need to change Secure Boot settings, and I want Secure Boot left alone.

Then I put the NVMe back in, booted into UEFI/BIOS setup, and both drives were visible as boot options, with Ubuntu listed first. Good enough! I booted and rebooted a number of times again, selecting each OS from my F12 Boot Menu. At this point they were not "linked" by grub, and either could have been first in the boot order, but I left it Ubuntu. Then, with Ubuntu running, I did sudo update-grub and successfully got this report:
update-grub.png


After that, with Ubuntu being first in the boot order, the grub menu was now showing and I could select Windows... and it worked as expected. This is what you have been trying to achieve!

That was @Lord Boltar's method... keeping the drives separate to make sure that the Ubuntu bootloader was installed to the correct drive. Of course it worked... Ubuntu had no other choice.

But @wizardfromoz is also correct in that it is not necessary to remove any drives, and I proved this also by erasing the EVO 860 Ubuntu installation from above and starting over. But care must be taken during the Ubuntu install at the partitioning step. With the NVMe drive still installed, and the EVO SSD totally empty, I booted on the Ubuntu USB and ran the installer....

Do not choose "Install alongside Windows" and do not choose "Erase disk and install Ubuntu"... you need the "Something else" option. This gives the options to properly partition the empty SSD... and 2 partitions are needed: first, an EFI System Partition (500 MB is a typical size, but way more than needed). The second will usually be set to EXT4, mounted at " / " and using the remainder of the drive space. Then, most important (and what you likely missed).... is at the bottom of this screen is an option (drop down selector box) to choose what "Device for boot loader installation." This should simply be /dev/sda ... but you will likely have to use the drop down selector to choose it. Note: /dev/sda for me... your sda is your 4TB data drive and sdb was Ubuntu, so be careful here. Don't use any partition number, like sda1 or sdb1... just /dev/sda or /dev/sdb as appropriate. (Another Note: I don't know if this matters, but have the ext4 partition highlighted (not efi) when beginning the installation. If it does matter, the efi partition is too small, obviously.) Also leave the small "free space" areas alone. This isn't a great photo, but you can see what I have done:
partition.jpg


This worked just as well to keep the Ubuntu bootloader separate from the Windows drive, as Chris said, but you have to be paying attention to it.

If you want to give up on dual-drive and instead dual-boot Windows and Linux on the same NVMe drive, you could choose "Install alongside Windows" without the need to first shrink the Windows partition. This option will provide a "slider bar" tool to allow you to resize the partitions and make room for Ubuntu. But if you pre-prepare a partition by shrinking Windows first, then you would use "Something else" option again, similar to the description above, but you would choose the NMVe drive for the bootloader (it will probably default to the correct location, but check it). I mention this because your 4TB storage is getting pretty full. Dual-booting on the NVMe could then open up the EVO SSD to be used for more storage, and especially creating an ext4 partition to store your Timeshift snapshots. Something to think about.

Here are my Gparted screenshots to show the final outcome:
windows.png


ubuntu.png


Whew.... I'm exhausted! ;) And I know you're not going to move on this anytime soon. That's okay. Hopefully I've given you enough information to fix this "problem" if/when you decide to tackle it again, and you'll remember to come back here and refresh yourself about this. But also remember... with our hardware differences, it still may fail to work properly for you. That would suck, but Windows and Linux often do not like to play well together, and I can't fix that.

Cheers :)
 
Last edited:

Staff online


Top