rdmbair15m5-changelog-20260825-1540-fleet-filevault-aware-reboot-wrapper

Added a FileVault-aware reboot shell function to five of six fleet Macs, so a terminal reboot defaults to fdesetup authrestart and the machine comes back without a human at the unlock screen.

Scope: rdmbair15m5, rdmsm4x, rdmpw3265m, rdmpw3275m, jdmbair13m5. rdmbair13m5 PENDING (off).
When: 2026-08-25 15:37 - 15:41 EDT. Driven from rdmbair15m5.

Why

Every fleet Mac has FileVault On with no auto-login. A plain sudo reboot / sudo shutdown -r now parks the machine at the pre-boot unlock screen with no network, no Tailscale and no launchd jobs until someone types the password in person. On the headless boxes (rdmsm4x, rdmpw3265m) it does not come back at all. sudo fdesetup authrestart hands the unlock key to exactly the next boot. The right command is easy to forget at the moment you type reboot, so it is now the default.

What changed, per host

Path	Change
`~/scripts/fleet_reboot.zsh`	NEW v1.0.0, mode 644
`~/.zshrc`	appended a guarded `source` line under `# --- fleet reboot wrapper (FileVault-aware) ---`. Backup at `~/.zshrc.bak-20260825-1540`

Append is idempotent — it greps for scripts/fleet_reboot.zsh first. .zshrc was already divergent across all five reachable hosts (five distinct sha256 prefixes: 697aa1df3aa5, 00b05f12c1e2, 01a71daa0ede, 352cc7fc78a4, ea91405dce79), so it is NOT force-synced and appending per host is safe.

Behaviour

reboot (and alias restart) is a zsh function, so it only shadows the binary in interactive shells. Scripts, sudo reboot, command reboot, \reboot and /sbin/reboot are all unchanged.

Invocation	Runs	Result
`reboot`	`sudo fdesetup authrestart`	returns unattended
`reboot -p` / `--plain`	`sudo shutdown -r now`	stops at the FileVault screen
`reboot -g` / `--gui`	`osascript ... System Events restart`	apps may prompt; can be cancelled
`reboot -q` / `--hard`	`sudo reboot -q`	ungraceful, for an already-stuck machine
`-y` / `--yes`	skips confirmation

Every path prints a banner naming the hostname, uptime, FileVault state, the exact command, and the plain-English consequence, then confirms. With six hosts and constant SSH between them, the realistic mistake is rebooting the wrong machine, not picking the wrong flag.

authrestart failure does not silently fall back to a plain reboot — that would strand the machine. It reports the likely cause (no Secure Token / wrong FileVault password) and tells you to run reboot --plain if that is acceptable.

Security note, stated rather than buried

fdesetup authrestart deliberately keeps an extra copy of the FDE unlock key in system memory and (on supported hardware) the SMC until the next boot completes. That is a documented, real reduction in FileVault protection while the restart is pending. It is surfaced in reboot --help. Use reboot --plain where that matters more than unattended recovery. pmset destroyfvkeyonstandby prevents the key being kept across standby.

Verification

zsh -n clean on every host; source is ASCII-only.
All four modes dry-run tested via FLEET_REBOOT_DRYRUN=1 before any deployment.
Confirmation edge cases tested: bare Enter declines, n declines, yeah declines, only y/Y/yes/YES proceeds. Unknown flag exits 2.
whence -a reboot confirms /sbin/reboot is still reachable.
Loaded in a fresh login shell on all five hosts, each correctly reporting its own hostname.

How to undo (per host)

rm -f ~/scripts/fleet_reboot.zsh
cp ~/.zshrc.bak-20260825-1540 ~/.zshrc      # or delete the two appended lines

Outstanding

rdmbair13m5 did not receive it — unreachable on both .local and the tailnet at 15:41 EDT, almost certainly powered off. Re-run the same two steps when it is back.