Ubuntu 18.04 server installation gets stuck at 66% while running'update-grub'

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.

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 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.

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
GRUB_CMDLINE_LINUX="GRUB_DISABLE_OS_PROBER=true"

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

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

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

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.)

KiBi