Installing the zipl boot loader fails because "/boot' is located on a multi-target device-mapper device"

[bugproxy]

Installer version: 20101020ubuntu501
Kernel: 4.10.0-15

Description/Reproduction:

System is using two multipathed FCP-LUNs. A volume group is created over these two LUNs and logical volumes for root and home are defined.

~ # vgs
  VG #PV #LV #SN Attr VSize VFree
  rootvg 2 2 0 wz--n- 39.99g 0

~ # pvs
  PV VG Fmt Attr PSize PFree
  /dev/mapper/mpatha1 rootvg lvm2 a-- 20.00g 0
  /dev/mapper/mpathb1 rootvg lvm2 a-- 20.00g 0
  /dev/mapper/mpathc1 lvm2 --- 20.00g 20.00g
  /dev/mapper/mpathd1 lvm2 --- 20.00g 20.00g

~ # lvs
  LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
  homelv rootvg -wi-ao---- 11.18g
  rootlv rootvg -wi-ao---- 28.81g

The installer fails on "Install the ZIPL boot loader on a hard disk". In syslog you see the following errors:

Apr 5 12:39:49 zipl-installer: Root filesystem on /dev/mapper/rootvg-rootlv (/dev/mapper/rootvg-rootlv)
Apr 5 12:39:49 zipl-installer: info: Root filesystem is on LV ( rootvg rootlv)
Apr 5 12:39:49 zipl-installer: Error: Unsupported setup: Directory '/boot' is located on a multi-target device-mapper device
Apr 5 12:39:49 zipl-installer: Using config file '/etc/zipl.conf'
Apr 5 12:39:49 zipl-installer: Ignore section 'old': Image file '/boot/vmlinuz.old'
Apr 5 12:39:49 zipl-installer: Run /lib/s390-tools/zipl_helper.device-mapper /boot
Apr 5 12:39:49 zipl-installer: Error: Script could not determine target parameters
Apr 5 12:39:49 main-menu[355]: (process:17396): File descriptor 3 (pipe:[11141]) leaked on lvm invocation.
Apr 5 12:39:49 main-menu[355]: (process:17396): Parent PID 17397: /bin/sh
Apr 5 12:39:49 main-menu[355]: (process:17396): File descriptor 4 (/dev/pts/0) leaked on lvm invocation.
Apr 5 12:39:49 main-menu[355]: (process:17396): Parent PID 17397: /bin/sh
Apr 5 12:39:49 main-menu[355]: (process:17396): File descriptor 5 (/dev/pts/0) leaked on lvm invocation.
Apr 5 12:39:49 main-menu[355]: (process:17396): Parent PID 17397: /bin/sh
Apr 5 12:39:49 main-menu[355]: (process:17396): File descriptor 6 (/dev/pts/0) leaked on lvm invocation.
Apr 5 12:39:49 main-menu[355]: (process:17396): Parent PID 17397: /bin/sh
Apr 5 12:39:49 main-menu[355]: WARNING **: Configuring 'zipl-installer' failed with error code 1
Apr 5 12:39:49 main-menu[355]: WARNING **: Menu item 'zipl-installer' failed.

As the error message says, having the /boot partition on a device-mapper device is not supported. If that error is not a bug, then the partitioner should not allow having such a setup and display a warning.

[bugproxy (bugproxy)]

Default Comment by Bridge

[Dimitri John Ledkov (xnox)]

I have not reproduced this bug yet, if true, I will try to fix, but I think it is too late to make onto 17.04 release media.

[Dimitri John Ledkov (xnox)]

Adding candidate to be release noted as known issue.

[Launchpad Janitor (janitor)]

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

[Dimitri John Ledkov (xnox)]

Creating warning and preventing partitioning should improve this, however this will make default autopartitioning recipe to fail. If clicking next blindly fails to install the system - is a very bad user experience.

I believe I need to introduce separate /boot recipe, and do automatic detection for must have separate /boot or not, and act appropriately.

Not sure if this will be an extra set of recipes in partman-auto or a new stanza.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-07-04 07:01 EDT-------
(In reply to comment #6)
> Creating warning and preventing partitioning should improve this, however
> this will make default autopartitioning recipe to fail. If clicking next
> blindly fails to install the system - is a very bad user experience.

Yes, indeed!

> I believe I need to introduce separate /boot recipe, and do automatic
> detection for must have separate /boot or not, and act appropriately.

That's IMO the best solution, to detect, whether /boot must be separate or not and having a separate recipe for setups with separate /boot.

> Not sure if this will be an extra set of recipes in partman-auto or a new
> stanza.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-11-29 04:14 EDT-------
Canonical, will this make it into 18.04 ?

[bugproxy (bugproxy)]

Default Comment by Bridge

[Frank Heimes (fheimes)]

My tests on 18.04 beta 2 show that this is fixed.

Installed and configured a system like follows and it boots fine - hence closing this ticket.

  ┌────────────────────────┤ [!!] Partition disks ├─────────────────────────┐
  │ │
  │ This is an overview of your currently configured partitions and mount │
  │ points. Select a partition to modify its settings (file system, mount │
  │ point, etc.), a free space to create partitions, or a device to │
  │ initialize its partition table. │
  │ │
  │ - │
  │ Multipath mpatha (WWID 36005076306ffd6b60000000000002600) - 68.7 ▒ │
  │ > #1 primary 68.7 GB K lvm ▒ │
  │ Multipath mpathb (WWID 36005076306ffd6b60000000000002601) - 68.7 0 │
  │ > #1 primary 68.7 GB K lvm ▒ │
  │ LVM VG rootvg, LV homelv - 100.0 GB Linux device-mapper (linear) ▒ │
  │ > #1 100.0 GB f ext4 /home ▒ │
  │ LVM VG rootvg, LV rootlv - 37.4 GB Linux device-mapper (linear) ▒ │
  │ > #1 37.4 GB f ext4 / ▒ │
  │ . │
  │ │
  │ <Go Back> │
  │ │
  └─────────────────────────────────────────────────────────────────────────┘

    ┌───────────────────────┤ [!!] Partition disks ├───────────────────────┐
    │ │
    │ If you continue, the changes listed below will be written to the │
    │ disks. Otherwise, you will be able to make further changes manually. │
    │ │
    │ The partition tables of the following devices are changed: │
    │ LVM VG rootvg, LV homelv │
    │ LVM VG rootvg, LV rootlv │
    │ │
    │ The following partitions are going to be formatted: │
    │ LVM VG rootvg, LV homelv as ext4 │
    │ LVM VG rootvg, LV rootlv as ext4 │
    │ │
    │ Write the changes to disks? │
    │ │
    │ <Yes> ...

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-04-11 03:41 EDT-------
IBM bugzilla closed -> Verifed by Canonical