The installer ignores deliberately selected /boot/efi partition

Bug #1822464 reported by Vladimir Yerilov on 2019-03-31
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Undecided
Unassigned

Bug Description

I've noticed that Ubuntu installer ignores explicitly selected /boot/efi partition. I have 2 ssd drives: the first one is nvme (/dev/nvme0n1) the second one is sata (/dev/sda), both have their EFI partitions for multiboot purposes. During the installation process the installer generates fstab with /dev/nvme0n1p1 as /boot/efi despite the fact that the partition chosen for this mount point was /dev/sda1. Device for bootloader installation was /dev/sda. Moreover, /dev/nvme0n1p1 was even marked as "do not use this partition", but anyway it got put in requisition.
Moving bootloader files (grubx64.efi,etc) to initially desired location, editing fstab correspondingly, remounting partitions and re-installation of grub helps but these actions are not user-friendly and the situation itself is not good at all.
This issue affects Ubuntu 18.04 onwards (18.10 and 19.04 too).

$ lsb_release -rd
Description: Ubuntu Disco Dingo (development branch)
Release: 19.04

Information about partitions:

$lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTTYPE,MOUNTPOINT
NAME SIZE TYPE FSTYPE PARTTYPE MOUNTPOINT
loop0 143.5M loop squashf /snap/gnome
loop1 4M loop squashf /snap/gnome
loop2 53.7M loop squashf /snap/core1
loop3 3.7M loop squashf /snap/gnome
loop4 89.3M loop squashf /snap/core/
loop5 1008K loop squashf /snap/gnome
loop6 91.1M loop squashf /snap/core/
loop7 14.8M loop squashf /snap/gnome
loop8 35.3M loop squashf /snap/gtk-c
sda 465.8G disk
├─sda1 300M part vfat c12a7328-f81f-11d2-ba4b-00a0c93ec93b /boot/efi
├─sda2 402.7G part ntfs ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 /media/data
├─sda3 8.8G part swap 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f [SWAP]
├─sda4 19.6G part ext4 0fc63daf-8483-4772-8e79-3d69d8477de4 /
└─sda5 29.1G part ext4 0fc63daf-8483-4772-8e79-3d69d8477de4 /home
nvme0n1 238.5G disk
├─nvme0n1p1 599M part vfat c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─nvme0n1p2 16M part e3c9e316-0b5c-4db8-817d-f92df00215ae
├─nvme0n1p3 129.5G part BitLock ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
├─nvme0n1p4 499M part ntfs de94bba4-06d1-4d40-a16a-bfd50179d6ac
└─nvme0n1p5 107.9G part crypto_ 0fc63daf-8483-4772-8e79-3d69d8477de4

affects: ibus-anthy (Ubuntu) → ubiquity (Ubuntu)
description: updated
summary: - iThe installer ignores deliberately selected /boot/efi partition
+ The installer ignores deliberately selected /boot/efi partition
Tomek Kalinowski (tkali) wrote :

This bug is also present during 20.4 installation.

I have two ESPs on two different SSD drives. One used by Windows, another meant for Linux distros. Even though I mark Windows one as "Do not use this partition" during partitioning step, the Installer tries to mount it as /boot/efi anyway.

This is particularly troublesome if Windows taints the ESP somehow (like with Fastboot feature) and mounting process fails with the message:

"The attempt to mount a file system with type vfat (...) at /boot/efi failed"

resulting with whole installation process silently crashing (installer hangs on creating filesystems phase).

Possible workaround:

Boot into Ubuntu live environment with "Try Ubuntu" option, open GParted, unselect esp and boot flags for the ESP in question. Launch installer and make sure "Do not use this partition" option is selected for that ESP.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers