Return to

✓ [SOLVED] Grub keeps booting to command line even though I've tried everything

So I installed Ubuntu into a USB for a portable OS, and now when I have it out of the computer, grub boots to a command line even though I’ve configured in the other OS on the computer (Linux Mint 19.3) to do otherwise. If I type “prefix=(hd0,gpt2)/boot/grub” (without quotes) and then “normal” (also without quotes) it boots into the grub menu I configured with the interface, and I can choose Linux Mint from there. If I have the USB inserted, it automatically boots to grub with a menu interface, but it’s a different theme than the Mint one. I don’t know where the command line grub is booting from, but I need help making it where I don’t have to type that string to get to the boot menu. I’ve tried updating grub, reinstalling grub, and repairing grub, but nothing has worked. Sorry if this topic has already been discussed.

1 Like

You made the mistake of installing Ubuntu while running Mint. Grub detected your Mint install and modified it’s Grub menu to include Ubuntu. Or rather, it chain-loads Mint from the Ubuntu menu.

So, to fix this, boot into Mint (using the USB drive) then remove the USB drive from your system. Next, issue this command:
sudo grub-mkconfig -o /boot/grub/grub.cfg
This effectively rebuilds the grub menu for Mint. Let it finish, then reboot to see if it worked. If it didn’t, you may need some manual tweaking of the Grub config file. But we’ll get to that when the need arises :slight_smile:



If you have multiple installs, these problems become likely, sooner or later, because grub in each fights with the other grubs, and sometimes the windows boot manager, for control of the boot. Unplug something, plug something in, do a release upgrade, or even just get a new kernel, and on boot you get what’s called the “grub rescue” prompt. IMO you’ve done well to recover without resorting to booting from a live USB.

One solution I don’t like, but sometimes see advocated, is to keep different installs on different devices, and disconnect the others while installing, effectively using the boot firmware to control the boot. It’s limiting, and doesn’t always work.

I advocate for installing grub independently of any OS install, on its own partition or subvolume, taking control of the boot yourself. But if one intends that one install will always be there, it can be designated as the controller.

Either install the others without a boot loader, or after installing uninstall the grub package that “indicates that this version of GRUB should be the active boot loader” (on debian-derived distros that’s usually grub-efi-amd64) and boot back to the controlling install and run “sudo update-grub” there to re-establish it’s control. One can replace grub-efi-amd64 with grub-efi-amd64-bin which “will not automatically install GRUB as the active boot loader nor automatically update grub.cfg on upgrade”. This also avoids problems doing release upgrades.


I fixed the problem, thanks for the help! All I had to do was go to /boot/efi/EFI/ubuntu and change the grub.cfg file there to show the correct UUID and drive letter/number(s) corresponding to the Mint partition and then run “sudo grub-mkconfig -o /boot/grub/grub.cfg” and “sudo update-grub” WITH THE USB IN.

Thanks for your help, too!