[Bug] hex_sdk snapshot: snapshot_load_network_undo deletes /etc/appliance/state/configured on a configured node on 3.2.0

Open Beginner friendly
  • Is something wrong?
#1,783 0 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@arasHi87 is already working on this.

Since Oct 9, 2026.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
linux, shell
Domain
backend, infrastructure

Research direction

Read core/sdk_sh/modules/sdk_snapshot.sh:60-71 and trace how snapshot_load_network_config and snapshot_load_network_undo use /tmp/unconfigured and the configured-state files. Reproduce the configured-node case, then run the five QA checks in the issue, including the unconfigured-node case. Done means undo preserves an already configured node, settings are restored, and an unconfigured node remains unconfigured.

Written by the indexing model from the issue text.

Description

Description

On a configured 3.2.0 node, hex_sdk snapshot_load_network_config followed by hex_sdk snapshot_load_network_undo deletes /etc/appliance/state/configured. Undo is supposed to cancel the staged load and leave the node as it was. Instead, the node is put into unconfigured mode straight away: hex_cli falls back to the first-time-setup command set, where cluster is an "Unknown command". On the next boot the node would come up as unconfigured.

Both commands return rc=0 and print nothing, so the operator gets no warning.

Root cause (traced in core/sdk_sh/modules/sdk_snapshot.sh:60-71):

# snapshot_load_network_config
if [ ! -f /etc/appliance/state/configured -o ! -f /etc/appliance/state/sla_accepted ] ; then
    touch /tmp/unconfigured
fi
# snapshot_load_network_undo
if [ -f /tmp/unconfigured ] ; then
    rm -f /tmp/unconfigured /etc/appliance/state/configured /etc/appliance/state/sla_accepted
fi

sla_accepted is written only by the first-time SLA step (hex firsttime_sla.cpp, linked into hex_firsttime through cube.mk). A node that is configured but never went through that step, as the test node was, has configured and no sla_accepted. On such a node the -o condition is true, /tmp/unconfigured is touched, and undo removes configured. Nodes that accepted the SLA during first-time setup are not affected.

Reach is narrow: the only caller is the hex snapshot CLI's load-only path, which is labelled "for debugging" and asks for confirmation. The consequence on an affected node is still serious (it boots unconfigured).

How to Reproduce

Reproduction steps (7 steps, with command output)

On a configured 3.2.0 node that has no /etc/appliance/state/sla_accepted (the 1cc test node, CUBE_3.2.0_20261004-0551_cfc4886c), as root:

  1. ls -la /etc/appliance/state/configured /etc/appliance/state/sla_accepted. configured exists and sla_accepted doesn't.
  2. cp -a /etc/settings.txt /root/settings.bak; cp -a /etc/appliance/state/configured /root/configured.bak
  3. hex_sdk snapshot_load_network_config; echo rc=$?. This gives rc=0, and /tmp/unconfigured (0 bytes) is created even though the node is configured.
  4. hex_sdk snapshot_load_network_undo; echo rc=$?. This gives rc=0.
  5. ls -la /etc/appliance/state/configured → No such file or directory.
  6. hex_cli -c cluster health_ng → Unknown command: cluster, followed by the unconfigured-mode command list (advisor, agent, first, license, preset, snapshot, time, tree).
  7. Restore: cp -a /root/configured.bak /etc/appliance/state/configured.

Expected behavior

snapshot_load_network_undo restores /etc/settings.txt and leaves the node's configured state unchanged. It only removes configured if that file was created by this load/undo cycle, which can't happen on a node that was already configured before the load.

Screenshots (Optional)

None.

Additional Context (Optional)

Additional context: environment, versions, priority and notes

  • Found by upgrade check #1670 (story #772) on build CUBE_3.2.0_20261004-0551_cfc4886c in the 1cc test environment (regression run rt694-20261006).

  • Suggested fix: key the undo on configured only, i.e. touch /tmp/unconfigured only when configured is missing before the load, and drop the sla_accepted test. The settings.txt part of undo works: the md5 matched the baseline.

  • Consumers of configured that are affected after a reboot include bootstrap_cube_config, sdk_02-var-runtime.sh, sdk_health.sh and phone-home-agent.service.

Device Information (Optional)

None.

QA Verification

# Command / steps Expected outcome
1 On a configured node: hex_sdk snapshot_load_network_config; ls /tmp/unconfigured rc=0; /tmp/unconfigured doesn't exist
2 hex_sdk snapshot_load_network_undo; ls -la /etc/appliance/state/configured rc=0; configured still exists with its original mtime
3 md5sum /etc/settings.txt before step 1 and after step 2 Both md5 values are the same
4 hex_cli -c cluster health_ng after step 2 The cluster command is recognised (no "Unknown command: cluster")
5 On an unconfigured node (no configured file): load then undo The node stays unconfigured, and /tmp/unconfigured is removed by undo
  • QA Status declared at Done — when this issue reaches Done, set the board's
    QA Status field to Not needed or Ready to QA. Never leave it empty on a Done
    ticket; In QA / Verified are QA's own transitions.

Output artifacts (Definition of Done)

Beyond code, docs, and config changes, completing this issue must also deliver:

  • Handbook knowledge update — land the durable, team-readable knowledge from this
    work into the bigstack-handbook cubecos kb (kb/cubecos/…) via
    /bigstack-core:save-to-handbook (Topic / Runbook / Known-issue / ADR as fits).
    Diagnosed or fixed a failure? Ship the scenario sidecar (<note>.scenario.yaml)
    beside the note.
Dominant language
Shell
Stars
161
Forks
19
Avg merge
1d 12h
Merged PRs (30d)
135

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bigstack-oss/cubecos

All issues in bigstack-oss/cubecos

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.