feat: automate the disk-VM lifecycle end to end - #37
Conversation
qemu.Start only flips Installed at the NEXT start, and the installer's poweroff just exits QEMU (-no-reboot). Nothing brought the disk itself up until now: a user had to run `stoat up` a second time by hand. AutoRestartAfterInstall waits for the installer to power off, then restarts the VM so it boots the disk. The guard disarms itself after one restart, since the next load sees Installed already true.
`stoat up` used to leave a fresh disk VM's install running and exit; the disk never booted until a second, manual `up`. up now blocks on AutoRestartAfterInstall before its usual post-boot apply, so one `up` carries the VM from installer to a provisioned system.
The TUI already auto-applies once a VM answers ssh; an uninstalled disk VM never reached that path, since needsAutoProvision excludes it on purpose (its sshd belongs to the installer, not the system). awaitInstall watches for the installer to power off in the background, the same way awaitSSH already watches for reachability, so the program stays responsive during the wait. Once the restart lands, installRestartedMsg hands off into the existing awaitSSH watch.
xfce's install-alpine.sh switches Alpine from mdev to udev (setup-devd), a change OpenRC only picks up at the next boot; without it Xorg finds no mouse or keyboard. A manual restart was the only fix. recipe.toml gets a reboot=true flag. Apply reboots the guest once, after every recipe in a run has succeeded, when any of them declared it, and waits for the guest to answer ssh again before returning.
|
Warning Review limit reached
Next review available in: 32 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (12)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Part 2 of the plan. One
stoat upnow takes a disk VM from install to a provisioned, input-working desktop with no manual restarts.Auto-restart after install (
internal/core/autorestart.go):AutoRestartAfterInstallwaits for the install poweroff (waitStopped), then restarts the VM so it boots the disk. The guard (disk && !Installed && qemu.Running) self-disarms after the install flip, so exactly one restart happens. A successful install powers off (QEMU exits via-no-reboot); a failed install leaves the installer running, so the watcher rides outInstallTimeout(15m) and gives up silently.stoat upon an uninstalled disk VM printsinstalling <vm>..., blocks on the watcher, then falls through to the existing apply.--no-applyskips the apply, not the restart.awaitInstallmirrorsawaitSSH;vmStartedMsgbatches it for an installing disk VM, andinstallRestartedMsgchains intoawaitSSH→ apply.Reboot once for udev (
internal/core/apply.go): recipes gain areboot = truemanifest field. After the recipes run, if one that ran declared it,rebootAndWaitreboots the guest over ssh and waits for it to come back. The xfce recipe sets it, sincesetup-devd udevonly takes effect at the next boot. One reboot regardless of how many recipes ask.Net:
stoat up <alpine disk vm + xfce>→ installer → auto-restart → apply → reboot once → a clickable desktop.Known limitation:
rebootSettle(2s) is a guess to keepwaitReachablefrom catching the pre-reboot sshd. Real reboot timing needs a live VM to confirm; I'll validate and tune it in an E2E pass. If it returns early, the guest still reboots and udev still takes effect — only the "ready" signal would be premature.Tests:
autorestart_test.go(guard, timeout-silent, stop-triggers-restart),apply_reboot_test.go(reboot-and-wait via a fake ssh + fake sshd, no real ssh), manifest reboot parse, TUI branch/installRestartedMsg.just checkandjust testpass.