unable to provision using several providers on Arm64/Apple Silicon M3 chip #2727
Labels
Comments
|
So this is an issue in vagrant itself rather than VVV, I encountered it and made a PR upstream so a new release of vagrant should fix this ( 2.4.2 most likely but it hasn't been released yet ). As for how I resolved this, it involved removing docker networks, Note that this only impacts the Docker provider, other providers are unaffected. Also remember that vagrant will always stick to the provider of the current VM, even if you change your mind. So if you start with a docker provider, you'll need to destroy that VM before you can switch to Parallels/etc |
I'm happy VMWare got at least that far, support for VMWare is spotty at best though, nobody working on VVV uses it but if we try and deprecate or remove support people complain as they still use it. A full copy of the provisioner log for VMWare would be helpful though, happy to try and fix issues with VMWare but it might mean you need to help test since I can't verify a fix works at my end.
Those look like the VM has DNS issues, configuring the VM internally to use a 3rd party DNS server such as |
No problem, here's the full VMWare provision log: |
Do you maybe have a link to your PR so I can ask the vagrant folks if that's going to be released here at some point soon? Is it this issue? I wonder if doing a bleeding edge build of vagrant from source would have this modification included?
Unfortunately, |
I tried setting the DNS to `1.1.1.1` as suggested using the following commands...Then added Tried reprovisioning and got stuck at a weird mysql root password error... |
I SSHed in and reset the MariaDB root password using `sudo mysqladmin -u root password root` and reprovisioned and it did fully provision, although I did this error in the provision:I reprovisioned again and didn't get the error trying to connect to mirror.rackspace.com. Everything looks good on the surface but I can't access any sites in a web browser, including |
Surprising but I see rackspace have more issues with their mariadb mirror again in your log output >_<
Can you check https://mariadb.gb.ssimn.org/repo/10.5/ubuntu and let me know how quickly that loads for you? Is it super slow or is it a reasonable loading time? I'm assuming from the username you're in an American timezone? The network check used to halt provisioning but it seems that some people could provision even with it failing, we had someone pop up with rackspace Apt issues a few days ago which resolved on their own.
That's the issue, my PR to fix it got merged but looking at what was already there someone else had tried fixing it for another reason and that hadn't been released either. hashicorp/vagrant#13339 (comment) seems to diagnose the issue better and reveal the root causes, and also implies downgrading docker to <v25 might also be a solution though I'm loathe to do that. You could also apply the change directly to the vagrant gem ruby files which is how I debugged the issue though that's more of a hack ( albeit one that gets stuff working ) Given 2.4.1 was in January it's been quite a while for a 2.4.2 release
Their release page should have a 2.4.2 dev build so you shouldn't have to build from source, here's one from July https://github.com/hashicorp/vagrant/releases/tag/2.4.2.dev%2B000038-26a1ff10
|
|
For VMWare this was what failed the provisioning during the Nginx package install: Currently we mount that folder and others like this: # The VMware Provider does not understand "dmode"/"fmode" in the "mount_options" as
# those are specific to Virtualbox. The folder is therefore overridden with one that
# uses corresponding VMware mount options.
config.vm.provider :vmware_desktop do |_v, override|
override.vm.synced_folder 'www/', '/srv/www', owner: 'vagrant', group: 'www-data', mount_options: ['umask=002']
override.vm.synced_folder 'log/memcached', '/var/log/memcached', owner: 'root', create: true, group: 'root', mount_options: ['umask=000']
override.vm.synced_folder 'log/nginx', '/var/log/nginx', owner: 'root', create: true, group: 'root', mount_options: ['umask=000']
override.vm.synced_folder 'log/php', '/var/log/php', create: true, owner: 'root', group: 'root', mount_options: ['umask=000']
override.vm.synced_folder 'log/provisioners', '/var/log/provisioners', create: true, owner: 'root', group: 'root', mount_options: ['umask=000']I wonder if it's the owner/group or the umask that needs changing for that. Also curious if VMWare is running the Arm64 box or if it's using x86 + Rosetta 2 or transpiling on the fly |
I changed the all of the umasks to `777` just to give it a shot and my provision failed:I also tried changing the owner and group to provisioner-main.logprovisioner-tools.log
Here's what Activity Monitor is reporting: 
I believe |
I'm loaded the URL at either ~650-800 ms or ~170 ms (assuming these requests are cached) in a Chrome browser. Yes, I am in the Pacific time zone on the west coast of the United States. |
How do I upgrade vagrant to the 2.4.2 build with this
|
That change helped, have you tried doing that to the other mounts?
The |
I changed all owner/group fields in the provisioner-main.logprovisioner-tools.log |
I edited that driver file (saved myself a lot of time going through the build process) with the edit you mentioned and reprovisioned my docker provision and it appears to have booted normally. This looks like the route to take. You have been such a giant help, @tomjn; thank you so sincerely. |
|
One issue did come up when I fire up the box: It has an issue restarting a couple of services. When I SSH into the box and try to reload any process, I get this notice that > systemctl status nginx
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is downDoes this box use something besides |
|
I provisioned a fresh VVV instance with Docker on a Mac running on an Intel processor and it provisioned fine after making the same change to the vagrant@vvv:~$ systemctl reload nginx
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is downThe |
|
that won't be a problem with the image since the image doesn't come with Nginx, that image comes from https://github.com/pentatonicfunk/docker-vagrant-ubuntu-base-images it's goal is to get a base container image we can run provisioners in. #2687 tries to bundle the dockerfile so we don't need the dependency but it takes longer to provision as it has to build the image each time. It's unlikely this has a docker based solution and it's more likely that Nginx inside the VM is not installed properly for unknown reasons
|
|
You won't find it on Hashicorps box catalog because it's a container image not a box: https://hub.docker.com/r/pentatonicfunk/vagrant-ubuntu-base-images |
|
So what now? If nothing else, I thought I could have at least gotten a VVV box to run on Parallels on an Apple Silicon processor. I mean, I guess I could still use the Docker box for testing/development without the ability to control system processes with |
|
Most VVV users have no idea what systemd is, nor should you need to. Nginx should start and stop without any intervention. Is Nginx installed inside the VM and available in path? Have you tried instead using the |
|
As for Parallels I lost track of where you got up to in the above, I thought you ran into a DNS issue, resolved it then had root password issue that you fixed |
|
#2728 should swap out the rackspace servers and upgrade to MariaDB 10.11 These commands output should prove interesting if not outright useful: sudo service nginx startsudo nginx -t |
It'll boot fine, but nothing comes up for The |
|
What do you get instead for vvv.test? Sometimes duplicates from older provisions can cause issues, do the site provisioner logs say anything about their nginx configs? |
Just an ERR_CONNECTION_REFUSED error: 
Here are last Parallels provision logs (I don't see any nginx errors): provisioner-tools.logprovisioner-site-wordpress-one.logprovisioner-site-wordpress-two.logprovisioner-main.logprovisioner-extension-source-core.logprovisioner-extension-core-tls-ca.logprovisioner-extension-core-phpmyadmin.logprovisioner-dashboard.log |
|
hmm usually that happens if you've still got left over entries in the hosts file from another VVV with a different IP |
I agree, which is why it's so odd that there isn't. I'm giving up on Parallels for now and continuing my focus on Docker. |
|
It still would be so much better of an experience with my Docker setup if I could get |
|
what packages are those? Systemd on a docker container is rare, not to say you couldn't install it manually but that isn't ideal |
|
Sure, I'll give you one I failed to get running on my Docker-provisioned box: Elasticsearch. After installing, it couldn't find the service with I haven't extensively fired up a lot of Docker containers so I didn't realize this was a rarity. Why wouldn't Systemd work in that environment? Is there possibly an alternative box that runs Systemd properly I could base my provision off of? It is clearly installed in the box because it wouldn't fire back with that kind of error if it wasn't, it just happens to not be working properly. Reinstalling Systemd didn't make it work. I don't know what alternative to Systemd is running; I don't see grub or upstart installed on the box. |
|
Let me ask you this, @tomjn - if you happen to be running VVV on an Apple M-series processor, what setup are you using? |
|
I did use Parallels but I'm currently on a docker provisioned instance. MacOS Sonoma 14.5/M1 Pro/Docker 27.1.1 |
|
Docker has been my most successful attempt in an arm64 processor environment. I would have used Parallels if I could have gotten it to work. I never could find a way to install Elasticsearch in this environment, which something I have always been able to do in VVV running on virtualbox. Now I'm getting a provision error via docker. It seems it can't find this package: Full provision log
�[0;38;5;2m ▷ Running the �[0m�[1m�[0;38;5;5m'main'�[21m�[0;38;5;2m provisioner...�[0m�[0m�[0m
Is there something I can do to correct this provision issue? |
|
that looks like it's unrelated to VVV provisioners, I'm guessing you added that source and tried to install systemd manually? Looking at http://ppa.launchpad.net/pitti/systemd/ubuntu/dists/ there's no Fundamentally systemd is there to start and end the services, but it's not the only way of doing it. I don't have a nice neat answer for how you would start and stop elastic without systemd though, I can say that the automatic starting and stopping of MariaDB is something that isn't quite working, and that there are scripts that run on |
|
Though in theory you shouldn't need a custom apt source to install systemd, wouldn't |
|
I had tried the logical Not sure what my ongoing issue with certain services not reloading are, and I don't know how much it actually ends up mattering either. |
|
I personally think this is an acceptable fix for the issue of multiple service restarts not working when vvv_info " * Restarting Nginx"
- sudo service nginx restart
+ sudo service nginx status > /dev/null && sudo service nginx restart || sudo service nginx start
vvv_info " * Restarting MariaDB"
- sudo service mariadb restart
+ sudo service mariadb status > /dev/null && sudo service mariadb restart || sudo service mariadb start
vvv_info " * Restarting PHP-FPM"
find /etc/init.d/ -name "php*-fpm" -exec bash -c 'sudo service "$(basename "$0")" restart' {} \;
vvv_info " * Restarting Memcache"
- sudo service memcached restart
+ sudo service memcached status > /dev/null && sudo service memcached restart || sudo service memcached startIt checks if the service is running, reloads if it is and starts it if it isn't. Solved the issue on my end. |
|
That looks good, happy to merge that into VVV for the next release |
|
@columbian-chris can you give #2732 a test? It changes how services are started, and might even speed up some of the scripts a tiny bit. I also noticed what you were using triggered a shellcheck warning where both clauses of the logic might run despite the first returning success |
|
I did a fresh clone and fetched the Provision log |
|
Are you able to reach mariadb.gb.ssimn.org in a browser? That looks like network connectivity issues unrelated to the service command changes |
4 tasks
|
I can reach it in a browser and I can also successfully ping it when I get into the box via SSH. |
|
hmm I added it to the network checks in #2734 and removed the rackspace and nodesource references |
|
Can you perform a traceroute for |
|
Just to note, I had install traceroute via traceroute for 149.102.129.233 outside the boxtraceroute for mariadb.gb.ssimn.org outside the boxtraceroute for 149.102.129.233 inside the boxtraceroute for mariadb.gb.ssimn.org inside the box |
|
hmmm, the new mariadb mirror seems more reliable in the sense that packages don't go missing randomly, but I've noticed some of the github CI has started failing with connection errors similar to what you're seeing. Finding a MariaDB mirror that works for everyone is proving to be a bit of a pain in the arse. I think it's time to take another look at the list Also, a PR was merged into the |
|
@columbian-chris would you be willing to test out using the OVH mirror? https://mariadb.org/download/?t=repo-config&d=20.04+%22focal%22&v=10.11&r_m=ovh It'd involve replacing the contents of |
|
Sure, I destroyed my last box to create a fresh provision, made the edit to that file, then provisioned. Here's my `provisioner-main.log` log (let me know if you want to see the other logs and well and I'll post them).Sidenote, do you know which encoding these log files are saved in? I keep posting them and they appear in this thread with a bunch of annoying characters (that most of the time I've deleted before posting) and I tried opening the logs in a every encoding I could but was unable to find one that would render them properly. |
I don't think a fresh instance was needed but this log looks more successful than the others you've posted
But if you were to |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
What was The Command Used To Provision
Using only an out of the box clone from this VVV GitHub repository with no customizations and using default config.
What Kind of VVV Provision Was This
This was a fresh install
Logs/What Broke
Trying to install with Docker via
vagrant up --provision --provider="docker"resulted in this:Trying to provision with Parallels via
vagrant up --provision --provider="parallels"resulted in this:And then finally attempting to provision with VMWare via
vagrant up --provision --provider="vmware_desktop"resulted with this:I thought at least one of these would work now that I'm on an Apple Silicon machine and no longer am able to use virtualbox.
Your Environment
VVV: v3.14
Ruby: 3.1.4
git develop branch, commit 8f4eaaa
Platform: darwin shell:/bin/zsh shared_db_folder_disabled
Vagrant: v2.4.1
Parallels: v19.4.1
VMWare: Fusion Professional Version 13.5.2 (23775688)
Docker Desktop: v4.33.0 (160616), Engine: 27.1.1
MacBook with Apple M3 Max chip
MacOS Sonoma 14.6.1 (23G93)
The text was updated successfully, but these errors were encountered: