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

Unix & Linux Asked by Just Khaithang on January 6, 2022

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

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.

Answered by Michael on January 6, 2022

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

Answered by jmamma on January 6, 2022

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.

Answered by Steve on January 6, 2022

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

Answered by Oleg on January 6, 2022

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

Answered by Arni J on January 6, 2022

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


Answered by Just Khaithang on January 6, 2022

Add your own answers!

Ask a Question

Get help from others!

© 2024 All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP