Podman Desktop Hangs at "Initializing Podman" on Mac Book M1

[myfear]

Bug description

Podman Desktop stuck in above state after install.

Operating system

macOS Ventura 13..2.1

Version

0.12.0

Steps to reproduce

Install Podman Desktop on a blank system.

you can reproduce the hang on initialize podman by deleting all the podman artifacts[1] and begining again with the installer disk image -> drag to applications -> run -> install podman -> quit -> restart podman desktop -> intialize podman -> HANG

[1]:
~ % rm -r .config/containers
~ % rm -rf .local/share/containers
~ % sudo rm -rf /opt/podman
~ % rm -rf Library/Application\ Support/Podman\ Desktop
~ % sudo rm -r /private/etc/paths.d/podman-pkg
~ % sudo rm -r /usr/local/podman
~ % sudo rm /Library/LaunchDaemons/com.github.containers.podman.helper-josh.plist

~ % mdfind -name podman|grep -v 'devel/go' /Users/josh/Downloads/podman-desktop-0.12.0-arm64.dmg

Relevant log output

No response

Additional context

No response

[joshix]

Workaround is something like: At HANG T+?, quit Podman Desktop. Relaunch Podman Desktop to find ready state.

NB: HANG here and above represents no progress no completion of podman init process, but not a hang or unresponsiveness in the electron UI side.

[benoitf]

It could be interesting to know what is happening when you do in cli 'podman machine init' step and then 'podman machine starts step ( instead of launching podman desktop and clicking on the toggle to initiale podman )

Do you have errors ?

[joshix]

I used the arm64 macos .pkg from podman-installer-macos-arm64.pkg.

j@s2 ~ % podman machine init
Downloading VM image: fedora-coreos-37.20230303.2.0-qemu.aarch64.qcow2.xz: done
Extracting compressed file
Error: key generation failed, unable to read from stderr: exit status 1
j@s2 ~ % podman machine start
Starting machine "podman-machine-default"
WARN[0000] podman helper is installed, but was not able to claim the global docker sock 
Waiting for VM ...
Error: qemu exited unexpectedly with exit code 1, stderr: qemu-system-aarch64: -drive file=/Users/j/.local/share/containers/podman/machine/qemu/podman-machine-default_ovmf_vars.fd,if=pflash,format=raw: Could not open '/Users/j/.local/share/containers/podman/machine/qemu/podman-machine-default_ovmf_vars.fd': No such file or directory

Note that sometimes -- cannot reliably repeat -- the GUI displays the same error key generation failed when the init step initiated in the GUI is spinning.

Note that I removed ~/.local/share/containers/podman/machine/qemu/podman-machine-default_ovmf_vars.fd manually when cleaning the environment to reproduce the GUI spinning at init step. It doesn't seem to get recreated on a subsequent install, so evidently there is state still lingering somewhere telling us it is not the first run?

[TomasHubelbauer]

I can confirm this happens to me as well. Podman 0.12.0 and macOS Ventura 13.3. The workaround is the same as others already mentioned: wait a few minutes, restart Podman Desktop. I checked podman machine list first before restarting Podman Desktop to see the default machine got created so I was reasonably sure that after the restart everything would work fine. BTW there were no errors in the developer tools console before I restarted Podman Desktop.

This was already raised in #951 and supposedly fixed in #953 but I think the fix was only partial seeing as it continues to happen.

[benoitf]

if you are stuck please provide logs ( View / toggle developer tools and then console and paste all the logs)
There is an error thrown somewhere

[TomasHubelbauer]

As I've already started, there was no error thrown in the developer tools. Unfortunately I have not saved the contents of the console. After restarting the Podman Desktop app, the VM was discovered and the app worked, so I cannot reproduce this issue anymore to get the logs.

[benoitf]

this is the main problem to fix without knowing the root cause. If you're able to reproduce please report the logs. Thanks

[TomasHubelbauer]

Have you tried installing Podman Desktop on a clean macOS install? I might try uninstalling and reinstalling it later if that's enough to reproduce the issue. BTW I used Homebrew to install both Podman and Podman Desktop if that helps. I will let you know if I've managed to reproduce the error on my same machine after uninstalling and reinstalling Podman.

[benoitf]

@TomasHubelbauer let us know. Thanks

[ST33LDI9ITAL]

Same situation. Fresh install from website. Asked to install podman, so did, it didn't refresh detection and switch to initialize.. so had to restart Podman Desktop, (filed separate ticket for that). Once quit and went back into PD, hit initialize and start, then got a good ol never ending infinite loading loop.

[sgallagher]

Same as @ST33LDI9ITAL above, on Podman Desktop 0.15.0 and Podman Engine 4.5.0.

[TomasHubelbauer]

I was able to try this again on a new machine. I am using macOS Ventura 13.4 (latest) on an MX series CPU. Docker was already installed and running on the machine. I installed Podman according to the instructions on https://podman-desktop.io/docs/Installation/macos-install and went through the process of fixing the detection checks (not being in PATH) as well, the other prerequisites were all met and the application is displaying that Docker is running:

I started it and clicked on the Initialize button and checked the Podman window dev tools. There are messages repeating in a loop, some containing names of existing containers (not created or maintained by Podman) that I have in my Docker Desktop instance.

This is what I am seeing in the dev tools console:

index.ts:1327 main ↪️ Kubeconfig path /Users/tom/.kube/config provided does not exist. Skipping.
index.ts:1327 main ↪️ PluginSystem: received dom-ready event from the UI
index.ts:1327 main ↪️ Delayed startup, flushing 6 events
index.ts:1327 main ↪️ System ready. Loading extensions...
index.ts:1327 main ↪️ Activating extension (compose)
index.ts:1327 main ↪️ Activation extension (compose) ended
index.ts:1327 main ↪️ Activating extension (docker)
index.ts:1327 main ↪️ Activation extension (docker) ended
index.ts:1327 main ↪️ Activating extension (kind)
index.ts:1327 main ↪️ Activating extension (kube-context)
index.ts:1327 main ↪️ [kube-context] starting extension kube-context
index.ts:1327 main ↪️ Activation extension (kube-context) ended
index.ts:1327 main ↪️ Activating extension (lima)
index.ts:1327 main ↪️ [lima] Could not find podman socket at /Users/tom/.lima/podman/sock/podman.sock
index.ts:1327 main ↪️ Activation extension (lima) ended
index.ts:1327 main ↪️ Activating extension (podman)
index.ts:1327 main ↪️ Activating extension (registries)
index.ts:1327 main ↪️ Activation extension (registries) ended
index.ts:1327 main ↪️ Activation extension (podman) ended
index.ts:1327 main ↪️ Retrieved fetchable extensions in 304.05624997615814ms
index.ts:1327 main ↪️ [kind] Error: Error: spawn kind-darwin-arm64 ENOENT
    at ChildProcess.<anonymous> (/Applications/Podman Desktop.app/Contents/Resources/app.asar/extensions/kind/builtin/kind.cdix/dist/extension.js:7:11544)
index.ts:1327 main ↪️ Activation extension (kind) ended
index.ts:1327 main ↪️ PluginSystem: initialization done.
index.ts:1327 main ↪️ Autostarting container engine
index.ts:1327 main ↪️ event is "exec_create: wget --no-verbose --tries=1 --spider http://localhost:9999/health" ID "77c04fdf617be45f2cd668809496693666dcf8e5460dccd2c9b4f295e7a727ff"
index.ts:1327 main ↪️ event is "exec_create: wget --no-verbose --tries=1 --spider http://127.0.0.1:5000/status" ID "b773d50d865ce4c76658948bcbd415162aa98ddc42a99b4ffc67f4e252f39908"
index.ts:1327 main ↪️ event is "exec_start: wget --no-verbose --tries=1 --spider http://localhost:9999/health" ID "77c04fdf617be45f2cd668809496693666dcf8e5460dccd2c9b4f295e7a727ff"
index.ts:1327 main ↪️ event is "exec_start: wget --no-verbose --tries=1 --spider http://127.0.0.1:5000/status" ID "b773d50d865ce4c76658948bcbd415162aa98ddc42a99b4ffc67f4e252f39908"
index.ts:1327 main ↪️ event is "exec_create: bash -c printf \\0 > /dev/tcp/localhost/4000" ID "7f6167f854fb6936dbf356dfcf9a5c32057304b02a14d9627c5c944910286ebf"
index.ts:1327 main ↪️ event is "exec_start: bash -c printf \\0 > /dev/tcp/localhost/4000" ID "7f6167f854fb6936dbf356dfcf9a5c32057304b02a14d9627c5c944910286ebf"
index.ts:1327 main ↪️ event is "exec_die" ID "b773d50d865ce4c76658948bcbd415162aa98ddc42a99b4ffc67f4e252f39908"
index.ts:1327 main ↪️ event is "exec_die" ID "7f6167f854fb6936dbf356dfcf9a5c32057304b02a14d9627c5c944910286ebf"
index.ts:1327 main ↪️ event is "exec_die" ID "77c04fdf617be45f2cd668809496693666dcf8e5460dccd2c9b4f295e7a727ff"
index.ts:1327 main ↪️ event is "exec_create: pg_isready -U postgres -h localhost -p 5432" ID "4b917c9dd33879bb7de777c688c159139026eb049781c7448ca9415537327085"
index.ts:1327 main ↪️ event is "exec_start: pg_isready -U postgres -h localhost -p 5432" ID "4b917c9dd33879bb7de777c688c159139026eb049781c7448ca9415537327085"
index.ts:1327 main ↪️ event is "exec_create: imgproxy health" ID "5ec76798de084eb1b5ab27510a209d3098692fcf2936c23e6573a12f40b021ce"
index.ts:1327 main ↪️ event is "exec_start: imgproxy health" ID "5ec76798de084eb1b5ab27510a209d3098692fcf2936c23e6573a12f40b021ce"
index.ts:1327 main ↪️ event is "exec_die" ID "4b917c9dd33879bb7de777c688c159139026eb049781c7448ca9415537327085"
index.ts:1327 main ↪️ event is "exec_die" ID "5ec76798de084eb1b5ab27510a209d3098692fcf2936c23e6573a12f40b021ce"

