-
-
Notifications
You must be signed in to change notification settings - Fork 380
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
Error starting with --network-address #458
Comments
Are you on macOS Ventura as well? If yes, we can close this in favour of #457 |
Can you kindly try with the current development version?
|
@abiosoft I am not on Ventura. It still errors after upgrading. Results are below. console logging:
~/.lima/colima/ha.stderr.log
|
This is very strange. Can you start again with network address to reproduce the error and share the contents of the
|
ls -lah ~/.colima/default/daemon
cat ~/.colima/default/daemon/daemon.log
|
Does it prompt you for a password for setting up network?
|
It did not prompt me for sudo. It has before, but even after the suggested command, it is not prompting. |
Oops, I made a typo in the command. I've fixed it now. |
Hey can you do one thing.
|
Reran with the above steps plus removing STDOUT:
~/.lima/colima/ha.stderr.log
~/.colima/default/daemon/daemon.log
|
I have the same issue on Ventura M1. The colima version with --HEAD option colima does start but there is no IP address assigned. |
Here is my daemon.log if it helps:
|
You just can't run that image, as it has an incompatible architecture, whatever arm64e is. Really, oracle mysql image isn't going to work for you on an arm64 (mac M1) machine. |
Sorry, the above error is without installing using --HEAD.
as you can see there is no IP address assigned cat .colima/oraxe/daemon/daemon.log
time="2022-11-11T22:27:34+01:00" level=info msg="- - - - - - - - - - - - - - -"
time="2022-11-11T22:27:34+01:00" level=info msg="daemon started by colima"
time="2022-11-11T22:27:34+01:00" level=info msg="Run `pkill -F /Users/codrut/.colima/oraxe/daemon/daemon.pid` to kill the daemon"
time="2022-11-11T22:27:34+01:00" level=info msg="waiting for clients..."
on_accept(): vmnet_return_t VMNET_INVALID_ARGUMENT
vmnet_write: Undefined error: 0
time="2022-11-11T22:27:37+01:00" level=info msg="new connection from to /Users/codrut/.colima/oraxe/daemon/gvproxy.sock" |
Sorry, I did read it wrong, usually this is seen with oracle. But the problem is the same. You seem to be trying to use an architecture arm64e, please change that in your config file to arm64. AFAIK To recreate your situation, rename the .colima folder to .colima.bak and the lima folder to .lima.bak and then go through your process. |
@altitudedashboard the error you shared should be gone with Can you try starting with |
@abiosoft This works! Thank you!
starts from scratch:
|
The above seems to work intermittently, as today trying to start colima doesn't revel an IP address |
Have the same problem on the latest (13.0.1) macOS and M1.
Having the same error with all combinations of runtimes and network drivers ( |
just try also with the latest colima version: brew install --HEAD colima and also perform a reinstall of qemu after colima as it might fix some bugs brew reinstall qemu |
@sparhomenko kindly use the |
Apologies, I should have mentioned that I was already using HEAD with the latest commit:
Reinstalling qemu also doesn't help (I was actually already doing that as |
Having a similar problem... |
I am also having the same problem, my logs are exactly the same however wiping the directories and reinstalling from HEAD works "intermittently" as described above but to the negative. Meaning: if I blow it all away and start over sometimes it errors out completely and sometimes it starts with no routable IP, I am not able to get a valid IP at all. |
It seems like there may be an issue with the If I run the following (profile =
If I don't specify a profile name and start Colima (
|
Hello folks, Version: Operating System I would like to have some advices to solve the issue about the option --network-address, I have tried all the possibilities, a clean installation and all the stuff described above. but I'm still getting this information :
and no attribution of IP is made. Thanks in advance. |
@PARENTELF I am struggling with properly reproducing this as well. It seems to happen (for me) in one of the following scenarios.
The main issue is that the behaviour is not consistent, it works most time but when it breaks I am usually unable to resolve it until a macOS restart. Since you are on macOS 13 Ventura, you can give the VZ driver a try colima delete # required for switching vm types
colima start --vm-type vz --network-address PS: kindly update to latest head as it includes a fix to a regression introduced in |
Hello thanks for your quick reply, Colima updated: colima version HEAD-ed49fef when I add this extra option :--vm-type vz, I fall into the following case: note: after the installation of colima I have give a restart.
wich is also related #533 thanks! |
@PARENTELF this is not "an issue" except it got stuck. |
This doesn't work for me either
I also tried |
We were having this issue and discovered that having a |
same thing happens on intel mac .. posted in 449 as well. This is after I removed & reinstalled everything per the suggestions in this and 449, think there was another around vmnet.
regular network driver
slirp driver
|
Can anyone try the latest development version Thanks. |
Hi @abiosoft , Specs: |
Same issue when running multiple instance with
Tried using |
Hi!
I am running macOS Monterey 12.4 on an M1 Mac. |
I managed to get it working three weeks ago using the instructions posted by codrutP. Previously, I had tried using Colima by installing Docker, Docker Compose, and then Colima via Homebrew. Starting Colima resulted in the following error message:
After that, I followed the above-mentioned instructions, which led to:
Three weeks ago, I was confused about the warning ('error setting up reachable IP address: [...]'), thinking that my Docker containers wouldn't function because of it. However, it turned out that they functioned without any problems. Today, I reinstalled Colima due to an issue running docker login. For some reason, Docker was unable to connect to Docker Hub for authentication. After a fresh install of Colima, I was able to resolve my issue with docker login. Regarding issue #458: I would like colima to work right out of the box when installing it via PS: I used |
For me the issue persists M1 Ventura, latest colima version WARN[0181] error setting up reachable IP address: vmnet socket file not found: stat /.../.colima/default/daemon/vmnet.sock: no such file or directory Instructions havent changed the result. |
Same for me @OksiBlack |
Certainly not the fix, but this works as a workaround for me when
(you are now in SSH inside VM)
This results in the VM having the IP
|
@madpah Thanks for the workaround. I did a factory reset and its been hold steady for now. Some others using the trellis project have similar issues. Ill refer back here. |
Trying all the solution suggested above, still having that issue. Though I tried Here's my daemon.log:
|
Hello guys, To whom it may concern: colima version 0.5.5, arch: aarch64, macbook air m2, vz/virtiofs With The solution is to start dhcp server on bridge100 serving 192.168.106.* range, e.g., dnsmasq, which might require disabling macos builtin server |
@jamhed can you share what commands we actually need? or any other solutions? |
I've had to revise my solution to run this command inside the colima VM (after sudo):
|
So there seems to be multiple issues in the project regarding regarding creating a colima VM and successfully obtain a IPv4 address after @norrs doing some research:
Executing the following commands below would add a firewall rule for $ sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/libexec/bootpd
$ sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblock /usr/libexec/bootpd However, you might be blocked due to MDM (mobile device management) in your company if you are unlucky: lima-vm/socket_vmnet#18 (comment) and lima-vm/socket_vmnet#18 (comment) . This issue seems to already be documented in lima-vm/socket_vmnet:README. FYI @abiosoft - hope it helps clearing up errors others are experiencing. For everyone else: This is also a good link for introduction on how lima under the hood does networking: https://lima-vm.io/docs/config/network/
I had this working on Friday, I believe I did a required system upgrade due to policy on the computer during the weekend (and probably had colima running in the background) and ended up with Sonoma 14.4 on my newly freshly aquired Mac Pro M3. After reboot I noticed my VMs under colima did not receive an IPv4 addresses. |
It is sort of weird that I'm observing something completely different from what @norrs is reporting in this comment. I wonder if we're observing completely different issues or the same issue with different manifestations due to slight differences in our set-ups. These are the observed differences.
In my case for VZ fails because the interface
In my case for QEMU it works perfectly. My setup:
To see how to reproduce the issue, click hereVZCommand line
OutputINFO[0000] deleting colima [profile=test-net]
INFO[0000] done
INFO[0000] starting colima [profile=test-net]
INFO[0000] runtime: docker
INFO[0000] creating and starting ... context=vm
INFO[0102] provisioning ... context=docker
INFO[0104] starting ... context=docker
INFO[0215] done
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 52:55:55:ce:b3:5a brd ff:ff:ff:ff:ff:ff
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:9b:d1:eb:ee brd ff:ff:ff:ff:ff:ff
INFO[0000] colima [profile=test-net] is running using macOS Virtualization.Framework
INFO[0000] arch: x86_64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/[...]/.colima/test-net/docker.sock QEMUCommand line
OutputINFO[0000] deleting colima [profile=test-net]
INFO[0000] deleting ... context=docker
INFO[0001] done
INFO[0000] starting colima [profile=test-net]
INFO[0000] runtime: docker
INFO[0001] creating and starting ... context=vm
INFO[0100] provisioning ... context=docker
INFO[0102] starting ... context=docker
INFO[0209] done
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 52:55:55:ce:b3:5a brd ff:ff:ff:ff:ff:ff
3: col0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 52:55:55:95:bc:04 brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:2d:62:04:ef brd ff:ff:ff:ff:ff:ff
INFO[0000] colima [profile=test-net] is running using QEMU
INFO[0000] arch: x86_64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0001] address: 192.168.106.4
INFO[0001] socket: unix:///Users/[...]/.colima/test-net/docker.sock |
same here. IP address is not showing up for |
M1 Sonoma 14.5 I was able to fix it with the following steps:
|
After having reported here that |
@abiosoft I have just tried The reported error message is |
Description
Attempting to start
--network-address
fails. Additional starts without the flag fail with a different error message. Removing~/.colima
allows for a successful start, without the network address.Version
Colima Version: 0.4.6
Lima Version: 0.12.0, 0.13.0
Qemu Version: 7.1.0
Operating System
Reproduction Steps
colima start --network-address
Expected behaviour
Colima starts correctly.
Additional context
First start:
ha.stderr.log:
Second start:
which is obviously due to the colima.yaml being updated with the
--network-address
flag.The text was updated successfully, but these errors were encountered: