Problem
I was working with bento/centos7.2 box. I did a vagrant up and while it was booting up, I noticed the box has an update and I instinctively cancelled the operation (which I suggest not to do, ever!). So I went ahead and did vagrant destroy, rm -rf .vagrantjust to be sure (Again, I suggest not to do, ever!). I removed my box by vagrant box remove bento/centos7.2 and did vagrant up and ended up with this:
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
Environment
Ubuntu 16.04
Vagrant 1.81
Centos 7.2 Box
Things I tried
Following are the threads I have tried:
vagrant + virtualbox Timed out while waiting for the machine to boot
Timed out while waiting for the machine to boot when vagrant up
Vagrant "Timed out while waiting for the machine to boot."
When I enabled the GUI, I realized the box is booting up properly; it's just stuck at login screen(bug in box with ssh?). Screenshot:
Any help is much appreciated.
There are multiple possibilities that cause this issue:
Try running:
vagrant reload
This re-installs the guest-additions on the box.
Try opening Virtualbox (GUI interface) and the open the virtualbox (console). The box might for example be
i) waiting for fsck (filesystem check) if it was shutdown uncleanly
ii) login to the box over Virtualbox GUI by using the default username/password (typically vagrant/vagrant) and figure out is the ssh server running on the box or not.
Run
vagrant ssh-config
and see to what port and by which ssh key it is trying to use. Use them manually e.g.:
ssh -i <identity_key_location> vagrant#localhost -p 2222
Related
I have Cywgin running on a windows VM and I'm having problems keeping a stable SSHD service running.
The issue is that file permissions on the /etc/ssh_host_ecdsa_key, /$home/.ssh etc directories are being randomly reset so SSH connections are refused because I am using strict mode. When I stop the SSHD service, reset all the file and folder permissions to 700, restart SSHD, SSH connections work fine until they apparently randomly stop and sure enough all the relevant sshd directory and file permissions are reset.
Has anyone encountered this problem before and know a possible solution?
In case somebody is researching a similar issue, the problem was due to instability on the VMs C drive after hibernating, logging off etc.
The solution was instead of installing Cywgin directly on the VM, install Cywgin a separate networked drive mounted on the VM. Works perfectly and no more instability issues.
I have gentoo(linux) host machine. On which, I have Virtualbox 4.3.28 and vagrant 1.4.3 installed(these are the latest available version for gentoo).
On vagrant up, the Ubuntu 14.04 gets launched. I'm also able to ssh to Ubuntu. But then as soon as it gets launched I get the following error. Below is my Vagrantfile and output error.
P.S I have created Ubuntu 14.04 base box from scratch
-----------Vagrantfile-------------
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure(2) do |config|
config.vm.box = "Ubuntu"
config.vm.boot_timeout = "700"
config.vm.provider :virtualbox do |vb|
vb.gui = true
end
end
-----------Output in terminal------------
Bringing machine 'default' up with 'virtualbox' provider...
[default] Clearing any previously set forwarded ports...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
**
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period. This can
mean a number of things.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.**
Any solution to fix this problem?
P.S I have created Ubuntu 14.04 base box from scratch
That could be the missing piece - When you package a box, you need to run a few commands as explained below
It is very common for Linux-based boxes to fail to boot initially.
This is often a very confusing experience because it is unclear why it
is happening. The most common case is because there are persistent
network device udev rules in place that need to be reset for the new
virtual machine. To avoid this issue, remove all the persistent-net
rules. On Ubuntu, these are the steps necessary to do this:
$ rm /etc/udev/rules.d/70-persistent-net.rules
$ mkdir /etc/udev/rules.d/70-persistent-net.rules
$ rm -rf /dev/.udev/
$ rm /lib/udev/rules.d/75-persistent-net-generator.rules
Can you make sure to run the command above before packaging the box.
So, I tried to set up a public SMB share with Samba on CentOS 7. Now, I have it set up, and I have a headache. But, sweet victory. I'm posting this here for all y'all so that you don't need to waste your time. It's actually easy, you just need to know the hoops you need to jump through. I'll also edit the Samba wiki.
The first problem was that it wouldn't connect at all, except locally:
Remote Connection (my Linux desktop):
-------
[root#my-desktop ~]# smbclient //sambaserver/PublicDocs -N
Error connecting to 192.168.100.97 (No route to host)
Connection to cgybkp01 failed (Error NT_STATUS_HOST_UNREACHABLE)
On Windows 8, using Windows Explorer, after typing "\\sambaserver" into the address bar, the progress bar would wait, wait, wait, then time out. The error message was:
Remote Connection (my Windows 8 desktop):
Windows cannot access \\sambaserver
Check the spelling of the name. Otherwise, there might be a problem with your network. To
try to identify and resolve network problems, click Diagnose.
This ended up being a problem with firewalld. To unblock Samba, I needed to add this line to /etc/firewalld/zones/public.xml :
<service name="samba"/>
Perfect, now I can connect!
But, I was actually mounting an NFS share, so I had one more issue, with SELinux. Now, when I attempt to connect with smbclient...
smbclient //sambaserver/PublicDocs -N
I can connect, but when I try to ls, I get the error: "NT_STATUS_ACCESS_DENIED" in CentOS 7. So, how do I connect?
The first thing everyone recommended that I try was file permissions. If you're not familiar with file permissions in Linux, I'd recommend trying those first. But for me, that didn't work, because SELinux was blocking me.
To see all of the SELinux options for Samba, type:
getsebool -a | grep samba
getsebool -a | grep smb
The one I needed to change was samba_share_nfs, because I was sharing an NFS mounted directory:
setsebool -P samba_share_nfs on
CentOS maintains a list of these booleans here.
I am trying to use putty and XMing to run programs from my Fedora 20. I used this configuration before on other machines and I was able to run GUI programs on Linux and display them in my windows 7. But this time I have trouble and get the "cannot connect to X server" error when I try to launch kwrite and kdesvn which are GUI programs in Fedora 20. The connections were good. And the XMing server was running and the X11 forwarding was enabled in putty, like the instruction here.
From my another Fedora 20 machine, I was able to connect to and run GUI programs from the target machine with ssh -X and the same username. So I am thinking the settings of the target machine was right.
Then what else I can try? how to figure out where the problem is?
Ensure that X11 forwarding is enabled in /etc/sshd_config.
X11Forwarding yes
Ensure in your home directory that you have an .Xauthority file. Permissions should be set 0600. If the file does not exist create it.
touch ~/.Xauthority
chmod 0600 ~/.Xauthority
As was previous stated first make sure that X11 forwarding is enabled in PuTTY.
Config > Connection > SSH > X11 > Enable X11 Forwarding. Based on your question it appears you already did this. Make sure you save this config.
I had a problem much like this, what happened to me was that my DISPLAY was being set elsewhere. If you can, try opening a new settion via putty from the same Windows machine using another user and then checking the display and testing your GUI programs
Another thing would be to use your own user but remove any custom work you may have done in your configuration, login fresh, check the DISPLAY and then test X
Did you enable X11 in putty?
It's under SSH | X11 | Enable X11 Forwarding
Then save the putty profile and click on session | save | open
Should work perfectly after you make those changes.
I recently start to use Vagrant (and recently move to Ubuntu from Windows too). My goal to understand fundamentals of vagrant ssh.
So, I'm trying to understand what vagrant ssh actually does.
I've read What does vagrant ssh actually do?, but I haven't understood anything.
I'll try to explain with an example:
The first time, I connect into the vagrant machine by ssh vagrant#192.168.0.x and typing the password.
Next, I configure the keypair and connect into guest by ssh vagrant#192.168.0.x without typing password.
Next, I try to understand how vagrant implements SSH into its own guest machine:
In /etc/ssh/sshd_config, I set PasswordAuthentication no, but vagrant ssh still works
Delete insecure_private_key placed in ~/.vagrant.d on the host machine, but vagrant restores it and vagrant ssh still works.
Remove openssh-server in the vagrant machine and now vagrant ssh really doesn't work :)
Please could anybody in plain English explain me how vagrant implements vagrant ssh?
Update: Vagrant Docs: SSH explains actually what I need.
May be I didn't get the point of your question, but I'll try to explain you the main differences between vagrant ssh and ssh.
vagrant ssh is actually the same as a normal ssh, but there are several differences between them:
port which ssh-client tries to access;
private key that ssh-client uses for authentication;
hosts-key is switched off for vagrant so you will not get initial message "The host is unknown";
other minor differences.
If you know the port where vagrant runs, and know where is the private key that vagrant uses,
you can use ssh instead of vagrant ssh.