vagrant up hangs for a newly created Fedora 19 box. Can't login?

[Esen Sagynov]

I've successfully created a Fedora 19 x64 box using veewee on RVM but fail to start it with vagrant up. It simply never finishes.

Using veewee 0.3.7, Vagrant 1.2.4 on Mac OS X 10.8.4 (Mountain Lion).

Since the Fedora 19 x64 template is outdated in the veewee release, I've updated it with the latest stable Fedora release download links at Fedora-19-x86_64/definition.rb:

:iso_file => "Fedora-19-x86_64-DVD.iso",
:iso_src => "http://download.fedoraproject.org/pub/fedora/linux/releases/19/Fedora/x86_64/iso/Fedora-19-x86_64-DVD.iso",
:iso_sha1 => "73e45acf91d73146c7a71f7e8ca72762833aeadd",

Then did the following to create the box:

cd veewee
build install
FEDORA_VERSION=19-x86_64
VBOX_VERSION=$(VBoxManage -v | sed 's/\(.*\)r\([0-9]*\)/\1/')
BOX_NAME=fedora-$FEDORA_VERSION-vbox-$VBOX_VERSION
bundle exec veewee vbox define "$BOX_NAME" "Fedora-$FEDORA_VERSION"
bundle exec veewee vbox build "$BOX_NAME"
bundle exec veewee vbox validate "$BOX_NAME"
VBoxManage controlvm "$BOX_NAME" poweroff
vagrant package --base $BOX_NAME --output boxes/$BOX_NAME.box
vagrant box add $BOX_NAME boxes/$BOX_NAME.box
VBoxManage unregistervm $BOX_NAME --delete

Validation, etc. is successful. Then vagrant box list gives the following:

$ vagrant box list
fedora-19-x86_64-vbox-4.2.16 (virtualbox)

When I try to start it up with vagrant up, it hangs at the following:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'fedora-19-x86_64-vbox-4.2.16'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Creating shared folders metadata...
[default] Clearing any previously set network interfaces...
[default] Preparing network interfaces based on configuration...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Running any VM customizations...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.

Nothing happens further on. Moreover, vagrant halt as well as vagrant reload hangs. I suspect Vagrant can't login.

If I check the Virtualbox Preview, it displays the login message.

Any ideas where to look at for the problem?

[Stephen Figgins]

Not sure where to look yet, but the same thing just happened to me.  I still have the virtual box vm I exported to created my vagrant box.  It comes up okay.  I just can't get to the vagrant box. 

[Peter Halliday]

I'm getting this too with a fedora 17 64bit live box that i built from scratch and started with the gui turned on. Seems the networking isn't working as expected. I manually switched to host only network and rebooted then switched back to NAT (with 2222 port forwarding) and now it works. But if I destroy the VM and start it again it stops working again. Still confused :s

[Alvaro Miranda Aguilera]

for fedora, before export/save the box

1.  rm /etc/udev/rules.d/70-persistent-net.rules

2. chkconfig NetworkManager off

3. edit /etc/sysconfig/network-scripts/ifcfg-eth*

you can leave only ifcfg-eth0 and delete all the others, as Vagrant will recreate them

remove UUID
remove HWADDR

ensure NM_CONTROLLED=no is in the file.

and let me know how it goes.

Alvaro.

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Peter Halliday]

I dont have a /etc/udev/rules.d/70-persistent-net.rules file

And the interface is called p2p1 so i changed the config for that one

still no luck though

[Alvaro Miranda Aguilera]

On Fri, Feb 14, 2014 at 12:03 PM, Peter Halliday <pghal...@gmail.com> wrote:

p2p1

hey, that could be the reason..

what version of fedora are you using?

[Peter Halliday]

fedora 17 - I have also tried

systemctl disable NetworkManager.service

instead of chkconfig

but it doesn't make a difference.

This doesn't seem to be a  vagrant problem - I noticed that the original VM won't accept connections either.

I manually added a a forwarded port from 2222 to 22 and then tried

ssh localhost -p 2222

but it just hangs

I verified that sshd is running and can connect from inside the VM to itself with ssh

I also checked the firewall which is on but allowing ssh on port 22 (I also tried disabling the firewall just to be sure)

Also whereas earlier i did get it to respond after messing with the network settings in virtual box, I can no longer reproduce that either :s

[Peter Halliday]

correction i just got it to work by disabling the firewall :s

[Peter Halliday]

and then restarted the firewall and it still works - even after reboot

I did notice that before I restarted the firewall, iptables -L did not list ssh and actually listed mdns or something

It's fixed now and iptables -L lists:

ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh

I restored from the snapshot i took before i started messing with stuff and iptables -L in the broken configuration lists

ACCEPT     udp  --  anywhere             224.0.0.251          state NEW udp dpt:mdns

I then just ran

system-config-firewall

and performed the following sequence to fix the iptables config

disable

apply

enable

apply

I'm going to leave it at that and rebuild my base box :)

[blong]

Hi all, I believe I've resolved the issue that I was having (similar to this thread) and was hoping to get some feedback from someone.  This thread seemed to resolve my problem, but I wanted to try and really pinpoint the error I saw.  It seems pretty clear that a properly configured network is essential to creating a reliable .box file (e.g. this wiki page).  

Here's what I experienced: 

VBoxManage version: 4.3.6r91406

Vagrant version: 1.4.3

CentOS version: 6.4 (Final)

When I run 'vagrant up', I get this output: 

[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.

At this point, 'vagrant ssh' does not work, however, I can login to the VM with the UI.  When I login, I can see that eth0 and eth1 come up with the same IP address (192.168.50.102), although different MAC addresses (eth0 has 08:00:27:60:FC:47 and eth1 08:00:27:67:F8:71) .  Next, I took a look at /etc/sysconfig/network-scripts/ . 

Contents of ifcfg-eth0

DEVICE="eth0"

BOOTPROTO="dhcp"

IPV6INIT="yes"

NM_CONTROLLED="yes"

ONBOOT="yes"

TYPE="Ethernet"

UUID="56f45b3e-..."

Contents of ifcfg-eth1

#VAGRANT-BEGIN

# The contents below are automatically generated by Vagrant. Do not modify.

NM_CONTROLLED=no

BOOTPROTO=none

ONBOOT=yes

IPADDR=192.168.50.102

NETMASK=255.255.255.0

DEVICE=eth1

PEERDNS=no

#VAGRANT=END

I can resolve this one of 2 ways:

1) Simply running "sudo service network restart" from the UI.  This properly configures the network and from then on I'm able to run 'vagrant halt', 'vagrant ssh', etc.

  -or-

2) By fixing the network configuration re-packaging (so that anyone using my .box file can run without issues).  To achieve that, I basically followed Alvaro's earlier email on this thread, however I did a few things differently (in error).  In any case, I published a box file that I believe is configured properly by doing the following : 

1. As root or with sudo :

1. rm /etc/udev/rules.d/70-persistent-net.rules

2. chkconfig NetworkManager off

3. edit /etc/sysconfig/network-scripts/

1. Edit ifcfg-eth0

1. Remove UUID // per Alvaro, but now I'm thinking this wasn't necessary

2. Set NM_CONTROLLED="no"
   

2. Edit ifcfg-eth1

1. Set NM_CONTROLLED="no" // Used the form with double quotes. Does this matter?
   

2. Then, shutdown the VM cleanly and run “vagrant package” to create the .box file.

In Alvaro's email, the instructions say to just remove the eth1 config file and let Vagrant create it. Is that the correct solution, I didn’t follow that as I was concerned Vagrant would not create the ifcfg-eth1 file with NM_CONTROLLED="no". However, one would think that running "sudo chkconfig NetworkManager off" would mean NM_CONTROLLED is ignored, right?

I appreciate any feedback and thanks in advance!

[Alvaro Miranda Aguilera]

Hello,

My suggestion are based in a mix of what I see and what I know. I am a former RedHat Instructor (from rh9 upto rhel5), plus what I do, and I use at home.

(udev rules)

When a fedora or redhat (or his derivates) machine in a *non xen* environment start, in order to have the network cards pinned, it will create the persistent-net file, based on the mac address, this is because you usually ADD more nics in a physical server, so once you have eth0 and eth1, and you add a new nic, to avoid issues, as eth0 and eth1 are pinned, the new ones will become eth2 and so on..

the downside of this, is, when you remove one of the cards, you get holes and you won't be able to use it.. , so you remove the persistent-net file and reboot.

(hwaddr in conf file)

in a total separate side, on each ifcfg-ethN file, you can have HWADDR= to identify the nics, so you can have always the same nic as eth0, even if you add or remove cards.

Think a physical server that have 6 NICs, which one is eth0 when you look from the back? it's prett messy, so you pin them and you are happy.

For virtual machines, this is not required, as the virtual pci bus and the card ware the same, so if you add a new card, will be always at the end.

(network manager)

not all the linux machines are created the same, say you install a redhat 6 with minimal packages, the network manager is not used.. but if later you install group desktop, that will install network manager.. and network manager is more fridnly when you use the machine as desktop and ypou log ove tthe gui, but having a machine that is head less or you use more over the network, NetworkManager can cause more troubles.. one thing I have noticied is sometimes you edit the ifcfg-ethN file, and network manager sense it and try to reset the network and lock you down.. (have happened twice on remove computers I have at home), so best is leave the nics out of network manager.

so, at some point, you need to chose, do all properly, or go for the simple path, and remove what cause troubles.

Hope this helps,
Alvaro