0

My setup has multiple hard drives. The target drive was an SSD drive residing on /dev/sdc. Trying to perform a complete re-install of either 18.04 or 17.10 from a flash drive was failing with an error:

grub-install /dev/sda failed

I already had 16.04 installed there, and decided to install over it (letting the installer to wipe the disk). I chose "use the entire disk and create LVM", and the installer failed with the error above. I tried the 17.10 installer and had the same issue.

After trying multiple workarounds suggested on the forums (boot-repair, GPT, Fast Boot, Secure boot, etc.) and none solving the problem, thinking about why is it trying to install grub onto /dev/sda instead of /dev/sdc I decided to try to disconnect all hard drives but that one.

As soon as I had just the SSD drive, it installed without a hitch.

I have no idea why it was trying to install grub onto /dev/sda. Perhaps it's a bug in the installer. 2 years earlier I installed onto the same drive on the same system from 16.04 installer without a problem.

FYI, my SSD was set to be the first drive to boot from in BIOS, except it wasn't connected as a first SATA drive, which should make no difference.

Hope this helps someone.

edit: and I have just noticed the installer botched it even more. It created 1GB Swap partition, for a 24GB RAM installed. Yickes. I had to go to live CD, install and use kvpm to reduce the root lvm partition and extend swap.

Improve this question
2
  • 1
    First drive makes a huge difference with UEFI installs. Ubuntu's UEFI grub only installs to ESP on sda. And even if BIOS install, default grub install will be to sda. If you want full install on sdc, often easiest is just to unplug all other drives. Otherwise you must partition in advance and copy files from ESP on sda to ESP on sdc. Or reinstall BIOS grub to sdc, if BIOS. Boot-Repair may let you install grub to sdc, but you must have ESP if UEFI and gpt partitioning. help.ubuntu.com/community/Boot-Repair
    – oldfred
    Aug 1, 2018 at 22:36
  • Yes, indeed. And you'd think that the installer program would tell that to the user. But it just fails.
    – stason
    Aug 2, 2018 at 3:23

1 Answer 1

Reset to default
0

I was seeing this problem while trying to install Ubuntu yesterday after a run with MX Linux. Tried multiple OSes, partition options, and ways of creating the LiveUSB I was using.

Turned out I had too many entries in the EFI portion of the NVRAM on my motherboard (nothing to do with the SSD or install options). I was able to fix it by opening a terminal using the LiveUSB, installing efibootmgr using apt, and removing the old boot entries.

Improve this answer

You must log in to answer this question.

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