Skip to content

Windows: recover after the Podman WSL machine is stopped #46

Description

@lefoulkrod

Summary

After a successful clean installation on Windows 11, stopping the Podman WSL machine and relaunching the v0.10.0-alpha.2 CLI does not recover the runtime. The CLI enters environment preparation, fails to start Podman's user-mode networking, and cannot recreate the Omnideck container without manual changes inside the Podman WSL environment.

This is a non-blocking recovery edge case when the saved Podman machine is deliberately stopped. Normal clean installation, application use, and stable-to-alpha upgrade succeeded.

Tested environment

  • Omnideck CLI: v0.10.0-alpha.2 (c36d248d69e5)
  • Windows 11 Pro 25H2, build 26200, x64
  • WSL 2.7.11
  • Podman 6.0.2
  • Podman machine: omnideck-runtime, rootless WSL machine
  • Initial host state: WSL and Podman absent; both installed through the candidate's clean-host flow

Reproduction

  1. Start from a clean Windows 11 VM with WSL and Podman absent.
  2. Run bare omnideck v0.10.0-alpha.2 and complete the recommended setup, including restart/resume.
  3. Verify the omnideck container is running and http://localhost:2337 returns HTTP 200.
  4. Stop the runtime with podman machine stop omnideck-runtime.
  5. Run bare omnideck again.

Actual behavior

  • The CLI routes into environment preparation instead of completing a stable runtime-repair flow.
  • Starting the machine fails with exit status 125.
  • The nested podman-net-usermode WSL command exits 3.
  • A subsequent manual podman machine start omnideck-runtime succeeds, but host.containers.internal is absent inside the machine and getent ahostsv4 host.containers.internal exits 2.
  • The CLI cannot recreate the Windows container until the VM is manually given a 192.168.127.254 host.containers.internal entry and WSL host-file regeneration is disabled.

Expected behavior

Bare relaunch should recognize the stopped saved runtime, present an actionable repair path, start or repair the Podman machine and its networking, and return the existing Omnideck instance to HTTP 200 without undocumented manual commands or configuration edits.

The existing application configuration and omnideck-home / omnideck-state volumes must remain intact, and the repair must not create a second machine or application instance.

Acceptance criteria

  • Reproduce the stopped-machine state on a clean Windows 11 VM using the released Windows binary.
  • Bare relaunch completes runtime repair without manual WSL or hosts-file changes.
  • host.containers.internal resolves from a recreated Omnideck container after repair.
  • The original instance returns HTTP 200 with both persistent volumes and their data intact.
  • Final inventory contains exactly one intended Podman machine, instance, container, and volume pair.
  • Add or update Windows regression coverage for the stopped-machine path.

Release impact

Non-blocking Windows recovery edge case. Track it for improved self-repair behavior; do not treat it as a release blocker. The portable Windows contract, clean installation, and v0.8.0-to-alpha upgrade passed.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions