Boot-disk repartition for in-field EVE-kvm ↔ EVE-k conversion

[eriknordmark]

Boot-disk repartition for in-field EVE-kvm ↔ EVE-k conversion

Long-lived devices installed with EVE's old small boot-disk layout (IMGA/IMGB
as small as 300 MB, a small ESP) cannot hold the EVE-k (Kubernetes) rootfs and
its container/k3s tooling. Upgrading replaces rootfs contents but never
repartitions, so the small geometry persists. This branch repartitions the boot
disk in place to the larger EVE-k geometry at the moment the controller pushes a
cross-flavor base-OS update — growing ESP/IMGA/IMGB, and first shrinking the
/persist filesystem when that's the only way to free the space — so an
in-field device can be converted to EVE-k without re-imaging and without losing
/persist data or device identity.

A read-only pre-flight classifies the disk into proceed / grow / shrink /
insufficient. grow happens online; shrink backs up the device identity to
the CONFIG partition and reboots into an offline shrink+grow under storage-init;
insufficient declines the conversion cleanly and the device stays on its
current flavor. The design is idempotent and fail-safe: no failure mode bricks
the device, and even a power loss mid-shrink recovers to a bootable, remotely
manageable state.

Interrupting the shrink also does not corrupt data on the filesystem being
resized: resize2fs flushes each relocated extent before repointing any inode at
the new location, and the smaller size commits only at the very end, so a reset
resumes from the old geometry with every file addressing either its untouched
original or a complete copy. Fault injection bears this out — 36 conversions with
193 watchdog resets landing inside the shrink, no corrupted app volume and no
structural fsck finding. It holds as far as the storage stack honors the flush;
buffering in the kernel and in the storage controller means a flush may be
acknowledged before the bytes reach the medium, which QEMU-based testing cannot
exercise, so the identity files are additionally verified by digest.

See docs/STORAGE-RESIZING.md for the full design.

What's here

• pkg/storage-resizer — standalone Go binary doing all the disk work
  (check/backup/shrink/grow/restore/cleanup) via diskfs/partitionresizer, kept
  out of the pillar module.
• storage-init — runs the offline shrink/grow and post-mount
  restore/cleanup, re-syncing /config so PCR14 stays stable.
• pkg/pillar/diskconvert — pillar orchestration that execs the resizer and
  selects the next step; unit-tested behind a fake Runner.
• baseosmgr / nodeagent / zedagent — drive the conversion at the cross-flavor
  seam, reboot into the offline shrink when needed, and report
  ZDEVICE_STATE_CONVERTING with a sub-state.
• volumemgr / upgradeconverter — recognize blobs already on /persist across
  the kvm→k namespace change so pre-staged content isn't re-downloaded; gate the
  cross-flavor block on the actual volume set.

In-flight items before merge

• The repartition and refused legs of the test plan now pass end to end — seven
  topologies (ext4 shrink/grow, two-disk ext4, two-disk ZFS, ZFS grow, and the two
  refusal cases), 7/7. The power-loss recovery cases are now covered by watchdog fault injection
  on an integration branch carrying this stack. Still outstanding: bare-metal power
  loss (see above), arm64, and a run on this branch alone rather than the
  integration branch.
• We should probably convert these eden tests to evetest but that can be done in a separate PR.

How to test and validate this PR

• Unit: pkg/pillar/diskconvert orchestration tests (fake Runner) and the
  pkg/storage-resizer check/shrink/grow logic.
• E2E under eden + swtpm on a device installed with the old small boot-disk
  geometry: push a cross-flavor (EVE-kvm→EVE-k) base-OS update and confirm
  each pre-flight class behaves correctly — grow (online), shrink
  (offline shrink+grow under storage-init, identity backed up to CONFIG and
  restored), and insufficient (conversion declined cleanly, device stays on
  its current flavor). Confirm /persist data and device identity survive,
  and that a power loss mid-shrink recovers to a bootable, remotely
  manageable state.

Changelog notes

Adds in-field boot-disk repartitioning so a device installed with EVE's old
small boot-disk layout can be converted between EVE-kvm and EVE-k on a
cross-flavor base-OS update, without re-imaging and without losing /persist
data or device identity. Requires that there are no app instances or volume instances
on the device.