etc.

It keeps looping like this with exec_create, exec_start and exec_die with matching IDs.
On the high level this then happens for other actions:

"exec_create: node -e require('http').get('http://localhost:8080/health', (r) => {if (r.statusCode !== 200) throw new Error(r.statusCode)})" 
"exec_start: node -e require('http').get('http://localhost:8080/health', (r) => {if (r.statusCode !== 200) throw new Error(r.statusCode)})"
"exec_create: node -e require('http').get('http://localhost:3000/api/profile', (r) => {if (r.statusCode !== 200) throw new Error(r.statusCode)})"
"exec_start: node -e require('http').get('http://localhost:3000/api/profile', (r) => {if (r.statusCode !== 200) throw new Error(r.statusCode)})"
"exec_die"
"exec_die"

and so on.

There is no one service/component that stands out, everything is just create-start-die forever and eventually the set starts looping.

I have the logs locally so feel free to contact me out of band for the whole logs, I didn't want to copy them to the issue because there are private container names in there.

BTW I have tried to set up Podman twice on two different machines and it failed each time. @benoitf now that there are logs and more info, can you try reproducing on a machine yourself and see if you run into the same issue? This seems quite reproducible at least in my experience.

[Lewiscowles1986]

mkdir -p ~/.lima/podman/sock was all I had to do to stop the loop when podman had been exited. Hope this helps someone.

[benoitf]

Thanks for your report @Lewiscowles1986

[darkBuddha]

just had same issue with Podman 1.1.0 on macOS 13.4 (installed via homebrew)

[evanshortiss]

EDIT: Check my new comment below this!

I'm running into this issue. I recently upgraded to macOS Ventura on an M1 MacBook Pro. Could the update be related? My Podman installation and machine are working as expected. It's only the Podman Deskop UI that's "stuck".

Starting machine "podman-machine-default"
Waiting for VM ...
Mounting volume... /Users/eshortis/:/Users/eshortis/

This machine is currently configured in rootless mode. If your containers
require root permissions (e.g. ports < 1024), or if you run into compatibility
issues with non-podman clients, you can switch using the following command:

	podman machine set --rootful

API forwarding listening on: /var/run/docker.sock
Docker API clients default to this address. You do not need to set DOCKER_HOST.

There's no useful information printed in the DevTools as far as I can see:

[evanshortiss]

So, it turns out that Podman Desktop finally passed the "Initializing" phase while I was writing my previous comment, but it takes over a minute.

I noticed that Podman Desktop can start up quickly (a few seconds) when I disable my Pi-Hole DNS. Is Podman Desktop reaching out to an analytics service on startup? If that analytics lookup fails does it stall Podman Desktop? Those are the only blocked DNS lookups in my Pi-Hole logs that correspond to when I launched Podman Desktop.

