-
-
Notifications
You must be signed in to change notification settings - Fork 397
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[hostagent] Waiting for the essential requirement 1 of 5: "ssh" on M1 Mac monterey #705
Comments
Can you share the output of |
Sure, there you go, I believe this is from the latest run which was using the command |
Looking at the logs, I found this which seems like the qemu process is getting terminated abruptly somehow.
|
It's a bit strange that the |
Anything I can do to get better logs to identify the reason? Could it be the log of the keyboard interrupt to stop the process as it was waiting for too long
As I mentioned above these logs seems to be from the latest run where I tried |
@rjra2611 just to confirm, this only happens when you're simulating x86_64 right? |
Nope, as shared in the issue description. I tried the following:
But got The only command which gave me a different result was |
You cannot change an architecture of an existing VM. If you initially created with You will need to either create a new instance by specifying the profile name |
@abiosoft I did a fresh install and tried
|
@rjra2611 you should probably also make sure you've done these when testing:
I use colima 0.5.4 with limactl 0.15.1 every day on mac M1, so so do dozens or hundreds of other DDEV users, so there must be something odd going on. I don't have a place to test with Monterrey, but lots of people are using it. The setup we recommend for DDEV is |
Thanks, @rfay Something worked, something didn't. I tried:
But it doesn't work and says What worked was using Logs from As may require is NOT to start VM in x86_64 I tried
NOTE: Used this after CC @abiosoft |
I didn't remember, maybe But running with --arch x68_64 is something which would be very, very unusual to use on mac M1. Can you please show the output of |
Sure, here you go @rfay Also, output of |
I'm glad you have the arm64 colima, that's good, and you have homebrew installed in the right place; lots of people have trouble when they move to mac M1 because they copy /usr/local/bin with amd64 homebrew over to the new mac, and it doesn't work at all. Your situation makes no sense at all :( You really don't want x86_64 right? You want to be running arm64? x86_64 will be nothing but trouble and poor performance for you unless there's some exotic reason you really have to run x86_64/amd64. I know you've already done this, but |
Please show |
Yeah, it only works on Ventura. |
I have the same issue. I just updated brew and Colima stopped working. I'm on an M1 Macbook Pro, and Colima worked just fine yesterday.
What worked for me is doing
It still hung on ssh for a minute or two. But it ended up working after that. But your mileage may vary. |
@rfay sure there you go Yup, nothing in /usr/local/Homebrew .
Yup, tried it as shared above with logs, sharing the screenshot here as well. @abiosoft can you please look into it too. My use case is to only run colima with arm64 but currently only works when using |
That is totally bizarre. Thanks for trying it out. |
It may also be weirdness on my machine / network. But FYI in case this is an issue for anyone else. |
I have upgraded to
At the same time:
It said that it can't open the
|
What might be good is cleanup and restart - and yes, restart sounds not needed, but if you had a system running for a while, and updated software etc - a clean restart might not be a bad idea. What might be good to do:
Now try a basic setup: Also if any issues - maybe post the following so all is 100% sure what versions are in use:
|
No, it did not work still :(
And here are logs:
|
It does look like you have qemu running already in this situation. We have asked about limactl current version a number of times, but not about qemu. You might want to brew uninstall all your qemu dependencies and reinstall them, and make sure qemu isn't running at all. But these lines sure do seem to imply problems outside of colima:
|
@rfay As stated earlier that I'm only able to run Colima in |
Hi @rjra2611 - All I can say is that your mileage may vary. In general, performance with emulated containers is awful and in many cases breaks unpredictably. For example, people are always trying to run Oracle DB and Oracle MySQL containers (only available in amd64) on arm64 and they run into complete blockers or random failures. I would certainly recommend that you upgrade to macOS Ventura but I assume there's a reason you haven't done that. It would sure help to understand this issue. But my expectation is that there's something in your network or computer that is the problem, and it's probably not Monterrey. But have you already tried temporarily disabling all firewall/VPN software? Have you tried using your computer on a different network? |
@rfay Thank you, that's very helpful |
I faced this issue every time I set |
I have this exact same issue, but on an intel 2020 macbook air.
|
Similar to the last two comments, I also run into this issue on an Intel MacBook Pro running 13.4 with 64gb RAM, but only whenever I run with |
Same issue here Tried completely cleaning colima, restarting the machine. generally using the options:
Modifying memory doesn't change anything for me, it still waits on "ssh" and fails with the same logs EDIT: UPDATE I'm not sure if the issue is pinned to a macOS version. It might be that the system update did it's housekeeping stuff and it got fixed that way. |
I have same issue with Apple M2 Max. Version of MacOs is
|
same issue with Apple M2 Max MacOs 13.5.1 (22G90) |
I fixed it with downgrade qemu to v8.0.3 |
That looks like a different error ("failed to open QMP socket") and different chip (Intel). I tried downgrading qemu anyway, but it didn't fix this error ("waiting for essential requirement ssh") on my system (M2 Ventura). |
Using a M2 Max on Ventura 13.2.1, this method worked for me (used Option 1 from the linked comment). Figured it was worth mentioning |
Also encountered this issue. Removed
As I am using MacPorts, I have no possibility downgrading to |
Same issue here. 😢 |
Now for the first time ever I've seen this, was wondering if it had to do with QEMU update, Homebrew/homebrew-core#155388 |
This latest seems to be due to QEMU homebrew upgrade etc,
And edit: The homebrew change is reverted in
Update, the homebrew revert fixed the problem. |
Same issue on Macos Sonoma 14.4.1 on M3 Pro |
Apparently, the workaround is using vz instead of qemu for now, on lima's issue #1996 |
For me this did not work either, I am getting
|
try removing the existing instance |
Try removing the cache folder |
I've had the same issue and looking through the /Users/<user>/.colima/_lima/colima/ha.stderr.log found that /Users/<user>/.colima/_lima/_config/user ssh key is too open, e.g. has to wide permissions. After executing chmod o-r,g-r /Users/<user>/.colima/_lima/_config/user everything was able to start without issues |
this worked for me! thanks! |
Trying the other items in this thread and nothing worked until I saw this. The
The "waiting for ssh" message in my other terminal tab went away and colima finished starting! I'm on MacOs Sonoma | M1
|
Solvento el problema, muchas gracias |
Description
Hey,
I'm trying to run
colima start --cpu 4 --memory 8
after a fresh brew install on my M1 Mac monterey but it seems to hangserial (9).log
Also tried
colima start --cpu 4 --memory 8 --cpu-type qemu64
which gaveerror at 'creating and starting': exit status 1
Logs for
colima start --cpu 4 --memory 8 --arch x86_64
serial (10).log
Tried using profile as well
colima start test --verbose
but it still hangsVersion
Colima Version:
colima version 0.5.4
Lima Version:
Qemu Version:
qemu-img version 8.0.0
Which colima
Which qemu-img
Operating System
Output of
colima status
FATA[0000] colima is not running
Reproduction Steps
Expected behaviour
colima start
should not hangAdditional context
No response
The text was updated successfully, but these errors were encountered: