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

[Deleted member 108694]

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.

Fix Boot Record in Windows 11 - just for your general info
The next step is to go to the EFI partition and fix the boot record with the help of these commands.
cd /d
bootrec /FixBoot
ren BCD BCD.bak
bcdboot C:\Windows /l en-us /s x: /f ALL
bootrec /rebuildbcd
Now reboot - done

 

[stan]

That deserves a beer

Thank you, sir!

 

[stan]

Fix Boot Record in Windows 11 - just for your general info
The next step is to go to the EFI partition and fix the boot record with the help of these commands.

I gotta go write that down... thanks!

And I hope I never, ever, have to use it!

 

[stan]

Oh jeez.... let me again recommend separate computers for Windows and Linux!

You might think that removing the Linux drive (with it's self-contained boot partition) would be no big deal and Windows would return straightaway. You might be right, if you have more luck than I do.

That's right, removing the EVO SSD on my Dell left me with the same grub> prompt. I got into BIOS setup and restored the Windows Boot Manager as the first boot device. Yep, that worked. Then I restored BIOS defaults and I was back at the grub> prompt again. Hmmmm.

It's clear that more information is actually being stored in UEFI/BIOS settings itself, and not only on the boot partitions of each drive. This is new to me, and I'm not actually sure about the best way to resolve it. I'm not worried about it... I can get Windows back, no problem. But I do want to investigate what the best procedure is for a permanent remedy.

This is a great lesson in caution for anyone wanting to dual-boot or use a dual-drive setup. For those who like to "tinker" (like me)... it can be fun and challenging... and a good learning experience. But for @mike_linux, who needs his computers for his work, this could go from just a bad dream to a nightmare.

 

[mike_linux]

Oh jeez.... let me again recommend separate computers for Windows and Linux!

You might think that removing the Linux drive (with it's self-contained boot partition) would be no big deal and Windows would return straightaway. You might be right, if you have more luck than I do.

That's right, removing the EVO SSD on my Dell left me with the same grub> prompt. I got into BIOS setup and restored the Windows Boot Manager as the first boot device. Yep, that worked. Then I restored BIOS defaults and I was back at the grub> prompt again. Hmmmm.

It's clear that more information is actually being stored in UEFI/BIOS settings itself, and not only on the boot partitions of each drive. This is new to me, and I'm not actually sure about the best way to resolve it. I'm not worried about it... I can get Windows back, no problem. But I do want to investigate what the best procedure is for a permanent remedy.

This is a great lesson in caution for anyone wanting to dual-boot or use a dual-drive setup. For those who like to "tinker" (like me)... it can be fun and challenging... and a good learning experience. But for @mike_linux, who needs his computers for his work, this could go from just a bad dream to a nightmare.

@stan believe me it's a nightmare at this time to deal with all these solutions especially with the ones which have a lot of steps. So I leave it for now but I will come back when more free time is available .

 

[stan]

It's clear that more information is actually being stored in UEFI/BIOS settings itself, and not only on the boot partitions of each drive. This is new to me...

One last kick to this dead horse!

With a fresh look this morning, I now think that I was wrong about info being "actually stored in the UEFI/BIOS settings." But with the Linux drive removed... where did the grub> prompt come from?

As I said earlier, running sudo update-grub in order to bring the Windows boot option to the grub menu "links" the drives together, even though the desire is to actually keep the operating systems separate from one another. There may be a better term than "links" to describe this, but you get the idea.

So what happened is that I found an <ubuntu> folder in the \EFI partition on the Windows drive, and that must be the culprit. And it must have been put there automatically, by grub itself, I assume, but maybe by UEFI/BIOS. With some of my reboots and restoring the UEFI/BIOS settings to default (two different ways: BIOS defaults and Factory defaults)... something triggered the BIOS to try to load grub from that <ubuntu> folder, and it failed. I have now deleted that <ubuntu> folder and don't expect any further grub> prompts.

A 10-year old article provided very concise descriptions of how to delete the <ubuntu> folder from the Windows \EFI partition using either Linux or Windows.

To be very clear... @mike_linux should NOT delete the <ubuntu> folder on his Windows drive! Although grub seems partially broken, deleting that folder now might cause Ubuntu to fail to boot at all from the BIOS Boot method that is currently working. But he might choose to follow the article steps above to examine his \EFI partition and see if he can determine the trouble. Could there be two <ubuntu> bootloaders there, one working and one broken? That seems a stretch, but strange things happen sometimes.

Well, that was fun (for me) and I've learned some things.

Good luck, Mike!

 

[wizardfromoz]

So what happened is that I found an <ubuntu> folder in the \EFI partition on the Windows drive, and that must be the culprit.

Yep. Same applies in reverse. If you remove Windows you will find a reference to it in

/boot/efi/EFI/

You can safely delete the Windows folder.

Wiz