krunkit: secondary "disk:" volume mounts on first boot but breaks ("Unexpected disk at mount point.") on every subsequent restart

Description

On a krunkit vmType profile, the secondary data disk (the one sized by disk: in colima.yaml, as opposed to rootDisk:) mounts correctly on the VM's first boot, but is silently left unmounted after any subsequent plain colima stop / colima start cycle — no config change, no delete/recreate needed. provision.dependency/00000007 (disk.sh) fails on that second boot with "Unexpected disk at mount point.", and a separate root-disk resize step (provision.system/00000006) also starts failing at the same time with resize2fs: Please run 'e2fsck -f ...' first, pointed at the very disk that disk.sh is trying (and failing) to mount. Both failures make cloud-final.service exit with status 1 (failed).

Net effect: container/model data (/var/lib/docker, /var/lib/containerd, /var/lib/ramalama, etc.) silently falls back onto the small rootDisk (default 20GiB) instead of the large disk: volume after the first restart, so the VM runs out of space almost immediately when pulling large images/models (e.g. colima model serve --runner ramalama <30B model> fails with "no space left on device").

Reproduced twice independently: once on a long-lived profile (krunkit, delete + recreate did not help), and once from scratch on a brand-new profile created solely to isolate this (krunkit-repro) — full commands and output below. The equivalent vz profile (default, macOS Virtualization.framework) mounts its secondary disk correctly on every boot and has no such issue.

I checked main at HEAD (past the v0.10.3 tag): neither environment/vm/lima/disk.sh nor environment/vm/lima/yaml.go (which owns the resize2fs/growpart root-disk logic) has any commits since v0.10.3, so this is still present on current main, not just the released version.

Likely related to #1570/#1571 (fixed the "already mounted" detection in disk.sh using findmnt, present in my version) — but a different branch of the same script (the second findmnt --target guard, "Unexpected disk at mount point.") is the one failing here. Also very likely the underlying cause of #1583 ("krunkit vm data lost on restart"), which reports the same "works once, breaks on restart" pattern.

Separately, note for maintainers: while reproducing this on a fresh profile I also hit #1607 (mountType must be virtiofs or reverse-sshfs, got 9p) on plain colima start -p <profile> --vm-type krunkit. That one is already fixed on main (#1609, merged after v0.10.3) but not yet in a tagged release — mentioning it only so it isn't confused with this report; I worked around it with --mount-type sshfs to get to the actual repro below.

Version

colima version 0.10.3
git commit: 00f6c297e92a82c04a4ab507db0a61435650d7e8

runtime: docker
arch: aarch64
client: v28.5.1
server: v29.5.2
limactl version 2.2.0
qemu-img version 11.0.3

krunkit 1.2.2

Operating System

• macOS Intel <= 13 (Ventura)
• macOS Intel >= 14 (Sonoma)
• Apple Silicon >= 14 (Sonoma) — macOS 26.6 (25G72)
• Linux

Reproduction Steps (clean, isolated profile)

$ colima start -p krunkit-repro --vm-type krunkit --disk 40
...
level=error msg="Failed to set config" error="rpc error: code = Unknown desc = field `mountType` must be `virtiofs` or `reverse-sshfs` for krunkit driver, got `9p`"

