wie ich talos die falsche disk formatieren liess

2026-06-14

kurze notiz an mein zukünftiges ich, damit ich denselben fehler nicht zweimal mache.

was ich wollte

frischer single node talos cluster, public homelab. zweite nvme als lokaler storage für die apps, home assistant zuerst. plan: talos formatiert die zweite platte, mountet sie nach /var/mnt/storage, local-path-provisioner verteilt davon pvcs. ein topf patch, fertig.

machine:
  disks:
    - device: /dev/nvme1n1
      partitions:
        - mountpoint: /var/mnt/storage

was ich kaputt gemacht habe

/dev/nvme1n1 war nicht die leere platte. es war die system disk von talos. die gerätenamen waren gegenüber dem installationszeitpunkt vertauscht, nvme0n1 und nvme1n1 hatten die rollen getauscht. ich habe talos also gesagt, es soll seine eigene os platte neu partitionieren.

talos hat brav versucht, die bestehende efi partition als xfs zu formatieren:

22:40:04  formatting filesystem device=/dev/nvme1n1p1 filesystem=xfs
22:40:04  error formatting XFS: size 256 of data subvolume is too small,
          minimum 4096 blocks

256 blocks. das war die efi partition, rund ein megabyte. mkfs.xfs verweigert das zu recht. der volume controller geht in eine endlosschleife, alle 30 sekunden derselbe versuch. das blockiert die userDisks phase im boot, dadurch wird /var nicht sauber durchgereicht, dadurch bleibt /etc/kubernetes read only:

22:40:06  KubeletServiceController failed: error writing kubelet PKI:
          open /etc/kubernetes/bootstrap-kubeconfig: read-only file system
22:40:22  NodeApplyController failed: timeout

kubelet startet nicht, etcd startet nicht, node bleibt für immer in stage booting. ein reboot hilft nicht, weil talos die persistierte config wieder lädt und denselben tanz nochmal beginnt. um 23:03 in den logs dieselbe schleife, jetzt mit filesystem type mismatch: vfat != xfs, weil p1 eben eine vfat efi partition ist.

wie ich es gefixt habe

erst den schaden stoppen: den disk patch entfernen und die config neu pushen, damit talos die kaputte volume definition vergisst und der boot durchläuft.

dann die lektion: nie eine platte über den gerätenamen ansprechen. namen sind nicht stabil über reboots. talos kann disks per selector wählen, und es kennt die system disk:

talosctl -n <ip> get disks

erst die wirklich leere platte über seriennummer oder grösse identifizieren, dann ein UserVolumeConfig mit einem diskSelector der explizit !system_disk sagt. so kann der patch die os platte gar nicht mehr treffen, egal wie die kernel enumeration gerade gelaunt ist.

merksatz: device: /dev/nvme1n1 ist eine wette darauf, dass der kernel heute gleich zählt wie gestern. die wette verliert man irgendwann, und zwar immer dann, wenn produktivdaten drauf wären.