[Big Sur] VMs turn to "Starting" state and won't budge #1839
Comments
|
Hi @flying-sausages, when this happens, what do you see in Can you comment on when did you leave / get back to the machine? This suggests the VM crashed (when the host was going to sleep?): And then Multipass failed to realize? Would you please enable trace logging, as that may give us more of a clue? $ sudo launchctl unload /Library/LaunchDaemons/com.canonical.multipassd.plist
$ sudo /usr/libexec/PlistBuddy -c "Add :ProgramArguments: string --verbosity" -c "Add :ProgramArguments: string trace" /Library/LaunchDaemons/com.canonical.multipassd.plist
$ sudo launchctl load /Library/LaunchDaemons/com.canonical.multipassd.plist |
|
Thanks for the fast response! I'm going to wait until this reproduces again and will let you know. I've restarted my instances since so I don't have those old logs. As for the timing, I've left it when I went to bed, and picked it up in the morning. I'll see if this reproduces again over longe periods of sleep. |
|
Hi @flying-sausages, does this happen only when powering the machine on? If so, this could be a variation of #1652. Multipass comes up and tries to start the VMs that were previously running, but the OS doesn't seem to be ready yet. We could try a 5s or 10s delay in the daemon when on macOS, but that may always fall short. Otherwise, I don't see an infallible way to handle this. There might be a way to interrogate the OS for a fine-grained status or something like that... it would need investigating. However, I would expect the crashed instance to be stopped (as in the linked issue). You mentioned you weren't sure if you saw a time-out on the command line, right? Let us know if you see one. Also, you said you could not restart or stop the VM when it's in that state, correct? But after restarting the daemon (as you mention in your workaround) you can recover it, IIUC? If so, I think that's the best option for you in such situations, to avoid dropping the VMs. |
|
Hello, I believe I have the same or at least similar problem. It occurs after I reboot my host (macOS Mojave 10.14.6). If the VMs were stopped before rebooting, I can restart them just fine. Regardless of the order I do the list, start, stop, restart commands, I always get the same result. Workarounds: |
|
Hi @naturaverl, in the session you pasted, your If that still doesn't work, you could try |
Sorry I haven’t forgotten about this but my MacBook Pro has some hardware issues so until spare parts come through I can’t verify this. |
|
I have had the same problem twice already in my macOS Big Sur This sucks as the images get into an corrupted state. @ricab No, |
So I got an M1-equipped machine in the meantime, guess I can't come back to you on this one. |
|
@flying-sausages v1.8.0 supports the M1 now, too. All, please reopen if you encounter this again. |
|
I am seeing this on BigSur. Restart and the image becomes corrupt. multipass 1.8.1+mac As above ... Reestarting the daemon does "fix" the image. |
|
same here Big Sur v 11.6 multipass 1.8.1+mac @Saviq apparently only the reporter can reopen the issue; |
|
still persists in 1.8.1 on macOS 12.1 |
|
Same problem on Windows 10, multipass 1.8.1. Instances are stuck after a reboot - just says "starting" indefinitely when running |
|
@philrawlings can you please file a new issue with your details? 1.8.1 was only released for macOS, btw :) |
Describe the bug
When I come back to my machine in the morning, my VMs are in a "Starting" state and I cannot get them to shut down, start up, suspend or anything. Deleting and purging works but i'd prefer not to have to wait for my environment to setup every time this happens.
To Reproduce
How, and what happened?
Expected behavior
Not having to kill/delete+purge instances
Logs
Please provide logs from the daemon, see accessing logs on where to find them on your platform.
Additional info
multipass version: 1.5.0+macmultipass info --all: Will update once I am able to reproduce this again, seeing as I binned everything and started again.Additional context
Current workaround is finding the
multipassdprocess throughsudo htopand then killing it. There is no trace ofmultipassinlaunchctlThe text was updated successfully, but these errors were encountered: