subiquity crashes when attempting advanced network/disk configuration

[Todd Taft]

Subiquity for 20.04 crashes and a system install attempt fails when attempting to do an install with a complex network or disk configuration.

When attempting an install with a semi-complex configuration (e.g. multiple network interfaces bonded together using LACP or multiple partitions with LVM, tmpfs, and swap), the installer will crash and fail.

I am attempting an automated install using ISOs generated by the scripts at https://github.com/covertsh/ubuntu-autoinstall-generator and I am attempting to use the daily Ubuntu ISOs downloaded by that script. The user-data file that is attached fails with the current Ubuntu ISO download; however, it works with a daily ISO download that I made on 2021-12-03, so it appears that something broke on or after that date.

[Michael Hudson-Doyle (mwhudson)]

So the (admittedly very obscure) error is that we don't know what to make of this device:

 P: /devices/virtual/block/dm-8
 N: dm-8
 L: 0
 S: mapper/ventoy
 E: DEVPATH=/devices/virtual/block/dm-8
 E: SUBSYSTEM=block
 E: DEVNAME=/dev/dm-8
 E: DEVTYPE=disk
 E: MAJOR=253
 E: MINOR=8
 E: USEC_INITIALIZED=6700470
 E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
 E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
 E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
 E: DM_UDEV_RULES=1
 E: DM_UDEV_RULES_VSN=2
 E: DM_NAME=ventoy
 E: DM_SUSPENDED=0
 E: DEVLINKS=/dev/mapper/ventoy
 E: TAGS=:systemd:

What is it? I can't tell from this fragment! (Not really sure how you get a device-mapper device without a DM_UUID entry in udev but maybe I'm misunderstanding something)

[Todd Taft (taft)]

The major number would suggest that it's a logical volume, but it doesn't seem to correspond to a logical volume, so I'm not sure what it is:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 377.4M 1 loop /media/filesystem
loop1 7:1 0 221.8M 1 loop
loop2 7:2 0 82.1M 1 loop /usr/lib/modules
loop3 7:3 0 61.9M 1 loop /snap/core20/1270
loop4 7:4 0 42.2M 1 loop /snap/snapd/14066
loop5 7:5 0 67.2M 1 loop /snap/lxd/21835
loop6 7:6 0 24.3M 1 loop /snap/subiquity/2974
sda 8:0 1 119.5G 0 disk
├─sda1 8:1 1 119.5G 0 part
│ └─ventoy 253:8 0 1.2G 1 dm /cdrom
└─sda2 8:2 1 32M 0 part
sr0 11:0 1 1024M 0 rom
nvme0n1 259:0 0 953.9G 0 disk
├─nvme0n1p1 259:4 0 260M 0 part
├─nvme0n1p2 259:6 0 16M 0 part
├─nvme0n1p3 259:7 0 952.6G 0 part
└─nvme0n1p4 259:8 0 995M 0 part
nvme1n1 259:1 0 953.9G 0 disk
├─nvme1n1p1 259:2 0 512M 0 part
├─nvme1n1p2 259:3 0 1G 0 part
└─nvme1n1p3 259:5 0 952.4G 0 part
  ├─kangaroovg-rootlv 253:0 0 5G 0 lvm
  ├─kangaroovg-usrlv 253:1 0 20G 0 lvm
  ├─kangaroovg-varlv 253:2 0 5G 0 lvm
  ├─kangaroovg-varliblv 253:3 0 7G 0 lvm
  ├─kangaroovg-homelv 253:4 0 100G 0 lvm
  ├─kangaroovg-srvlv 253:5 0 5G 0 lvm
  ├─kangaroovg-usrlocallv 253:6 0 5G 0 lvm
  └─kangaroovg-swaplv 253:7 0 8G 0 lvm
# ls -l /dev/dm*
brw-rw---- 1 root disk 253, 0 Dec 16 03:20 /dev/dm-0
brw-rw---- 1 root disk 253, 1 Dec 16 03:20 /dev/dm-1
brw-rw---- 1 root disk 253, 2 Dec 16 03:20 /dev/dm-2
brw-rw---- 1 root disk 253, 3 Dec 16 03:20 /dev/dm-3
brw-rw---- 1 root disk 253, 4 Dec 16 03:20 /dev/dm-4
brw-rw---- 1 root disk 253, 5 Dec 16 03:20 /dev/dm-5
brw-rw---- 1 root disk 253, 6 Dec 16 03:20 /dev/dm-6
brw-rw---- 1 root disk 253, 7 Dec 16 03:20 /dev/dm-7
brw-rw---- 1 root disk 253, 8 Dec 16 03:20 /dev/dm-8

/dev/dma_heap:
total 0
crw------- 1 root root 249, 0 Dec 16 03:20 system
# lvscan
  ACTIVE '/dev/kangaroovg/rootlv' [5.00 GiB] inherit
  ACTIVE '/dev/kangaroovg/usrlv' [20.00 GiB] inherit
  ACTIVE '/dev/kangaroovg/varlv' [5.00 GiB] inherit
  ACTIVE '/dev/kangaroovg/varliblv' [7.00 GiB] inherit
  ACTIVE '/dev/kangaroovg/homelv' [100.00 GiB] inherit
  ACTIVE '/dev/kangaroovg/srvlv' [5.00 GiB] inherit
  ACTIVE '/dev/kangaroovg/usrlocallv' [5.00 GiB] inherit
  ACTIVE '/dev/kangaroovg/swaplv' [8.00 GiB] inherit
# vgscan
  Found volume group "kangaroovg" using metadata type lvm2
# ls -l /dev/kangaroovg
total 0
lrwxrwxrwx 1 root root 7 Dec 16 08:58 homelv -> ../dm-4
lrwxrwxrwx 1 root root 7 Dec 16 08:58 rootlv -> ../dm-0
lrwxrwxrwx 1 root root 7 Dec 16 08:...

[Brandon McKean (mckeanbs)]

We encountered this on a server build on 22.04, though admittedly a daily image before the final was created.

While we didn't save the log, we encountered the same sort of behavior you did. Going off of Michael's comment and reading the logs, it looks like Todd was using Ventoy, which we were also using as well as complicated networking and partitioning.

For reference, Ventoy is software to run bootable iso files from a drive rather than needing to directly writing them to said drive.

When we did the installation with the final iso directly written to a flash drive, and did the same installation procedure, everything worked perfectly.

I think this error is due to something Ventoy is doing that the installer doesn't like. Whether or not that is something that is considered Ubuntu's fault, I'm not sure.