fix(shares): mount 9p shares on every boot, not just the first - #42
Conversation
Addresses six architectural issues: 1. Delete v1 metadata parser (dual parsers) 2. Add dependency ordering (depends field) 3. Add dry-run (--dry-run, --json) 4. Implement stage field (install-stage recipes) 5. Document single-reboot behavior 6. Add cloudinit post-boot SSH path
The host and work 9p lines carried _netdev. openrc runs localmount in the boot runlevel and skips _netdev entries, leaving them for netmount. stoat enables localmount, never netmount, so the shares mounted only at apply time (sshx.mountShares runs mount directly) and never again. A disk VM lost both shares on its next boot; the mountpoints stayed empty. virtio-9p enumerates during kernel init and needs no network, so localmount is the right service. Drop _netdev; keep nofail so a guest with no 9p module still boots. The apply mount step now also strips a stale _netdev from an already-installed VM's fstab, so stoat apply repairs a VM built before this.
|
Warning Review limit reached
Next review available in: 9 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 (5)
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
A disk VM's host/work shares mounted at apply time, then vanished on the next boot: the mountpoints were empty even though
/etc/fstabhad the lines.The 9p fstab options carried
_netdev. openrc runslocalmountin the boot runlevel and skips_netdeventries, deferring them tonetmount. stoat enableslocalmount, nevernetmount, so nothing mounted the shares on a plain boot. They mounted only becausesshx.mountSharesrunsmountdirectly during apply.virtio-9p enumerates during kernel init and needs no network, so
localmountis the correct service. This drops_netdevand keepsnofail(a guest kernel with no 9p module still boots). The apply mount step also strips a stale_netdevfrom an already-installed VM's fstab, sostoat apply <vm>repairs a VM built before this.Verified on a running disk VM:
mount /mnt/worksucceeds, the device and module are fine; the failure was openrc never invoking the mount at boot. Tests cover the new option string and the repair.Cloud-init's 9p path (systemd, different mount semantics) is untouched.