(→ this is #1607, fixed on main via #1609 but not yet released; worked around below.)

$ colima delete -p krunkit-repro -y
$ colima start -p krunkit-repro --vm-type krunkit --mount-type sshfs --disk 40
... (starts fine)

First boot — disk mounts correctly:

$ colima ssh -p krunkit-repro -- lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     253:0    0   20G  0 disk
├─vda1  253:1    0   19G  0 part /
├─vda15 253:15   0   99M  0 part /boot/efi
└─vda16 259:0    0  923M  0 part /boot
vdb     253:16   0   19M  0 disk /mnt/lima-cidata
vdc     253:32   0   40G  0 disk
└─vdc1  253:33   0   40G  0 part /var/lib/ramalama
                                 /var/lib/cni
                                 /var/lib/rancher
                                 /var/lib/containerd
                                 /var/lib/docker
                                 /mnt/lima-colima-krunkit-repro

$ colima ssh -p krunkit-repro -- systemctl is-active cloud-final.service
failed   # (this boot's failure was an unrelated transient DNS-not-ready issue during
         #  apt-get install rsync in boot.Linux/30-install-packages.sh — disk itself
         #  mounted fine, included for completeness)

Restart with zero config changes — disk comes back unmounted:

$ colima stop -p krunkit-repro
$ colima start -p krunkit-repro
$ colima ssh -p krunkit-repro -- lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     253:0    0   20G  0 disk
├─vda1  253:1    0   19G  0 part /var/lib/ramalama
│                                /var/lib/cni
│                                /var/lib/rancher
│                                /var/lib/containerd
│                                /var/lib/docker
│                                /
├─vda15 253:15   0   99M  0 part /boot/efi
└─vda16 259:0    0  923M  0 part /boot
vdb     253:16   0   19M  0 disk /mnt/lima-cidata
vdc     253:32   0 39.9G  0 disk
└─vdc1  253:33   0 39.9G  0 part          # <- no mountpoint anymore

$ colima ssh -p krunkit-repro -- systemctl is-active cloud-final.service
failed

Journal for that failing boot:

$ colima ssh -p krunkit-repro -- sudo journalctl -b -u cloud-final.service -o cat
...
+ [ -d /mnt/lima-cidata/provision.dependency ]
+ CODE=0
+ /mnt/lima-cidata/provision.dependency/00000001
+ /mnt/lima-cidata/provision.dependency/00000007
/dev/vdb         20M   20M     0 100% /mnt/lima-cidata
Unexpected disk at mount point.
+ CODE=1
+ /mnt/lima-cidata/provision.dependency/00000008
...
+ [ 1 != 0 ]
+ exit 1
LIMA ...| WARNING: Failed to execute /mnt/lima-cidata/boot.Linux/30-install-packages.sh
...
LIMA ...| Executing /mnt/lima-cidata/provision.system/00000006
resize2fs 1.47.0 (5-Feb-2023)
Please run 'e2fsck -f /dev/disk/by-label/lima-colima-krun' first.
LIMA ...| Exiting with code 1
...
cloud-final.service: Main process exited, code=exited, status=1/FAILURE
cloud-final.service: Failed with result 'exit-code'.
Failed to start cloud-final.service - Cloud-init: Final Stage.

blkid confirms /dev/disk/by-label/lima-colima-krun unambiguously resolves to /dev/vdc1 (the secondary disk; the root disk is separately labelled cloudimg-rootfs), so provision.system/00000006's resize2fs step is being run against the secondary disk, which apparently didn't get cleanly unmounted at colima stop and now needs e2fsck before it can be touched — which then aborts the whole provisioning chain with set -e-style propagation, so disk.sh's mount attempt right before it (00000007) never gets a clean run either.

$ colima ssh -p krunkit-repro -- sudo blkid
/dev/vdb: BLOCK_SIZE="2048" UUID="..." LABEL="cidata" TYPE="iso9660"
/dev/vdc1: LABEL="lima-colima-krun" UUID="..." BLOCK_SIZE="4096" TYPE="ext4"
/dev/vda15: LABEL_FATBOOT="UEFI" LABEL="UEFI" ...
/dev/vda1: LABEL="cloudimg-rootfs" UUID="..." BLOCK_SIZE="4096" TYPE="ext4" ...
/dev/vda16: LABEL="BOOT" UUID="..." ...

For comparison, the default profile (vmType: vz) on the same host mounts its equivalent disk fine on every boot:

$ colima ssh -p default -- df -h
...
/dev/vdb1              59G   36G   21G  64% /mnt/lima-colima
$ colima ssh -p default -- systemctl is-active cloud-final.service
active

Expected behaviour

• disk.sh mounts the secondary disk on every boot on krunkit, not just the first.
• The root-disk resize step (provision.system/00000006) never targets the secondary disk.
• cloud-final.service completes successfully (active) after a normal stop/start, not failed.
• Container/model data stays backed by the large disk: volume rather than silently falling back to the small rootDisk after a restart.

Workaround

Bumping rootDisk instead of relying on disk: works around the space problem (though cloud-final.service still ends up failed for the reasons above):

colima stop -p krunkit
colima start -p krunkit --root-disk 100

vda1 grows in place via colima's own growpart/resize2fs and everything under /var/lib gets the extra space, independent of the broken second-disk mount.

Additional context

• Confirmed present on current main (past v0.10.3): no commits to environment/vm/lima/disk.sh or environment/vm/lima/yaml.go since the v0.10.3 tag.
• Ruled out the fstrim/discard bug in #1549 (provision.system/00000005) as the cause here — manually re-running that script inside the VM exits 0 cleanly on this image.
• Ruled out ext4 16-char label truncation/collision between root and secondary disk as the cause — blkid shows distinct labels (cloudimg-rootfs vs lima-colima-krun).
• Happy to provide the full raw journalctl -b -u cloud-final.service output (trimmed above for brevity) or run further diagnostics.