Autoinstall can not match disks

Support and Help
, , ,
1

Ubuntu Support Template

Ubuntu Version:
24.04

Problem Description:
I am writing an autoinstall file for provisioning a bare-metal Ubuntu machine. I am having trouble with provisioining the raid-1. The raid-1 is provisioned on the two nvmes with the smallest space. I am trying to find the smallest nvmes in the early-commands section and then use them in the “storage” section in the autonistall file. I am placing the absolute path of these nvmes in an environment variable and trying to use them in the storage section. This is not taking affect and the error shown in the attached picture

Screenshot from 2025-12-29 15-36-43
Screenshot from 2025-12-29 15-36-431342×270 105 KB

This is the sample code:

 early-commands:
    - |
        set -eux

        # Get all physical disks, sort by size, pick the two smallest
        lsblk -dn -o NAME,SIZE,TYPE \
          | awk '$3=="disk"{print $1, $2}' \
          | sort -h -k2 \
          | head -n 2 \
          | awk '{print "/dev/"$1}' \
          | tee /run/os-disks

        DISK0=$(sed -n '1p' /run/os-disks)
        DISK1=$(sed -n '2p' /run/os-disks)

        echo "Selected OS disks:"
        echo "$DISK0"
        echo "$DISK1"

        echo "$DISK0" > /run/disk0-name
        echo "$DISK1" > /run/disk1-name
        # Create stable symlinks for curtin
        ln -sf "$DISK0" /run/disk0
        ln -sf "$DISK1" /run/disk1     

  #
  # ---- CRITICAL FOR PROXMOX / UEFI ----
  #
#  grub:
#    install_devices: []
#    reorder_uefi: false

  storage:
    swap:
      size: 0

    config:
      #
      # ---- DISKS ----
      #
      - type: disk
        id: disk0
        match:
          path: /run/disk0
        ptable: gpt
        wipe: superblock-recursive
        preserve: false

    type: disk id: disk1 match: path: /run/disk1 ptable: gpt wipe: superblock-recursive preserve: false # # ---- EFI SYSTEM PARTITIONS (NOT RAID) ---- #

    type: partition
    id: disk0-efi
    device: disk0
    size: 1G
    flag: esp
    grub_device: true

    type: partition
    id: disk1-efi
    device: disk1
    size: 1G
    flag: esp
    grub_device: true
2

Welcome to the community :slightly_smiling_face:

I don’t have long or deep hands-on experience with complex autoinstall RAID setups, so please take this as guidance rather than a definitive solution.

From what I understand, curtin does not expand environment variables or follow runtime symlinks created in early-commands when evaluating the storage.match section. The match.path is resolved very early and must refer to something stable that exists at install time (for example /dev/disk/by-id/*), not files or symlinks under /run.

You may want to try one of these approaches instead:

  • Use match: { size: smallest } or match: { ssd: true } if it fits your use case.
  • Match disks via /dev/disk/by-id/ or /dev/disk/by-path/ which curtin handles reliably.
  • Predefine disk selection logic using match rules only, without relying on early-commands variables.

Hopefully someone with deeper curtin/autoinstall experience can confirm the best pattern here, but this limitation is a common gotcha with autoinstall storage matching.

3

thanks for your response.
I have used these ones too, but does not take affect. any other suggestions on how to dynamically choose the two smallest disks?
for more info, my testbed is two vms (proxmox as the hypervisor)which one is the pxe server with autoinstall on it, and the other one is the candidate client which have three disks; two of them 10 G and one 15 G and when the early commands run; it shows sda and sdc as the two 10 G disks and sdb as the 15 G disk.

the below picture is the result of the

match: { size: smallest } and match: { size: second-smallest }

Screenshot from 2025-12-30 14-26-02
Screenshot from 2025-12-30 14-26-02668×270 47.3 KB

4

Thanks for the extra details. I did a bit more digging into this, and here’s what I found.

This looks like a limitation in curtin’s disk matching, not an issue with your logic.
match: { size: smallest } / second-smallest are evaluated globally and are not deterministic, especially once partitioning and RAID start. Curtin also doesn’t reliably expand variables or follow runtime symlinks created in early-commands.

For now, you may want to try one of these as a workaround:

  • Match disks explicitly using /dev/disk/by-id/ or /dev/disk/by-path/
  • Further constrain matching (e.g. combine ssd: true with size), though this isn’t guaranteed
  • Control disk order/sizing at the Proxmox level for predictable results

You can try this approach for now, at least until someone with deeper autoinstall/curtin experience can confirm a better pattern.

Hope this helps in the meantime :slightly_smiling_face:

1 Like