ubuntu jammy 22.04 iso is missing the dm-multipath.ko file

[Rui Lopes]

The dm-multipath.ko file is missing from https://releases.ubuntu.com/22.04/ubuntu-22.04-live-server-amd64.iso.

For reference, these are the found dm- files:

root@pxe:~# find /lib/modules/5.15.0-25-generic/kernel/drivers/ -type f | grep dm-
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-bio-prison.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-bufio.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-cache-smq.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-cache.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-crypt.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-log.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-mirror.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-raid.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-region-hash.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-snapshot.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/dm-thin-pool.ko
/lib/modules/5.15.0-25-generic/kernel/drivers/md/persistent-data/dm-persistent-data.ko

The need for dm-multipath.ko is triggered by the "wipe: superblock-recursive" section from this autoinstall snippet:

autoinstall:
  storage:
    config:
      - id: disk-boot
        type: disk
        wipe: superblock-recursive
        ptable: msdos
        path: /dev/sda
        grub_device: true
...

Something like this also happened with the 20.04 iso as described in https://bugs.launchpad.net/ubuntu-cdimage/+bug/1898045

[Steve Langasek (vorlon)]

I cannot reproduce this. dm-multipath.ko is present in both the squashfs and the initramfs on the release ISO, and booting it shows the file under /lib/modules as expected.

[Steve Langasek (vorlon)]

> The need for dm-multipath.ko is triggered by the
> "wipe: superblock-recursive" section from this autoinstall snippet:

Also opening a subiquity task because of this. While I can't reproduce the original issue, I don't see any reason that wiping the disk should result in a dependency on multipathd, which should be invoked IFF a multipath topology is detected.

[Rui Lopes (rgl)]

Something really odd is going on. When I directly boot from the iso in a VM, the .ko file is there. But when I PXE Boot it, its not. Even thou both boots mount the same squashfs files, they end up with different content.

I'm probably doing something wrong with the PXE boot setup (although it works fine with ubuntu 20.04). Here's my iPXE script:

      #!ipxe
      set base http://${proxydhcp/next-server}/artifacts
      set config ${base}/ubuntu-jammy/config/${netX/mac}
      set artifacts ${base}/ubuntu-jammy/{{ .Machine.Arch }}/live-server
      set iso ${artifacts}.iso
      set casper ${artifacts}/casper
      initrd ${casper}/initrd
      chain --autofree --replace \
        ${casper}/vmlinuz \
        initrd=initrd.magic \
        autoinstall \
        ip=dhcp \
        url=${iso} \
        ds=nocloud-net;s=${config}/ \
        cloud-config-url=/dev/null \
        hostname=pxe \
        domain=test \
        net.ifnames=0 \
        BOOT_DEBUG=2 \
        DEBCONF_DEBUG=5 \
        ignore_uuid

Here's what the install live environment kernel command line ends up looking like (I've splitted the arguments into different lines to make them easier to read):

root@pxe:~# cat /proc/cmdline
vmlinuz
initrd=initrd.magic
autoinstall
ip=dhcp
url=http://192.168.1.1/artifacts/ubuntu-jammy/amd64/live-server.iso
ds=nocloud-net;s=http://192.168.1.1/artifacts/ubuntu-jammy/config/ec:b1:d7:71:ff:f3/
cloud-config-url=/dev/null
hostname=pxe
domain=test
net.ifnames=0
BOOT_DEBUG=2
DEBCONF_DEBUG=5
ignore_uuid

So, I'm kinda lost in troubleshooting this and need your help :-)

[Rui Lopes (rgl)]

My local setup was fubar; somehow it ended up using an older iso. I deleted everything and started from scratch, and now this works as expected (dm-multipath.ko is found and loaded).

Sorry for wasting your time :-(

[Steve Langasek (vorlon)]

Thanks for following up. I think the subiquity task is still valid, though low-priority.

[Michael Hudson-Doyle (mwhudson)]

I'm not sure which part of subiquity / curtin would require multipath to be present if there is no multipath disk detected. It looks like curtin might try to run "multipath -r" in some situations. Hard to debug further without a traceback.