I installed Linux Mint on my laptop along with a pre-installed Windows 10. When I turn on the computer, the normal GRUB menu appears most of the time:

GRUB menu

But after booting either Linux or Windows then rebooting, I GRUB starts in command line mode, as seen in the following screenshot:

GRUB command line

There is probably a command that I can type to boot from that prompt, but I don't know it. What works is to reboot using Ctrl+Alt+Del, then pressing F12 repeatedly until the normal GRUB menu appears. Using this technique, it always loads the menu. Rebooting without pressing F12 always reboots in command line mode.

I think that the BIOS has EFI enabled, and I installed the GRUB bootloader in /dev/sda.

Why is this happening and how can I ensure that GRUB always loads the menu?


As suggested in the comments, I tried purging the grub-efi package and reinstalling it. This did not fix the problem, but now when it starts in command prompt mode, GRUB shows the following message:

error: no such device: 6fxxxxx-xxxx-xxxx-xxxx-xxxxxee.
Entering rescue mode...
grub rescue>

enter image description here

I checked with the blkid command and that is the identifier of my linux partition. Maybe this additional bit of information can help figure out what is going on?

  • IMHO Windows 10 has an update that sabotages (albeit possibly through incompetence) this kind of setup. You will need to get into your Linux, through the sequence of commands you mentioned or a live CD and fix the grub-efi package. Try purging and reinstalling grub-efi.
    – 111---
    Commented Dec 12, 2016 at 22:12
  • What is the output of cat /etc/default/grub? Commented Dec 17, 2016 at 10:53
  • 10
    Sometimes you can just type the word "exit" and hit return, and it will continue correctly. Commented Oct 5, 2019 at 15:45
  • here is what i did to fix this: open bios go to UEFI boot sequence add a new boot sequence; provide following file as boot loader for windows partition: (assuming you still hv primary partition) \EFI\Microsoft\Boot\bootmgfw.efi set it as the first boot option (if others are shown)
    – Nrj
    Commented Dec 23, 2022 at 1:12

15 Answers 15


The boot process can't find the root partition (the part of the disk, that contains the information for starting up the system), so you have to specify its location yourself.

I think you have to look at something like this article: how-rescue-non-booting-grub-2-linux

short summary:

in the grub rescue> command line type


... to list all available devices.
Then you have to go through each, type something like (depends what is shown by the ls command):

ls (hd0,1)/
ls (hd0,2)/ 

... and so on, until you find:

(hd0,1)/boot/grub   OR (hd0,1)/grub

... or, in case of "UEFI", it look something like:

(hd0,1)/efi/boot/grub OR (hd0,1)/efi/grub

Now you have to set the boot parameters accordingly - just type the following (with the correct numbers for your case) and after each line press return:

set prefix=(hd0,1)/grub

... or (if grub is in a sub-directory):

set prefix=(hd0,1)/boot/grub

Then continue with

set root=(hd0,1)
insmod linux
insmod normal

Now it should boot:


Go to the commandline (e.g. start a "terminal") now, and execute:

sudo update-grub

... this should correct the missing information and it should boot next time.

If NOT - you have to go through the steps again an might have to repair or install grub again:
Please look at the "Boot-Repair"-tool from this article: https://help.ubuntu.com/community/Boot-Repair (I had positive experiences with it, when previous steps wouldn't survive the reboot)

  • 6
    I will try this, but this answer does not explain why sometimes grub is able to find the partition, but if I press F12 before it loads, it is then able to find the partition. Commented Dec 17, 2016 at 18:45
  • 1
    @user2205916 ls gave you (hd0) ... this is a 'zero' as in '01234', and you wrote you tried ld (hdo)/ with an 'o' as in '..LMNOPQRS..' - you have to use the number 0 "zero"
    – MacMartin
    Commented Jul 11, 2018 at 8:01
  • 3
    The irony here is that boot-repair is what put it into this state to begin with... Commented Feb 24, 2020 at 19:27
  • 4
    This works for me, except the changes aren't persistent. once i restart the system, I get the boot loader CLI right back again.
    – J-Cake
    Commented Feb 26, 2020 at 1:33
  • 2
    I found that just before doing sudo update-grub I needed to do sudo grub-mkconfig, otherwise update-grub was installing a non-working configuration.
    – Adambean
    Commented May 20, 2020 at 10:08

This is some funny thing happening to many PC dual booting with Windows 10. Happened to me and friends recently. Please note that I don't know why, I can only speculate this depends on some Windows 10 updates. As someone said, indeed this is due to the boot process not finding the root partition for some reason, so GRUB asks you to tell him where it is via CLI.

this is what I got

