I am trying to get a virtual machine working with Vagrant. Everything seems to run fine and it begins to unpack/install all the needed files. But every single time it just stalls when I get to this point.
==> default: Setting up grub-pc (2.02~beta2-36ubuntu3.11) ...
Here is a screen shot of what is going on:
I shut down the virtual machine and booted it back up. I can ssh into it but nothing seems to work. By this I mean there is no psql, no SQLAlchemy. These, among other things, are supposed to be set up in the VM. It seems as if it halts before installing the necessary software.
I've tried vagrant destroy and reinstalling, downloading a new image in case that one was corrupt and I tried reinstalling Vagrant. I am running Vagrant 1.9.5
Looks like you're provisioning with shell commands. I'm guessing that there's some sort of install prompt that's coming up and demanding some sort of user interaction / response. Because vagrant's handling the provisioning behind the scenes, you can't respond to the prompt and the install is not continuing.
You should be able to fix the issue by editing your Vagrantfile. As a guess, it looks like grub-pc is causing the issue (there's actually a grub-pc command prompt in the image you shared). See if you can figure out which package is installing grub-pc. If you're lucky, the problem can be solved by piping in a yes along with the install command (which will automatically answer yes to all install questions). This looks something like yes | sudo apt-get install grub-pc. If grub-pc is being installed as part of another package, you'll need to do some educated guessing to figure out which package is installing it and adding the yes | apt-get pipe to that install line (or just add the pipe before every install line).
This being said, I ran into an issue when I was installing the Java SDK on vagrant, where Oracle was demanding I accept their terms of use before the install would complete and a yes pipe wouldn't solve the issue. I was able to fix it by searching the web for "silent java sdk install via command line". If you can figure out which package is causing the issue, and a yes pipe isn't enough, searching for how to "silently" install that package via command line should help.
UPDATE
As you can see in a comment on this answer
Unfortunately a yes pip didn't do the trick this time but a quick
search on how to "silently" install grub led me to this.
DEBIAN_FRONTEND=noninteractive apt-get -y -o
Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold"
upgrade . After editing my Vagrant file it worked perfectly
Related
While trying to use Laravel's Homestead environment, I had to install vagrant and virtualbox.
I already had an older version of Virtualbox.
uninstalled it and installed a new one, then installed Vagrant.
While trying to start my virtual machine I've got a well known issue:
For the past 2 days I've tried EVERYTHING
I've tried
sudo /sbin/vboxconfig
which didn't work, So as suggested in a few posts, I've disabled secure boot from the BIOS.
It still didn't work.
I've tried every type of uninstalling with apt, apt-get and dpkg for everything that includes "virtualbox" in it's package name. Also purged, autoremove and autoclean everything possible.
I've checked the lists and seems like I'm all clean of virtualbox.
But when I'm installing it again directly from the VB website with an installer (version 6.1) it happens again and again.
Funny thing is that no matter how much I clean or purge, whenever I'm installing it again, all my virtual machines are still there. meaning there's still something I'm missing...
Please help. Thanks a LOT!
I've read just about everything about it including:
https://askubuntu.com/questions/1163267/virtual-box-works-no-longer-suspect-a-kernel-update-caused-this
http://mitreasorin.blogspot.com/2016/08/upgrade-virtualbox-rtr3initex-failed.html
https://forums.virtualbox.org/viewtopic.php?f=7&t=79035
Unable to start Vagrant VirtualBox on Ubuntu
https://askubuntu.com/questions/1163267/virtual-box-works-no-longer-suspect-a-kernel-update-caused-this
https://forums.linuxmint.com/viewtopic.php?t=292858 (for /sbin/vboxconfig that didn't work)
https://forum.manjaro.org/t/virtualbox-not-working-cant-rmmod-vboxdrv/86277
And a lot more. too many to mention, it's just about repeating the same things.
So I am having some issues with vagrant. I had initially tried to report this as an issue on the vagrant github issue boards, but they kept closing the issues without responding to them. I guess they decided I wasn't worth their time, or they were just behaving unprofessionally. Anyway, Here is the problem: I use vagrant with virtualbox, and a new version of virtualbox was recently released that is, unfortunately, not compatible with the latest vagrant installation.
However, the people at hashicorp have already updated the source code so that it is compatible with the new version of virtualbox, but you have to build the vagrant executable from the source repo (instructions here). So I followed the instructions and vagrant is working just like it used to.....when the only command I need to run is vagrant up. I should also mention ahead of time that, in order to run the vagrant dev build, the current working directory needs to be the root of the source code repo and the dev build can only be run using the following command with ruby:
bundle exec vagrant
With that being said, I needed to update one of my custom boxes, so I built a vm in the updated version of virtualbox and ran the below command
bundle exec vagrant package --base go --vagrantfile ../../vagrant/vagrantfile
After an extended period of time, vagrant spat back out the following error
The executable 'bsdtar' Vagrant is trying to run was not found in the %PATH% variable. This is an `error. Please verify this software is installed and on the path.`
I should also note that I use a windows machine and that this error never occurred when using the installed version of vagrant. At this point, I had posted the issue on github to get some input from the devs, but they (very unprofessionally) decided to ignore my requests for help and close the issues without providing any response. I used the GNUwin32 project to make numerous unix commands available to my Windows environment and added the folder to my PATH environment variable. I then run the same command again to create my new box and it works!! So then I upload it to the vagrant cloud and attempt to update the vagrant box that is stored on my system by running the following command:
bundle exec vagrant box update
Then, after waiting for a while, vagrant then spat this error out at me:
The box failed to unpackage properly. Please verify that the box
file you're trying to add is not corrupted and that enough disk space
is available and then try again.
The output from attempting to unpackage (if any):
C:\gnuwin32\bin/bsdtar.EXE: invalid option -- s
Usage:
List: bsdtar.EXE -tf <archive-filename>
Extract: bsdtar.EXE -xf <archive-filename>
Create: bsdtar.EXE -cf <archive-filename> [filenames...]
Help: bsdtar.EXE --help
Another error, and still involving this bsdtar tool. It does not appear that anyone else is reporting the issue I am running into because I think they are just waiting for hashicorp to release the new official installation, but, just to give you a look into their priorities, the version of virtualbox that was released which no longer worked with vagrant was released back on December 10. It has been over a month since and there is still no updated release.
So, I am hoping that someone out there might be able to find out why I keep running into these errors when trying to use vagrant's dev build and provide a solution. If not, then maybe if someone else is able to reproduce the issue and report it to hashicorp, maybe they will listen to someone else.
If you are on Ubuntu 20.04 then bsdtar was removed. Try to install libarchive-tools package.
$ sudo apt-get install libarchive-tools
I figured it out. My original hypothesis was correct: since vagrant is a tool that was built primarily to be run on linux machines, then vagrant runs in windows, the installation includes a mingw environment with all of the dependencies vagrant needs to function and which the installed vagrant executable imports into the console session when run. This why the dev build kept failing: because it was not importing this mingw environment. So, in order to fix the issue, I first cloned the vagrant source code repo from github and followed the instructions I linked to above to build the executable from the source repo. I then copied all of the files in the source repo into the following folder:
<hashicorp install folder root>\Vagrant\embedded\gems\2.2.6\gems\vagrant-<version num>
So, for me, the destination directory is C:\HashiCorp\Vagrant\embedded\gems\2.2.6\gems\vagrant-2.2.6
This directory is identical to the source code repo, and copying the source code repo to the above folder replaces the installation version of vagrant with the dev build. After I did this, running the vagrant commands which had failed previously normally (as in, without using ruby or bundle) worked. I hope this helps someone else out there who Hashicorp has decided is not worth their time.
We started seeing some strange errors in our logs that normally appear when ruby isn't compiled properly with OpenSSL. But it's inconcistent...
We're getting errors like:
RuntimeError: Unsupported digest algorithm (SHA256). (also with other digests, like sha1). example error trace
Faraday::SSLError (SSL_CTX_new: (null)) example error trace
We managed to reproduce it when starting unicorn using service unicorn start or systemctl start unicorn. But only with some requests... Not all of them. Some requests that use OpenSSL under the hood do work. Others don't.
However, when we start unicorn with /etc/init.d/unicorn start, everything works without a hitch. (to clarify, systemd starts the same /etc/init.d script)
We tried debugging ENV vars, user permissions, file/dir ownership, recompile ruby, bootstrap a new server from scratch... Nothing seems to help.
In case this helps:
unicorn init.d script
unicorn.rb
What are we missing? What can we try that we haven't thought of?
UPDATE 1
output of some debug commands, e.g. OpenSSL, ruby etc
PATH is being set inside the init.d script
unicorn is being executed via su into www-data user
The same problem happens when we use this unicorn.service file in /etc/systemd/system
We're running Ubuntu 16.04 on Gcloud
Ruby was not installed via apt (explicitly removed, in case platform came pre-installed) and compiled from scratch. We're currently running 2.3.4 and tried also 2.3.6. Compiled either manually or using ruby-build. No rbenv, nor RVM.
We install libssl-dev via apt (we're running apt-get install -y autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev before building ruby)
UPDATE 2
We're using a scripted/repeatable build process for the VM (using fabric), and this problem is consistent on multiple VMs we bootstrapped on GCloud. We then tried a VM on DigitalOcean with the same bootstrap scripts, and the problem doesn't seem to appear there.
In both cases we picked Ubuntu 16.04 64bit base image, but obviously there are some differences with kernel versions, base installed packages etc...
UPDATE 3
The problem simply vanished. See my answer below.
#gingerlime I had a similar situation with our Jenkins on GCP, we're using ChefDK 3.1.0 (ruby embeed 2.5.1p57) -- tried other also, over a Jenkins that was running over systemd (Ubuntu 16.04) and upstart (Ubuntu 14.04) -- we tried on both versions, right now running over 16.04 in 4.15.0-1023-gcp kernel version, running a few jobs with kitchen-docker and this problem always emerge in a few situations.
I digged into and found that this only happens when the Etc.getlogin class gets called (for me here), this doesn't return any error, it return the correct info, the correct type of the class (String), but once it gets a call, the Unsupported digest algorithm gets raised.
If I start the process manually by root or jenkins user, this problem doesn't happen. I tried to implement the Etc.getlogin in several different ways, like using ENV['USER'], a fixed String, or other classes from Etc, like getpwuid, simulating the return class and values from Etc.getlogin, and the error doesn't get raised.
I'm not sure if this is some bug related to the ruby version and the custom kernel that GCP instances uses, but it happens in a similar situation like yours, and for me, the Etc.getlogin was the problem. Right now, I fixed by using a custom configuration that doesn't gets the call from this function, and it's working normally.
One option is that this isn't an issue of sysVinit vs systemd at all, but you just haven't triggered the issue with your sysVinit script yet.
When you run your svsVinit script through the systemctl command it's going through a compatibility layer, and there may be a problem there. Your problem would be simplified both yourself and for us if you reproduced the issue directly with a systemd service file and shared that file.
You mentioned debugging ENV, but didn't mention exactly what you checked in the ENV. This is definitely one place where systemd could make a difference. As seen in man systemd.exec, systemd sets $PATH in the environment to a fixed value:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
If this is not exactly the same as when run directly as an sysVinit script, that could be an issue.
I would also check for all your copies of SSL on the system. Do you have more than one? Where? Do you have more than copy of the ruby openssl module loaded?
locate -r lib/.*libssl.*so
Also see the answer to the FAQ: Why do things behave differently under systemd?
(also posted on this github issue)
It looks like the problem just vanished. We were testing and reproducing it consistently, across several Compute Engine instances on Google Cloud. Under certain conditions (unicorn / puma started by systemd, etc), it was completely reproducible both with our own rails app, and with a plain vanilla rails app we've set for testing purposes. It was reproducible across several ruby versions as well (we tested 2.3.4, 2.3.6 and 2.5.0).
Suddenly, all instances that were consistently failing started working without exhibiting these problems. Like it never existed. We didn't even reboot some of those instances, and we saw no evidence of any unattended upgrades taking place... We also had one snapshot of a system that had this problem, and that we can reliably reproduce on. Creating an instance from this snapshot stopped exhibiting it as well from that specific point in time a few hours ago.
We're totally confused as to what might have cause it, and what might have made it disappear... However, without being able to reproduce it now, I guess there's no point leaving this issue open, so will close it. Chalk it up to Deus ex machina I suppose. (perhaps the google support gods, but they haven't reported anything back to us yet)
Currently have an issue where i can not enable the ldap module in homestead. I have changed multiple php.ini files and still nothing seems to be working. Has anyone else had issues with enabling modules in homestead?
Side note: when trying to restart php-fpm i am getting a permission denied issue. They prompt me with a password (which i have tried "secret") but still cant seem to get that to work either.
Have restarted the homestead instance multiple times as well. no prevail.
any thoughts?
Citti
I think this question deserves its own answer as it's pretty easy to install the wrong version of ldap on homestead and not know why things aren't working.
TL;DR: Match the version of ldap to the version of php you're running & install with apt-get.
For example, running homestead v.6.1.0:
cd HOMESTEADFOLDER # on your host
vagrant ssh # access the guest machine
sudo apt-get update # update apt-get package list
sudo apt-get install php7.1-ldap # or whatever version
In my example above, if you switch out php7.1-ldap for php7.0-ldap everything appears to install correctly (it does in fact install correctly) but, in reality, you've installed the module to a version of php that's not actually running. It took me several attempts at rebooting FPM to figure out this is what I had done.
Side note: apt-get will restart php and reload modules so there's no need to try and reboot the server or mess about with .ini files.
While ssh-ed in to the guest machine, you can check that the package is installed with php -m
If ldap is a thing your project needs, it's probably a better idea to handle this in a script. The answer referenced by fh-jashmore in his comment above comment has a simple but solid example: How to automatically enable php extensions in Homestead on vagrant up
I have inherited a cheffed OSX machine running chef-client 11.14.6. I am trying to lay my hands on the installer for 11.14.6, but it seems that Chef have pulled it from the downloads site ( https://downloads.chef.io/chef-client/mac/ ).
Does anyone know anything about this, or know where I can get "archived" version?
Much appreciated.
I don't see any copies in any repos so it's probably lost to the mists of time by now. You should be able to build a new one using this commit from omnibus-chef https://github.com/chef/omnibus-chef/tree/6d5001c588edacc98f6045e22c70195200111660
Yes. From my research, and the research of others. It seems as if it has been removed.
However, we (I can't take the credit - it was one of my colleagues :) ) managed to get it working. We had another machine with the correct version on it, so we grabbed it from there and zipped it up (using root as the base, and grabbing /opt/chef).
Once tarball (e.g. opt.chef-11.14.6.tar.gz) is transferred to new machine, these were the steps used:
install chef-client v11.10.4 using:
(echo "version=11.10.4"; curl -L https://www.opscode.com/chef/install.sh) | sudo bash
verify your chef-client version is currently reported as 11.10.4 with "chef-client -v"
extract the tarball as root into the root filesystem using:
cd / && tar xvfz /tmp/opt.chef-11.14.6.tar.gz
verify your chef-client version is now reported as 11.16.4 with "chef-client -v"
run your knife bootstrap command like normal, but don't include the --bootstrap-version parameter, it'll detect chef-client is already installed and use the one you have installed manually.
I did not try rebuilding it.