I've recently started at a new job, and I'm fortunate enough to have a new M1 Macbook Air. I'd heard from the wider community that everything "just...
For further actions, you may consider blocking this person and/or reporting abuse
I don't have a “/sys/fs/cgroup” folder on my Mac m1 and I believe this is giving me an error because if I leave the volume line out it starts up normally. This is the error:
Command: ["docker", "run", "--name", "project_default_1623498440", "-d", "-p", "0.0.0.0🔢80", "-p", "5678:8080", "-p", "6000:1433", "-p", "6001:3306", "-p", "5432:1080", "-p", "127.0.0.1:2222:22", "--privileged", "b6cedafbcc778e04751de4e9d489d598a097c9e8032a2cd8518e9a4fe43bbb9f", {:notify=>[:stdout, :stderr]}]
Stderr: docker: Error response from daemon: OCI runtime create failed: invalid mount {Destination:[ Type:bind Source:/var/lib/docker/volumes/12fac82322215174e740bef9cd4f05ef753399de075f0f650dbe2e3d3e673ccb/_data Options:[rbind]}: mount destination [ not absolute: unknown.
Could this really be the cause of it or is it something else?
Hi, it looks like there's a bug in the script I posted. The quote marks around that part
"/sys/fs/cgroup"were the wrong kind (the curly kind like“, instead of the kind you use in code like"). Not sure how that happened, sorry! If you fix that up it should work.I am having the same problem! Could you fix it?
I just left the line out and it ran correctly, but if that is not a good idea for you, maybe this might help you
github.com/moby/moby/issues/30723
Hi Ingrid, I've left a comment on how to fix that issue above. I've also fixed it in the article.
I've updated the Dockerfile to comment out the line
VOLUME [ "/sys/fs/cgroup" ]. Initially I somehow had the wrong syntax for that line which seems to have just ignored it. Locally mine works without that line so I think it's unnecessary.Thanks for sharing Ben. I use Vagrant too out of necessity rather than convenience with the current state of ARM/Apple Silicon support.
"Vagrant doesn't like to run multiple boxes"
This section isn't really clear to me.
Is
vagrant box remove <box_name>not working? But since a vagrant box isn't required, then maybe Docker (desktop) is more useful for pruning/deleting.How about running
vagrant destroy -f <vm_name>before making changes to the Vagrantfile? AFAIK vagrant commands read this file on execution. So it takes extra caution when to do changes or at least comment out some lines on the Vagrantfile, destroy the vm, then make the changes on Vagrantfile, and run vagrant again.I'm not sure I understood this correctly. No errors presented here as well. Perhaps a log should lead you somewhere.
Some places I look for and things I do for clues,
--debugflag.vagrant/machines/<vm_name>/<provider>/**/*.logBut then again, Docker and Vagrant are two different species. So you are always on the edge.
What happened was my Vagrantfile was setup to run using Virtualbox, but I didn't have it on my machine. Vagrant created the box but then errored out. It wasn't able to destroy the box because Virtualbox wouldn't run. It was just one of those awkward scenarios where tools expect certain pre-requisites.
Hey! This was awesome!
Any idea on how to solve a non responsive ssh connection? At first creation it works great, but when I do vagrant halt and then vagrant up it is unable to ssh reconnect, and vagrant ssh delivers nothing.
I'm not sure sorry! I'd guess that sshd is stopping, but I'm not sure why that would be. I found that if I took down this box it wouldn't come up, so I would just recreate it instead. This is not really a setup I would recommend, rather something I had to do to get an existing project to work!
For me
vagrant reloadworks.Very very very good article, THANK YOU!!
Using this docker plugin, we have to configure the provision only on
Dockerfileor we still can add provision commands onVagrantfile?