fix(installer): run the network-FS guard before the log dir is created - #441
Merged
Conversation
#432) setup_log_file mkdirs HOST_DATA_DIR and tees the whole session's output onto it BEFORE run_preflight fires — so on the exact machine the network-FS guard was built for (NFS home + sudo + root_squash), the unguarded mkdir failed with a bare error, or the log dir landed squashed/nobody-owned, before the friendly named failure could print. New early_data_dir_guard runs right after validate_config and before setup_log_file: same filesystem classification (extracted as the shared _pf_is_network_fstype), console-only, silent on local/undetermined filesystems, defers to the full check's warning under TRACEBLOC_ALLOW_NETWORK_FS. The call is declare -F-guarded so a stale bootstrap without the new helper proceeds as before. Closes #432 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
…#441) The guard advised HOST_DATA_DIR=/local/path, but validate_config requires the data dir under $HOME (Bugbot #384 hardening) — so the exact audience this guard exists for (network home) was pointed at a fix that fails validation on re-run. The copy now states the real constraint and the two workable paths (local-home user, or the explicit TRACEBLOC_ALLOW_NETWORK_FS=1 override with its risk), and notes that datasets may stay on network storage via HOST_DATASET_DIR. Test asserts the impossible advice stays gone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
|
bugbot run |
… r2) The early guard's job is protecting the pre-log mkdir; an existing data dir has no at-risk mkdir, and a healthy machine's re-run must keep reaching the assess hand-off exactly as it did when the network-FS check lived only in run_preflight. Existing dir -> silent pass; the full preflight guard still classifies network storage for real (re)installs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
Author
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit e4642d6. Configure here.
saadqbal
approved these changes
Jul 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The NFS/root-squash guard is good — but it fires after
setup_log_filehas alreadymkdir'dHOST_DATA_DIRand redirected the session's output onto it. On the exact machine the guard exists for (NFS home,sudo,root_squash), the install dies on a baremkdirerror — or leaves a squashed/nobody-owned log dir — before the guard's friendly, named failure can print.Change
_pf_is_network_fstype— the filesystem classification extracted from_pf_storage_type(shared, single list; the full check's user-visible strings are byte-identical).early_data_dir_guard— runs right aftervalidate_config, beforesetup_log_file: silent on local/undetermined filesystems, refuses network filesystems with the named fix (HOST_DATA_DIR=/local/path), and defers to the full preflight warning whenTRACEBLOC_ALLOW_NETWORK_FS=1.declare -F-guarded (same stale-bootstrap pattern as the assess/host_audit gates).setup_log_fileinmain());manifest.sha256regenerated.Independent of the #437→#440 stack (different manifest lines) — mergeable in any order relative to it.
Type
Bug fix
Test plan
Full bats suite green locally (incl. copy catalog — no golden drift);
bash -n+shellcheck --severity=errorclean;gen-manifest.sh --checkclean.🤖 Generated with Claude Code
Note
Low Risk
Installer-only ordering and messaging change with regression tests; no runtime cluster or auth behavior changes.
Overview
Moves the NFS/network-home failure earlier so users see a clear refusal instead of a bare
mkdirerror or a root-squashed log dir whensetup_log_filecreatesHOST_DATA_DIRbefore preflight runs.Adds
early_data_dir_guardinpreflight.sh, invoked frominstall-k8s.shright aftervalidate_configand beforesetup_log_file(with the samedeclare -Fstale-bootstrap pattern as other gates). Network filesystem types are centralized in_pf_is_network_fstype, reused by the existing_pf_storage_typecheck (behavior unchanged there). The early guard skips when the data directory already exists so healthy re-runs still reach assess (#441), honorsTRACEBLOC_ALLOW_NETWORK_FS, and uses remediation text that fitsHOST_DATA_DIRunder$HOME(no bogus/local/pathadvice).Six new bats cases cover classification, pass/fail paths, and install ordering;
manifest.sha256is updated.Reviewed by Cursor Bugbot for commit e4642d6. Bugbot is set up for automated code reviews on this repo. Configure here.