Skip to content

Refactor VM script settings and fix load_functions errors - #13

Merged
MickLesk merged 2 commits into
mainfrom
feat/vm-core-settings-helpers
Aug 31, 2026
Merged

Refactor VM script settings and fix load_functions errors#13
MickLesk merged 2 commits into
mainfrom
feat/vm-core-settings-helpers

Conversation

@MickLesk

Copy link
Copy Markdown
Member

✍️ Description

Refactor VM script settings and fix load_functions errors

🔗 Related Issue

Fixes #

✅ Prerequisites (X in brackets)

  • Self-review completed – Code follows project standards.
  • Tested thoroughly – Changes work as expected (Proxmox VE and/or Incus, as applicable).
  • No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.
  • API.txt regenerated – If a function signature or behavior changed, API.txt was updated to match.

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any code in this PR, you must confirm compliance below.
Select exactly one option.

  • No AI used – Code was written without AI assistance.
  • AI was used – The output has been reviewed and corrected, and I take responsibility for it matching this repo's conventions.

🛠️ Type of Change (X in brackets)

  • 🐞 Bug fix – Resolves an issue without breaking functionality.
  • New feature – Adds new, non-breaking functionality.
  • 💥 Breaking change – Alters existing behavior in a way that may require updates in every downstream script.
  • 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
  • 📝 Documentation update – Changes to README, docs/, CONTRIBUTING.md, or other docs.

Every migrated VM script still carried two blocks that were not its own. The
default-or-advanced fork was byte for byte identical in all of them, and the
fifteen-line settings summary agreed on thirteen lines -- the two that
differed, the CPU model label and the app name, are both derivable from
variables the script has already set.

vm_echo_default_settings computes the labels rather than taking them, so a
script can no longer print "Host" while CPU_TYPE says otherwise. That was
not hypothetical: the summary text and the variable were separate edits.

vm_start_script resolves default_settings and advanced_settings when it
runs, so each script still supplies its own. Nothing existing is changed --
the ten scripts that define start_script themselves keep overriding it.

Caught while testing: vm_machine_type_label takes the type as an argument
rather than reading MACHINE_TYPE, so calling it bare reported i440fx for
every machine, q35 included. Verified both ways round now, along with the
cache and CPU labels.
Three faults, all visible in one run of the CachyOS VM:

  101
  curl: (22) The requested URL returned error: 404
  vm-core.func: line 124: _cs_clear: command not found

load_functions ended with six bare names -- get_valid_nextid, cleanup_vmid,
cleanup, check_root, pve_check, arch_check -- left behind when their bodies
moved out of it. Loading the engine therefore ran them: the stray 101 is a
VM ID printed by get_valid_nextid, and cleanup tore down a temp dir before
there was one. Every script calls those itself afterwards, in its own order.
The same residue is in debian-vm.sh and k3s-vm.sh in ProxmoxVED.

_cs_clear had five callers here and no definition. core/core.func owns it,
but a VM script never loads that file -- it carries its own colours and
icons -- so header_info died on the first line it drew.

get_header let curl print its 404. A script whose banner the generator has
not produced yet is the normal case, and header_info already handles it by
drawing nothing; it just did so loudly. The empty file curl leaves behind is
removed too, since it would satisfy the cache check forever after.
@github-actions

Copy link
Copy Markdown
Contributor

Try this branch

The engine and the scripts resolve independently, so a production script can
be run against the engine from this PR by setting one variable:

COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/feat/vm-core-settings-helpers \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVED/main/ct/debian.sh)"

Swap ct/debian.sh for whatever exercises the change.

This PR touches pve/, so it needs a Proxmox VE host.

Run a script from a fork as well
curl -fsSL https://raw.githubusercontent.com/community-scripts/core/feat/vm-core-settings-helpers/tools/run.sh |
  bash -s -- https://raw.githubusercontent.com/YOU/ProxmoxVED/your-branch ct/debian.sh \
             https://raw.githubusercontent.com/community-scripts/core/feat/vm-core-settings-helpers

Note that run.sh is reached through a pipe, so the script it starts inherits
an exhausted stdin. Whiptail is fine — it opens /dev/tty — but a plain read
would see EOF. The single-variable form above does not have that problem.

Useful flags while testing

dev_mode=net logs every engine fetch with status and duration, which is the
quickest way to confirm the branch is really being used. dev_mode=keep stops a
failed build from deleting the container along with the evidence.

@MickLesk
MickLesk merged commit f28b115 into main Aug 31, 2026
4 checks passed
@github-actions
github-actions Bot deleted the feat/vm-core-settings-helpers branch August 31, 2026 08:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant