I am trying to install Ubuntu server but it always get stuck at the last stage while updating grub.I cancelled the process and rebooted my system, it took me to the grub command prompt grub> .

I tried a manual boot from prompt:

root=(hd1,gpt5)       # Ubuntu root partition
linux   /boot/vmlinuz-something-   root=/dev/sda5
initrd    /boot/initramfs-something-

After some boot message scrolling, it dropped me in the

Busybox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3) built-in. shell (ash) 

with the initramfs> prompt. From here I did an exit And it showed me the kernel panic! with the following two hints.

mount: mounting/says on /root/says failed : No such file or directory
mount: mounting /process on /root/process failed: No such file or directory

6 Answers 6


Not a solution but a couple of Workarounds. Apparently, that's a bug in os-prober . I personally tried the second one and it works! To quote from the link:

Workaround 1: (proaction)

When you are reaching
the “Install the GRUB boot loader to the master boot record?” prompt, (in my case, no such prompt appeared but i figured out timing of the grub-install) switch to a console (ctrl+alt+[f2-f6]), and remove this file:

rm /target/etc/grub.d/30_os-prober

This will prevent update-grub from running os-prober, which should avoid running into this issue. Of course, other operating systems won't be listed, but at least that should prevent the installation process from getting entirely stuck. I've tested this successfully in a VM with guided (unencrypted) LVM, and standard plus ssh tasks (which is how I initially reproduced your issue).

Workaround 2: (reaction)

Otherwise, once the process is stuck, locate the process identifier (PID) on the first column of the ps output:

ps | grep 'dmsetup create'

then kill this dmsetup process. With your output above, that'd be:

kill 19676

(Tested successfully in a VM with the same setup/choices as above.)


  • I had to kill it twice, but it's unstuck now. I'll report back if I discover any side effects.
    – musicin3d
    Jun 20, 2019 at 20:07
  • thanks for explaining. i had to kill the os-prober calls themselves, otherwise it respawned. after being told there was a 'fatal error' (an installer, with the single purpose of installing something, being being stuck during installation till the end of time, apparently, is not fatal) I deleted the file and started over. This seems to have done the trick. Thanks for the good explanation. You'd think that the most standard model of the most standard Dell server would be working by subrelease 6 of the install ISO, but no. Apr 7, 2022 at 16:20
  • for the record, os prober had detected there's no other OS, so the theory laid out at the end of the 2017 bug report is likely incomplete. not to mention how the installer first asks us if we wanna wipe all of the boot disk and then tries to scan the system for other OS installs and so on and so on. would still love to understand what exactly it is about the PERC raid volumes that trips the OS probes. Apr 7, 2022 at 16:24

This happened to me while installing to 2x SAS HDD drives in a PERC RAID 1 on a Dell Poweredge r630.

I used ctrl+alt+f2 to get the console and killed the process and then returned to the installer with ctl+alt+f1 - your mileage may vary


Automated workaround for preseed

If you pass kernel argument GRUB_DISABLE_OS_PROBER=true after --- then grub-install stage will not hang at 66% and this variable will be added in the grub settings on a target host.

For example:

/etc/default # grep PROB grub

it works due to the code in the /etc/grub.d/30_os-prober

if [ “x${GRUB_DISABLE_OS_PROBER}” = “xtrue” ]; then
exit 0

I had this same problem installing xubuntu 20.04 (you'd think they would have squashed this bug by now). While the installer was "copying files" I used ctl-alt-f2 to get to the terminal. It asked for a login, which I finally discovered was xubuntu with no password. Once in I used @JustKhaithang's workaround 1 (had to run as sudo) and voila the install completed without a hitch.


I had this issue with Bionic 18.04. The suggested answers did not work.

The process getting stuck during the ubuntu installer is grub-probe

It appears to be due to read errors to SAS hard drives (probably specific to our server configuration). These drives are not required during my install but are still present in /dev/ and /sys/block.

The solution is to hide these drives from /dev , then restart the partitioning process. (You must also terminate the stuck grub-probe from terminal by finding the process id -> ps | grep grub-probe)

You need to identify which /dev/ devices to hide and use the following command.

echo 1 > /sys/block/$dev/device/delete;

Using a for loop, I perform the above command on any drive /dev/sd* that is not the installation target


I had something similar happen when installing Ubuntu 20.04 on two drives with the root partition on one and home partition on the second. I turned the machine off, unplugged the second drive and when I started configuration again I told it to download updates while installing. Just unplugging the drive was not enough by itself.

I will move the home directory to the second drive after I get the system set up. Apparently what I was asking it to do was just too complicated for the installer to handle.

You must log in to answer this question.

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