grow-var: resolve the whole disk with lsblk -d; refuse anything else

[mobileoverlord]

lsblk -no PKNAME <partition> also lists the partition's holders, and for a dm slave the dm child's row comes first — its PKNAME is the partition itself. On an encrypted /var this resolved "disk" to /dev/nvme0n1p16 and sgdisk -e wrote a fresh GPT over the LUKS2 header (primary and secondary both destroyed; the mapping survived only because the key was already in the kernel). Observed on a Jetson Orin Nano on its first encrypted-/var boot (meta-avocado #310). Plaintext boards never hit it because there the var device is the partition and lsblk's first row is its own — but every encrypted-var target (imx93, qemu) is exposed.

Fix: lsblk -dno PKNAME, and refuse to run sgdisk unless the resolved device is TYPE=disk.

Verified on the board: fixed resolution gives /dev/nvme0n1 type=disk ptable=gpt; the old form gives nvme0n1p16 type=part.

[mobileoverlord]

Pushed one commit: release: r0 → r1.

The two fixes here are correct, but without a version move they would not have reached a device. The extension declares 0.1.0-r0, which is the exact NEVR already in 2026/next — a rebuild republishes the same version and a resolving device keeps whichever copy it has, i.e. the broken one.

That is not hypothetical. avocado-img-bootfiles did exactly this: the correct package was built, published, and sat in 2026/next unreachable because 0.0.0-r0.1 sorts below the stale 2026.20-r0.0. It cost a day of debugging an unbootable imx8mp-evk.

Why this PR matters more than it looks

Confirmed on hardware today (Avocado OS 2026.38, imx8mp-evk):

avocado-grow-var[3594]: /usr/bin/avocado-grow-var: line 119: blockdev: command not found
systemd[1]: avocado-grow-var.service: Main process exited, code=exited, status=127/n/a
systemd[1]: Failed to start Grow /var partition and btrfs filesystem.

blockdev(8) is not in the runtime image, so the service fails 127 on every boot. It is not fatal — the unit is WantedBy=multi-user.target, so /var is already mounted by then — but it fails on every boot of every dev image, and the published avocado-ext-dev-0.1.0-r0 still carries it. This PR has been open and unreviewed since 2026-08-26.

One design question for the reviewer

The distro now grows /var itself: avocado-var-grow in meta-avocado, installed to ${libexecdir}, WantedBy=initrd-root-fs.target and ordered Before=cryptsetup-var.service var.mount. It grows the partition in the initramfs, before the LUKS container is opened.

This extension ships its own vendored copy at /usr/bin/avocado-grow-var, WantedBy=multi-user.target — a post-boot grow of an already-mounted filesystem. On a board with both, the distro one has already done the work before this one runs.

Worth deciding whether the extension should carry this at all, or drop the overlay and defer to the distro. That vendored snapshot is precisely how a copy survived the upstream rewrite and kept failing after the component it duplicates had been redesigned. Out of scope for this PR — merging it stops the boot-time failure either way.

https://claude.ai/code/session_0126qmPTM1gce9r9CEh2vxbo

[mobileoverlord]

Corrected the version bump: 0.1.0-r0 → 0.2.0-r0, not a release bump.

A release bump would have been wrong here. The payload changed, not just its packaging — grow-var no longer shells out to blockdev(8) and resolves the whole disk differently. That is a new version of the thing being shipped, so r0 restarts for it the way it does for any new upstream version.

Amended in place (force-with-lease); the two fix commits are untouched.

Release path is already correct on this repo: main is at ci: use the next channel (#2), and the matrix publishes to 2026/next + 2024/next — the channels a 2026 project actually resolves. The workflow guards that the pushed tag equals the avocado.yaml version, so after merge the tag is 0.2.0.

https://claude.ai/code/session_0126qmPTM1gce9r9CEh2vxbo