problem creating Debian based machine and issues with win-sshproxy.exe

[mwoodpatrick]

/kind bug

/kind feature

Description

I'm trying to create a machine using

1. podman.exe machine init --image-path https://cloud.debian.org/images/cloud/bullseye/latest/debian-11-generic-amd64.qcow2 podman-debian11

Describe the results you received:

Downloading VM image: debian-11-generic-amd64.qcow2: done
Importing operating system into WSL (this may take 5+ minutes on a new WSL install)...
Import in progress, this may take a few minutes.
Unspecified error

Error: WSL import of guest OS failed: exit status 4294967295

Describe the results you expected:

machine installed

Additional information you deem important (e.g. issue happens only occasionally):

I have tried several debian distributions with same result either specifying the URL or the path to the downloaded image

Installing the default machine (using fedora) worked fine apart from

   API forwarding for Docker API clients is not available due to the following startup failures.
    win-sshproxy.exe failed to start, exit code: 1 (see windows event logs)

I could not find the error in the windows logs some additional pointers on this would be useful also instructions on how to run win-sshproxy.exe after the machine has been started

Output of podman version:

Client:       Podman Engine
Version:      4.1.0
API Version:  4.1.0
Go Version:   go1.16.15
Built:        Fri May  6 09:13:30 2022
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.26.1
  cgroupControllers:
  - cpuset
  - cpu
  - cpuacct
  - blkio
  - memory
  - devices
  - freezer
  - net_cls
  - perf_event
  - net_prio
  - hugetlb
  - pids
  - rdma
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.1.0-2.fc35.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.0, commit: '
  cpuUtilization:
    idlePercent: 99.95
    systemPercent: 0.02
    userPercent: 0.03
  cpus: 8
  distribution:
    distribution: fedora
    variant: container
    version: "35"
  eventLogger: file
  hostname: MarkSpectre14
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.10.102.1-microsoft-standard-WSL2
  linkmode: dynamic
  logDriver: journald
  memFree: 1165160448
  memTotal: 2002829312
  networkBackend: netavark
  ociRuntime:
    name: crun
    package: crun-1.4.4-1.fc35.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.4.4
      commit: 6521fcc5806f20f6187eb933f9f45130c86da230
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.12-2.fc35.x86_64
    version: |-
      slirp4netns version 1.1.12
      commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
      libslirp: 4.6.1
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.3
  swapFree: 1073467392
  swapTotal: 1073741824
  uptime: 3h 35m 56.86s (Approximately 0.12 days)
plugins:
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 0
    stopped: 2
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 1081180868608
  graphRootUsed: 640733184
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.1.0
  Built: 1651853610
  BuiltTime: Fri May  6 09:13:30 2022
  GitCommit: ""
  GoVersion: go1.16.15
  Os: linux
  OsArch: linux/amd64
  Version: 4.1.0

Package info (e.g. output of rpm -q podman or apt list podman):

podman-4.1.0-1.fc35.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

[Luap99]

@n1hility PTAL

[baude]

You cannot just use any old qcow2. You have to use one that is prepared specifically for the environment of machine (it has to have a ignition file, podman (at the same version as the windows client), among other things like network support already installed into it.

[mwoodpatrick]

Are there instructions for generating a suitable qcow2 file somewhere?

[n1hility]

As Brent mentions this option is not for a generic Linux distro, it's to allow for a customized or updated variant of the same distro podman machine is using (currently Fedora). The Linux distribution is provisioned by podman machine based on certain expectations, modifying system services, installing packages, including a custom recent copr package of podman, and various configuration changes. All these things are distribution specific so supporting additional distributions would require an additional code path per distro, and a maintainer to sign up for the ongoing work maintaining it.

If you do decide to create a customized variant, WSL needs a rootfs tarball instead of a qcow (that's why you see the error).

As to to the win-sshproxy error. Can you paste the event logs. The easiest way to get them is through powershell:

Get-WinEvent -ProviderName '.NET Runtime' -Oldest | Format-table -Wrap

Internally win-sshproxy is making an ssh connection, so one simple thing to check is can you do podman machine ssh to the system. If you are able to login we know that the expected key is working and the distro is running.

[mwoodpatrick]

I have an existing distribution based on Debian that I am using for my current work and I would like to be able to run podman on that distribution is there documentation somewhere on the changes you mentioned above so that I can apply these changes. I was able to build and run podman from the github repo but I would like to apply the windows integration that the windows releaase provides

When I run:

Get-WinEvent -ProviderName '.NET Runtime' -Oldest | Format-table -Wrap

I get:

Get-WinEvent: There is not an event provider on the localhost computer that matches ".NET Runtime".

[n1hility]

Did you install via the msi installer?. If there is no logs that implies the executable might not be at the expected location. The zip files we have include just the podman.exe remote client.

If you intend to just use the podman command you could not use podman machine and instead install/manage the distro yourself and just use the windows client as described here:
https://github.com/containers/podman/blob/main/docs/tutorials/mac_win_client.md

If you want docker clients to work though you need API forwarding, which you could still do with this approach by manually starting and stopping win-sshproxy.exe

You could try to manually create what podman machine init does, and the start and stop would work, but it would be brittle, an update might break something and you would have to sort out the difference.

[mwoodpatrick]

I had installed it originally from the github repo since I was mirroring what I did on my Linux droplet on Digital Ocean. Then I did a second install using the msi installer. Are there docs for win-sshproxy.exe somewhere it does not appear to support a help option other than the dialog box which is a bit cryptic

where is the source code for this app? I will take a look at mac_win_client.md and the source for "podman machine init"

[n1hility]

Ah ok, so it looks for win-sshyproxy.exe in the same dir as the podman.exe so I would double check the one being ran has it next to it.

The way you use it manually is like this:
win-ssproxy.exe my-proxy c:\path\To\A\TempDir npipe:////./pipe/docker_engine ssh://[user]@localhost:[port]//run/[user]/1000/podman/podman.sock C:\path\to\your\sshkey

Replace [user] with your user and [port] with the port you decide to run the ssh service on your distro, and update the drive paths to point to where you want them (the latter needs to point to your identify key)

The source code to the proxy is here:
https://github.com/containers/gvisor-tap-vsock/blob/main/cmd/win-sshproxy/main.go

The source to machine init is here:
https://github.com/containers/podman/blob/main/pkg/machine/wsl/machine.go

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.

[n1hility]

Converted to discussion since this is now about how to create a custom podman WSL instance

[mwoodpatrick]

Does anyone have any pointers on installing Fedora CoreOS on WSL-2?

[n1hility]

CoreOS as is isn’t compatible with WSL,since it expects a kernel ramfs where it can configure the system and wire-up device mounts. To work, it needs a custom bootstrap involving a separate path on many of the systemd init services which implements the fs pivot it does differently. That would also require a new regular build since it would be a different binary output. That said if you want to run CoreOS you could just set it up in a VM (e.g using the built in Hyper-V in windows).

[mwoodpatrick]

Many thanks for the info much appreciated. Is there documentation somewhere on setting up CoreOS on a Hyper-VM?