[aervin]

Why

The appliance boots with ten identical 10 GB data disks, and some E2E journeys need a disk those cannot give.

• Boot Pool Status cannot detach a disk from a mirrored boot pool truenas/webui#14710. Boot Pool Status cannot detach a disk from a mirrored boot pool. It cannot be reproduced in CI, because the boot pool cannot be mirrored there: boot.attach needs a disk at least as large as the boot disk. The boot partition alone is about 15.5 GB, so every 10 GB disk is refused, and both mirror tests in e2e/tests/boot-pool.e2e.ts skip on every run.
• Add E2E coverage for the pool wizard's disk-size buckets, "Treat Disk Size as Minimum" and mixed-size warnings truenas/webui#14498, later: the pool wizard's disk-size buckets and its mixed-size warnings need unused disks of a second size.

Change

• New input extra-disk-gb. More sparse qcow2 disks after the data disks, one per size in GB, separated by spaces. '32' adds one 32 GB disk, and '12 12 15' adds three. The default is none, so nothing changes for existing callers.
• The extra disks come after the data disks, with serials extra1, extra2, and so on. A suite that takes the first unused disks, or disks of one size, still gets the 10 GB data disks.
• A value that is not a whole number fails the start with a message. ha: true with extra-disk-gb set fails with an error, rather than ha.sh silently ignoring it.
• The boot line names them, for example 10 data disks of 10G, and 1 more of 32G.
• The README's input table lists the new input.

The webui side is truenas/webui on branch ccr-76be8ba4-0fmqnb. It passes extra-disk-gb: '32' and picks a disk at least as large as the boot disk to mirror onto. That PR can merge before or after this one: until this merges, GitHub only warns about the unknown input and the test keeps skipping.

As the action's header says, a change in this directory is also a new appliance image in github-truenas-runner, whose build fetches these scripts.

Testing

• shellcheck -x appliance.sh lib.sh (run from the action's directory) and actionlint are clean. node scripts/check-input-refs.js reports that all input references resolve.
• I ran the parsing and the boot message on their own for '', '32', '12 12 15', an all-space value and '1x'. They give 0, 1, 3, 0 and a refusal, respectively.
• I have not booted an appliance with it. The first E2E run of the webui branch after this merges is that test. Its log line reads booting … 10 data disks of 10G, and 1 more of 32G, and boot-pool.e2e.ts's mirror test runs instead of skipping.

https://claude.ai/code/session_01KFP9uqyWUd8tys9JnmPjn4

---

Generated by Claude Code

[github-actions]

No findings. No human review required.

What I checked:

• Existing callers. extra-disk-gb defaults to ''. read -r -a on an empty string gives an empty array, so both loops do nothing and extrasaid stays empty. Without the input, the disks and the boot line are byte-for-byte what they were.
• Validation happens before anything is changed. The ^[1-9][0-9]*$ check runs after the running guard and before rm -rf "$DIR" and qemu-img create. A bad value like 1x, 0 or -5 makes die stop the start without touching an existing directory. Under set -u, expanding an empty "${extragb[@]}" is safe on the runners' bash 5.
• HA. The new guard in action.yml reads $HA, which the step's env: sets from inputs.ha. It fails with an ::error:: rather than letting ha.sh silently drop the disks. That is a failure, not a skip, which is the right side to err on.
• Disk order and serials. The extraN disks are attached after the dataN disks, with their own serials and drive ids. They don't collide with os or dataN, and nothing else in the action counts disks.
• Docs. The README input table, the action.yml description and the appliance.sh header all describe the new input, and they agree with each other.

The failing check-ticket check is about the PR metadata, not this code.

[github-actions]

Approved. No findings.

Nothing blocks and no human review is needed.

[bugclerk]

Jira URL: https://ixsystems.atlassian.net/browse/NAS-144815

[bugclerk]

This PR has been merged and conversations have been locked.
If you would like to discuss more about this issue please use our forums or raise a Jira ticket.