[Bug 1822464] Re: iThe installer ignores deliberately selected /boot/efi partition

[Vladimir Yerilov]

** Description changed:

  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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1822464

Title:
  iThe installer ignores deliberately selected /boot/efi partition

Status in ubiquity package in Ubuntu:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1822464/+subscriptions