Dev mode

Dev mode is a set of opt-in debugging switches. You turn them on with the dev_mode variable in front of a script command. Nothing here is active in a normal run. The implementation is in core/dev-mode.func; the switches themselves are read where they act, in core/core.func, core/build.func and the backends.

Turning it onCopy Anchor Link

Name the switches, separated by commas:

dev_mode=net,timing bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"

Or ask for a picker. Set dev_mode to an empty value, 1, yes, true, ask or menu, and a checklist titled DEV MODE opens before the install menu:

dev_mode=1 bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"

The same checklist is reachable from the install menu under Settings → Configure dev mode. Besides the eight switches it has a verbose entry, which sets var_verbose=yes.

An unknown name is reported and ignored:

Unknown dev_mode 'timings' — known: net timing trace pause keep breakpoint motd logs

What you see in a dev runCopy Anchor Link

• Everything that is normally green (success lines, check marks, the header) is red. color does this as soon as dev_mode is non-empty, so a screenshot of a dev run cannot be mistaken for a normal install.
• A line Dev mode: <switches> followed by the context block:

  ── dev context ─────────────────────────────────────────────
  engine         prefetched → /dev/shm/cs-engine.Ab12Cd
  engine url     https://raw.githubusercontent.com/community-scripts/core/main
  scripts root   none (remote)
  scripts url    https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main
  app            Debian (debian, type ct)
  platform       pve
  arch           amd64
  pve            9.1.4
  bash           5.2.37
  curl           8.14.1
  session        1a2b3c4d
  ────────────────────────────────────────────────────────────

engine is one of prefetched → <dir>, local checkout → <dir> or network (<url>). See Loading for what these mean.

The switchesCopy Anchor Link

parse_dev_mode turns each name into an exported DEV_MODE_<NAME> variable that is true or false. The Proxmox VE backend exports all of them into the container.

netCopy Anchor Link

Logs every download the engine's resolver makes on the host, on stderr:

  [net] 200    412 ms  prefetch: 35 files, 0 missing -> /dev/shm/cs-engine.Ab12Cd
  [net] 200     87 ms  https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/debian-install.sh

Each line is HTTP status, duration and URL. The engine files are normally fetched in one parallel request, which shows up as the single prefetch: line. Files read from a local checkout are not listed, and downloads made inside the container are not logged. core/build.func reads this switch straight from $dev_mode, because the first downloads happen before parse_dev_mode exists.

timingCopy Anchor Link

Appends the elapsed time to a finished step and prints the ten slowest steps when the script exits, including after a failure:

  ✔️  <step text> (41237 ms)

  ── slowest steps ───────────────────────────────────────────
     41237 ms  <step_text>
  ────────────────────────────────────────────────────────────

A step is measured from msg_info to msg_ok, and the two are matched by their text. Only steps whose msg_ok uses exactly the same text as the msg_info that opened them get a time; a pair such as msg_info "Installing Dependencies" / msg_ok "Installed Dependencies" is not timed. The host and the container each print their own summary.

traceCopy Anchor Link

Turns on Bash tracing (set -x) with a prompt that shows file, line and function:

+(/dev/shm/cs-engine.Ab12Cd/core/core.func:1362): msg_info(): log_msg '[INFO] Installing Dependencies'

Tracing is switched on by set_std_mode. In a container build that function runs again inside the container, so the install script is traced from its bootstrap on. On the host it ran once while the engine loaded, before the switch was parsed, so the host side of a create run is not traced. Expect a lot of output, and note that traced commands can include passwords.

pauseCopy Anchor Link

After every msg_info the run stops with:

[PAUSE] Press Enter to continue...

It waits for Enter on /dev/tty, before the step's commands run. This applies on the host and inside the container.

keepCopy Anchor Link

When the install script inside the container fails, the host prints Keep mode active - container <CTID> preserved and returns without showing the recovery menu and without removing the container.

keep covers that case only. A failure on the host before or after the install is handled by the error handler, which still asks Remove broken container <CTID>? (Y/n) [auto-remove in 60s] and removes the container if nobody answers.

breakpointCopy Anchor Link

When the install script fails, the host opens a shell in the container (pct enter <CTID>, on Incus incus exec <name> -- bash) instead of the recovery menu. After you leave the shell it asks:

Container 105 still running. Remove now? (y/N):

Only y removes it. The script then exits with the install's exit code. If keep is set too, keep wins and no shell opens.

motdCopy Anchor Link

Only has an effect in the recovery menu of a failed install, and only when you choose 2) Keep container for debugging. The host then runs motd_ssh inside the kept container, so the login banner and (if root SSH was selected) the SSH server are set up even though the install never reached that step, and prints the address to connect to:

MOTD/SSH ready - SSH into container: ssh root@192.168.1.50

It does not combine with keep or breakpoint, because both skip the menu.

logsCopy Anchor Link

Creates /var/log/community-scripts/ and writes the host build log there instead of /tmp:

/var/log/community-scripts/create-lxc-<SESSION_ID>-<YYYYMMDD_HHMMSS>.log

Files in /tmp do not survive a reboot; this one does. The install log stays inside the container at /root/.install-<SESSION_ID>.log, and the combined log that is built after a failed install is still written to /tmp/<app>-<CTID>-<SESSION_ID>.log.

Useful combinationsCopy Anchor Link

For an unattended run add a mode, otherwise the install menu opens:

dev_mode=timing mode=default bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"

Verbose output is separate from dev mode: var_verbose=yes shows the output of commands that are otherwise only logged. See core.func for $STD and verbose mode.