Anyway thanks for asking this question, I found it trying to fix my problem and I created this account just to answer this. The fix is super easy :

  • go to BIOS/UEFI
  • check the boot partitions: are there ok or too many? do you recognize all of them? Remove the ones that are not needed.
  • reset the boot order to default
  • restart, you should see the usual GRUB menu
  • 2
    This was exactly my case when installing Manjaro. After rebooting it would always go to the grub shell, which was a hassle. The problem was that in the UEFI boot options, the order for the hard rive was: 1. Live CD (not connected anymore). 2. Windows Boot Manager (the one that actually went to the grub shell). 3. Manjaro (which is actually Manjaro's grub). After putting Manjaro first in the UEFI boot order, the computer starts up and goes to grub as it's supposed to.
    – Arkenan
    Commented Feb 9, 2019 at 18:16
  • 1
    Changing the boot order worked for me: I had Windows 10 installed on Dell laptop, then installed Ubuntu 16.04 on an external SSD hard drive but somehow managed to end up with grub coming up on boot. I changed the boot order to Windows first and now it boots straight to Windows - I'm happy to F12 to boot to Ubuntu for now.
    – WillC
    Commented Jul 11, 2019 at 0:03
  • 1
    here is what i did to fix this: open bios go to UEFI boot sequence add a new boot sequence; provide following file as boot loader for windows partition: (assuming you still hv primary partition) \EFI\Microsoft\Boot\bootmgfw.efi set it as the first boot option (if others are shown)
    – Nrj
    Commented Dec 23, 2022 at 1:15

You can boot your linux system through Super Grub2 disk, Download the iso from here and create a bootable USB

After successfully booting kali linux , reinstall grub-efi as follows :

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=debian --recheck --debug /dev/sda
  • Thank you, that solved my issue. I used boot-repair which created a new partition and installed Grub, but it was giving me the grub console. Doing the given command solved my issue.
    – ZedTuX
    Commented Jan 11, 2020 at 6:02
  • Fixed my grub boo with the newer Rescatux on the same site. Commented Feb 3, 2022 at 17:39

I suddenly found that after some updates Windows has set the Fast boot option to enabled. And that caused my ubuntu boot problem)) Fast boot option can be found somewhere in your BIOS/boot settings

  • 2
    I tried a lot of advices, which didn't work. The solution was really simple, just disable fast boot. Linux root partition was on a second drive that did not have enough time to initialize. Perhaps this comment will help someone to pay attention to this answer.
    – Denis
    Commented Jan 5, 2022 at 7:23

I ran into the same issue. And I found that sometimes when booting in windows 10 the boot order is changed. I have two SSDs in my laptop. One has ubuntu and grub and the other has windows installed. The boot order is sometimes changed when windows 10 updates and puts the windows SSD first, causing the system to always boot into windows. Recently it randomly changed it and I started seeing the system boot into the grub prompt. Once I changed the boot order in BIOS, the grub menu loaded normally.


If you happen to boot into GRUB menu:

1. Start your system

1.1 Figure out which partition is the system one via mounting available partitions and looking for executable kernel file:

grub> ls # shows list of disks and partitions available
(hd0,gpt1), (hd0,gpt2) # you might have other things listed here
grub> set root=(hd0,gpt1)
ls /boot # if theres a file called vmlinuz<version> or initrd<version>, bingo!

If there's no vmlinuz file, call unset root and try with another one set root=(hd0,gpt2)

1.2 Load a linux kernel:

grub> linux /boot/vmlinuz-<version> # use TAB to autocomplete version. if theres multiple versions, use whatever

1.3 Load a linux initrd file:

grub> initrd /boot/initrd.img-<version> # same deal, use TAB to autocomplete version

1.4 Boot up your system:

grub> boot

2. Reinstall grub

2.1 Make sure `grub-install` is there:

sudo apt-get install grub-install

2.2 Reinstall grub for the mounted disk:

sudo grub-install /dev/sdX

sdX means a device mounted in step 1. If not sure, issue lsblk and look for the device which has / mountpoint:

$ lsblk
sda      8:0    0 223.6G  0 disk              <-- in my case, sdX = sda
├─sda1   8:1    0   100M  0 part /boot/efi
├─sda2   8:2    0 130.9G  0 part /mnt/windows
├─sda3   8:3    0    28G  0 part /            <-- because this is under sda
├─sda4   8:4    0   7.9G  0 part [SWAP]
├─sda5   8:5    0   128M  0 part
└─sda6   8:6    0  56.6G  0 part /home

2.3 Reboot

systemctl reboot

At this point, GRUB bootloader should work as you intend so.

References/similar issues:

  • 1
    nice, I got "boot arguments must include a root parameter" tho Commented Jun 7, 2020 at 1:20
  • 4
    Please note you may need to set the root partition again when running the linux command, so that you won't get a kernel panic (usually complaining about some root parameter). So the complete linux command looks like this: grub> linux /vmlinuz root=/dev/sda1. More info at @perlinwarp answer below Commented Nov 1, 2020 at 9:36
  • Your solution saved me again, omg this should be highlighted to the world 😭
    – testing_22
    Commented Nov 15, 2021 at 22:23
  • Re-specifying the linux may NOT change the value. I found rebooting from scratch if you didn't provide the root=X parameter works. (You only get one chance to type every command perfectly). Note that SSDs are typically named nvme0n1pX where X is the partition. Typically X=2 on debian-based systems.
    – aphid
    Commented May 24, 2023 at 9:17

Try these commands

Repeat this for all listed partitions until you find a result that includes something like initrd.img-... vmlinuz-... or even /grub.

Once you find a partition that contains your Linux Mint boot image you will run the following steps:

You should initialize kernel

grub> set root=(hd0,1)
grub> linux /vmlinuz-4.4.0-38-generic 
grub> initrd /initrd.img-4.4.0-38-generic
grub> boot

grub> set root=(hd0,[partition number you found])/boot
grub> insmod linux
grub> linux (hd0,[partition number you found])/boot/vmlinuz-[image name]
grub> initrd ((hd0,[partition number you found])/boot/initrd.img-[image name]
grub> boot

Once booted into your Linux Mint install and not a rescue disk or anything if you see that you are missing Windows from GRUB you will need to follow these steps:

sudo os-prober \\ If you see your Windows Partition then you can run the next step
sudo grub2-mkconfig
sudo update-grub
  • I dont find anything /vmlinuz-4.4.0-38-generic. I had installed ubuntu 20.04. which directory i should run these commands in?
    – Harry
    Commented Dec 19, 2020 at 1:22
  • @Harry try ls boot/ to see if you find it there. If so use boot/vmlinuz.... instead
    – testing_22
    Commented Oct 23, 2021 at 14:07

If entering 'exit' on the GRUB command prompt brings you to the GRUB menu, it could be an issue with the boot priority sequence in your BIOS utility.

For me the fix was to reorder the boot sequence - I entered my BIOS utility on startup and reordered the 'UEFI Hard Disk Drive Priorities' so that the Ubuntu partition was first in line.

My understanding is that entering 'exit' on the GRUB menu will quit GRUB and cause the BIOS to try and start the next available bootloader.


Your Windows may be installed in UEFI boot mode and Mint in BIOS boot mode. The two modes are not compatible and you can only dual boot from UEFI/BIOS menu and may have to turn on or off UEFI or BIOS boot settings. Grub can only dual boot other installs in same boot mode as you booted grub. You can use Boot-Repair to convert a BIOS.


After spending a while on this page, here is what worked for me:

Check each of the partitions until you find one with vmlinuz and initrd on. This could be in the same partition as root or (not in my case).

There will be one partition (root) you find with bin/ and boot/ etc in. If you "ls" in the boot folder and it's empty, you will have to look for vmlinuz somewhere on another partition.

(hd0,msdos1) corrisponds to /dev/sda1.
(hd1,msdos4) corrisponds to /dev/sdb4

set root = (hd0,msdos6)
linux (hd0,msdos1)/vmlinuz root=(hd0,msdos6)
initrd (hd0,msdos1)/initrd 


  • After typing vmlinuz you can press tab for autocomplete.
  • Replace (hd0,msdos1) with where vmlinuz and initrd are
  • Replate (hd0,msdos6) with the typical root parition, you should find bin/ boot/ home/ etc/ in here.

Pressing enter should lead you back into Ubuntu. If it does not, you got your partitions wrong.

sudo update-grub
sudo grub-install /dev/sda

Note: - The lack of numbers after /dev/sda

TL;DR - Read this: How to Rescue a Non-booting GRUB 2 on Linux


The same issue occurred on my dell laptop with windows 10 and Linux mint 19. So what happened was I was working windows and suddenly the hdd was missing from the disk list. Window was working fine since it was on ssd drive. After being confused for a while I wanted to make sure if the hdd was functioning so I run a diagnostic from the bios after it was done I restarted the machine and got my grub listing back.


After installing Linux Mint 19.1 the system would only boot to the grub rescue> prompt and displayed an error just above it indicating it could not find hd0. Thanks to this thread I accessed the BIOS and under "Storage/Storage Options" I changed the SATA emulation from AHCI RAID to Native Mode IDE and now the system boots up to the proper menu which allows me to choose my Linux Distribution and continue booting successfully.

  • I don't understand why this is being downvoted and is even collecting delete votes. This solution isn't mentioned anywhere else and seems to be a perfectly valid one.
    – terdon
    Commented Jan 12, 2020 at 13:48

Reinstall Linux on same partition, take care of foll. things this time:

  1. Start Live and then install
  2. Once installation is over, DO NOT Reboot
  3. Close the dialog box, and open Terminal Ctrl + Alt + T
  4. Type following command- sudo update-grub

Check for Line *"Found Windows Boot Manager ..."*

  1. Reboot if successfully done

I had this problem with Ubuntu. I went into BIOS and disabled Intel Encryption, Secure Boot, and anything else that looked vaguely like a security feature. Then installed Ubuntu again and it installed fine.


I copied my kubuntu 19.10 partition from hd to SSD to make the system work faster and didn't want to reinstall everything over again. I want to keep the original partition as a backup since I want to experiment with davinci resolve. So I changed UUID using Gparted. Then I got the Grub 2.02 "Mininal BASH-like line editing..." error. All I did was to booted into setup and changed the boot order to get it fixed. Now I see Kubuntu 19.10 on sda11, windows on sda1 and kubuntu 19.10 on sdb2. I hope it'll help someone.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .