ignition/butane and disk labels on OpenStack

[till]

Hey,

I am finally trying to update to butane and rebuild my configurations.

My environment: OpenStack
Flatcar: 3510.2.2

The butane itself is still pretty simple (there is more, but I have tested it in isolation):

variant: flatcar
version: 1.0.0
storage:
  filesystems:
    - path: /customer
      device: /dev/sdb
      format: ext4
      label: CUSTOMER
      wipe_filesystem: true
      with_mount_unit: true

A similar ignition configuration was working before as the order of devices was actually predictable on instance creation. So, I was able to use /dev/sdb to format and label the device on boot. After that, I mounted it predictably by its label every time I rebooted the VM.

From my testing so far, /dev/sdb happens to be the root volume now. Always. No matter how often I try. Consistently.

So this does no longer work. In a nutshell, I get dropped into shell since ignition fails.

I looked a bit into how this is working on OpenStack and I seem to be unable to match the device by anything on first boot. I looked at all the /dev/disk/by-* paths, but nothing exactly matches.

The only thing that could work maybe work is /dev/disk/by-id/:

lrwxrwxrwx.  1 root root   9 Jun  2 11:02 scsi-0QEMU_QEMU_HARDDISK_42b0eb4d-3b91-4b46-8 -> ../../sdb

The volume attached to the VM is 42b0eb4d-3b91-4b46-848c-b1bf95a4cd62. So it seems like the hard-disk is truncated. But I can't find much as to how I would truncate the ID exactly to always work.

The docs are somewhat opaque here and leave out this detail. And the above seems to be a somewhat obscure way to do the mounting though it seems that even the cloud controller relies on it. I was hoping I missed something obvious.

If not, then I guess that should be added to the docs as an example?

As I am walking through it all, I might send a PR for OpenStack related setup.

[pothos]

An issue would be the better way to track this. Can you share the resulting mount unit? I guess that it doesn't use the chosen label for mounting but /dev/sdb and this is unpredictable after reboot.

[pothos]

Honestly I think that even using /dev/sdb in the config is a bad idea if one of these disks could be the boot disk. The best solution would be to let Ignition choose a free disk. The mount unit should of course only refer to it by a stable name which is a bit hard to do in Butane but it could be done on best effort by using the (part)label when specified and if not specified, by generating one.

[till]

"my" generated unit is correct:

# /etc/systemd/system/customer.mount
# Generated by Butane
[Unit]
Requires=systemd-fsck@dev-disk-by\x2did-scsi\x2d0QEMU_QEMU_HARDDISK_844e0ced\x2d927f\x2d40a3\x2d8.service
After=systemd-fsck@dev-disk-by\x2did-scsi\x2d0QEMU_QEMU_HARDDISK_844e0ced\x2d927f\x2d40a3\x2d8.service

[Mount]
Where=/customer
What=/dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_844e0ced-927f-40a3-8
Type=ext4

[Install]
RequiredBy=local-fs.target

[till]

I don't know where that would be, but it seems like Butane is aware of the same UUID hack where the actual UUID is cut off.

[till]

It could be smarter/nicer to read by using the LABEL of course. (My disk is label'd)

[till]

@pothos still make an issue to convert to using labels when available?