EDIT: This might be the culprit? It might also require a separate issue? 😄

[deboer-tim]

I put an intentional sleep in the code where the telemetry initializes and indeed it hung on Initializing screen as above. We can fix that and make it async, but I don't think everyone above is hitting this same issue.

[evanshortiss]

@deboer-tim I tried to change it to the code below, and it didn't work. The telemetry.init() was a red herring, since I found the real fix and opened a PR explaining it. TLDR; Podman Dekstop attempts to reach out to the current cluster targeted by your kubeconfig. If this cluster is not available it delays the initialisation!

// Do not await init() complete, simply move along
telemetry.init().then(() => { console.log('telemetry init success') }).catch((err) => { console.error('telemetry init error', err) });

The issue for me was this line of code. I noticed in the DevTools logs that I have a log line that states Error while fetching API groups: Error: connect ETIMEDOUT x.x.x.x:6443. This appears immediately before the initialisation completes. It seems that Podman Desktop is trying to reaching out to an OpenShift cluster on my mesh network, but it fails because I have the OpenShift instance powered down. Seems to me that this code needs to use more aggressive timeout values? The Kubernetes client used must have an easy way to configure HTTP timeouts, but I wasn't able to see it.

[deboer-tim]

Thanks for narrowing this down, Evan. Agreed we need to reduce the timeout, make it async, or likely best: both.

IMHO a delay in sending out the first telemetry event shouldn't block initialization either, but I'll consider that unrelated and follow up independently.

[evanshortiss]

Thanks, and agreed! 😃

[Gauravtalreja1]

Hello, I've installed the latest podman and podman-desktop 1.3.1 from brew on MacBook M1. I'm also seeing this issue on podman-desktop, able to manage containers using podman from terminal but podman-desktop hangs, and guessing the fix mentioned for async telemetry setup might be included now, so just wondering if this is still being worked on or if there is any workaround? Thank you in advance :)

[benoitf]

@Gauravtalreja1 when you say it hangs, do you see some UI or errors ?

could you open the devtools windows (Command+Option+i )

[yasirmturk]

I am not able to connect to the socket

[lpar]

Console errors I get:

index.ts:1506 main ↪️ Kubeconfig path /Users/meta/.kube/config provided does not exist. Skipping.
index.ts:1506 main ↪️ [lima] Could not find socket at /Users/meta/.lima/podman/sock/podman.sock
index.ts:1506 main ↪️ [lima] Could not find config at /Users/meta/.lima/podman/copied-from-guest/kubeconfig.yaml
main ↪️ [kind] Error: Error: spawn kind-darwin-arm64 ENOENT
    at ChildProcess.<anonymous> (/Applications/Podman Desktop.app/Contents/Resources/app.asar/extensions/kind/builtin/kind.cdix/dist/extension.js:7:11545)
    at ChildProcess.emit (node:events:513:28)
    at maybeClose (node:internal/child_process:1091:16)
    at Socket.<anonymous> (node:internal/child_process:449:11)
    at Socket.emit (node:events:513:28)
    at Pipe.<anonymous> (node:net:322:12)

[abdullahcicekli]

Any progress ?

[sofpodev]

It also happens on Mac Intel (14.1). It also causes Mac to freeze!
Any permanent solution or workaround?

[Jap8nted]

Same here,

I am using Mac M1 arm

Tried using Podman command line and desktop, was not able to use it. Still don't understand what is the problem, there are multiple GitHub issues talking about this but none of them really gives a solution for this.

[benoitf]

@Jap8nted could you go to settings (cog in left navbar) then resources then click on the podman machine and click on ↗️ icon to get podman machine details

and here go to the logs tab

[Jap8nted]

Thanks for your response @benoitf , I was installing using:

brew install podman-desktop

I tried once installing the downloaded file from https://podman-desktop.io/downloads, it worked fine.

I have to fix some issues, after I do that, will try to reproduce it and upload the logs!

[Janhouse]

I did have an older vm running fine, but the podman-machine-default_fedora-coreos-39.20240112.2.0-qemu.aarch64.qcow2 image crashes when starting it.

podman machine init
podman machine start --log-level=trace

[benoitf]

the recent comment was about the Qemu 8.2.0 issue and ARM processor/Silicon (fixed with qemu 8.2.1)
https://gitlab.com/qemu-project/qemu/-/issues/1990

else it looks we do not reproduce it, closing