PR Backports

• 17.0-stable: No.
• 16.0-stable: No.
• 14.5-stable: No.
• 13.4-stable: No.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR

And the last but not least:

• I've checked the boxes above, or I've provided a good reason why I didn't
  check them.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 27.03488% with 502 lines in your changes missing coverage. Please review.
✅ Project coverage is 25.23%. Comparing base (aadcfa9) to head (b25f0c5).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/pillar/cmd/baseosmgr/convert.go	22.59%	137 Missing ⚠️
pkg/pillar/vault/handler_zfs.go	1.50%	131 Missing ⚠️
pkg/pillar/cmd/baseosmgr/baseosmgr.go	0.00%	58 Missing and 1 partial ⚠️
pkg/pillar/diskconvert/convert.go	46.66%	48 Missing ⚠️
...illar/cmd/upgradeconverter/containerd_namespace.go	71.68%	20 Missing and 12 partials ⚠️
pkg/pillar/cmd/baseosmgr/handlebaseos.go	0.00%	18 Missing ⚠️
pkg/pillar/cmd/nodeagent/handlebaseos.go	0.00%	18 Missing ⚠️
pkg/pillar/cmd/nodeagent/nodeagent.go	0.00%	18 Missing ⚠️
pkg/pillar/cmd/zedagent/reportinfo.go	0.00%	13 Missing ⚠️
pkg/pillar/zfs/zfs.go	0.00%	13 Missing ⚠️
... and 3 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6063      +/-   ##
==========================================
+ Coverage   24.87%   25.23%   +0.35%     
==========================================
  Files         506      519      +13     
  Lines       93177    95575    +2398     
==========================================
+ Hits        23181    24114     +933     
- Misses      68178    69444    +1266     
- Partials     1818     2017     +199     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[eriknordmark]

The yetus -1 on this PR is a structural consequence of adding a new Go module (pkg/storage-resizer), not a problem in the diff.

yetus — the -1 on golangcilint is a false positive. Yetus scores that subsystem by diffing the line count of golangci-lint's per-module output. master produces 503 lines, this branch 504, and the one extra line is:

pkg/storage-resizer/0 issues.

That is the new module reporting zero problems, counted as "1 new issue". In the yetus-scan artifact, results-codespell.txt, results-markdownlint.txt and results-revive.txt are empty, and results-golangcilint.txt contains only the line above. The four real findings from the earlier run (codespell unparseable, two MD040 fenced blocks, revive's builtin-shadowing clear plus the missing const-block comment, and four unchecked fmt.Fprint*) are all fixed. Since the extra line is inherent to the module existing, this vote is expected to recur.

scan-pr / osv-scan — resolved, and worth recording why. osv-scanner reads the go directive as the stdlib version, and a brand-new go.mod has no baseline to diff against, so at go 1.25.7 every stdlib CVE fixed after 1.25.7 was reported as new and failed the job. Declaring go 1.25.12 — matching pkg/kube/kube-init and the Go shipped in lfedge/eve-alpine — aligns the new module with a version already present in master, and the job now reports Total 0 packages affected by 0 known vulnerabilities. Its annotation still lists seven stdlib advisories fixed in 1.25.13 (GO-2026-5026, -5972, -6088, -6089, -6090, -6091, -6218), but those are shared with the modules already on 1.25.12 and do not fail the check. Going to 1.25.13 is not possible here regardless: the build image ships Go 1.25.12 and build.yml sets network: no, so a higher directive cannot download a toolchain. The vendored klauspost/compress finding from the earlier run is also fixed (1.18.6 → 1.18.7).

One project-wide change worth a reviewer's attention: the non-k ROOTFS_MAXSIZE_MB check moves from 290 to 291 MB. The statically linked resizer adds ~1.5 MB to the non-k squashfs rootfs, which put it ~164 KiB over 290; master itself sits at ~288.7 MB, so there was only ~1.3 MB of headroom. The compatibility constraint being guarded is the 300 MB pre-10.2.0 rootfs partition, which 291 still clears by 9 MB. Rationale is in the storage-init,pillar: run storage-resizer during the offline resize commit message.