`boot_device` sugar is not supported on s390x

[Benjamin Gilbert]

If boot_device.mirror is specified, Butane emits Ignition directives to repartition the entire boot disk(s), create RAID volumes, and create filesystems inside them. During first boot, the OS copies the entire OS contents into memory, does the repartitioning, and copies the contents back to disk. The partition tables created by Butane are hardcoded to match what the OS expects, which is slightly different for each architecture, and so Butane needs to know the CPU architecture via the boot_device.layout field (which defaults to x86_64).

If boot_device.luks is specified, Butane doesn't need to emit directives for repartitioning the entire disk, but it does need to locate the existing root partition so it can create a LUKS volume in it and a new filesystem inside that. (At runtime, the OS still does the copy to RAM and copy back to disk.) To do this, it references the partition by partition label (/dev/disk/by-partlabel/root) so that it doesn't need to know the number of the root partition. Since we're not repartitioning the disk, the layout directive is technically not required when only using boot_device.luks.

If both mirror and luks are specified, Butane does a combination of both.

That all works fine for x86_64, aarch64, and ppc64le, since they all use GPT partition tables. But s390x uses different partition table formats depending on the type of disk. On FBA DASD disks, it uses MBR partition tables, which Ignition doesn't know how to create, and which don't have partition labels. On ECKD DASD disks, it uses the DASD native partitioning format, which Ignition doesn't know how to create and which don't have partition labels (and which only support 3 partitions per disk).

So we could technically have three different layout values, e.g.:

• s390x-virt - works like the other arches
• s390x-fba - doesn't support mirror, supports luks by hardcoding a partition number (which requires a field for specifying the boot disk, e.g. /dev/sda)
• s390x-eckd - same constraints as fba but with different hardcoded constants

but that would be confusing.

Ignition and the OS copy-to-RAM/copy-to-disk code should work fine on s390x, it's just that the Butane sugar doesn't know how to configure them. For now, all users on s390x should bypass the boot_device sugar and manually configure LUKS and/or mirroring using the low-level directives, similar to how an encrypted/mirrored data volume would be configured. Do not use boot_device with the default x86_64 layout on s390x, even in VMs where it appears to work, since the x86_64 layout is not guaranteed to remain compatible with the needs of s390x.

On VMs using GPT partition tables this might look like:

variant: fcos
version: 1.5.0
storage:
  luks:
    - name: root
      label: luks-root
      device: /dev/disk/by-partlabel/root
      wipe_volume: true
      clevis:
        tang:
          - url: http://example.com/
            thumbprint: ...
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      label: root
      wipe_filesystem: true

/dev/disk/by-partlabel/root will only work in VMs using GPT partition tables. Other values will need to be used on DASD disks.