lxc-attach error

[lucasfs7]

Hi

I'm using vagrant-lxc on Arch Linux. I followed all steps on #123 and gr I run vagrant up I get this error:

There was an error executing lxc-attach

For more information on the failure, enable detailed logging by setting
the environment variable VAGRANT_LOG to DEBUG.

do anyone have any idea about this error?

[fgrehm]

Please run a vagrant destroy to start fresh and then a VAGRANT_LOG=debug vagrant up --provider=lxc. That will output A LOT of stuff and it will help me out identifying what might be going on with your setup. Once it errors out, please create a gist and send a link to it on this issue and I'll have a look :-)

[lucasfs7]

thanks,

I did it like you said and here is the gist.

[fgrehm]

Thanks for the gist, as I expected your problem is related to the container networking. I'm still figuring out how to properly set up an archlinux host so I can't help you out that much at this time =/

Improved docs for hosts other than ubuntu and improving the networking related code it is top my priority after cutting a new alpha release. I'll keep you posted!

[lucasfs7]

Ok, thank you. I'll try to figure out something too.

[imobachgs]

I guess that you've solved your problem some days ago, but just for the records... I've just installed libvirt (including the recommended dependencies) and it takes care of setting up the network (you only need to enable the «default» network using virsh).

Take into account that, by default, libvirt uses virbr0 as you bridge interface (an not br0 or lxcbr0), so you must update your /etc/lxc/default.conf for it to work.

Regards,
Imo

[lucasfs7]

@Imobach what do you mean with enable the <<default>> network using virsh?

[imobachgs]

@lucasfs7 As root, try:

# virsh net-autostart default

So the default libvirt network will be enabled: a new interface virbr0 will be created and your vagrant machines could take an IP using DHCP.

I hope it helps!

[tuminoid]

I'm hitting this as well by using fgrehm/centos-6-64-lxc from VagrantCloud/Atlas.
Container will never be ready as lxc-attach fail and then it enters endless lxc-info loop.

Gist: https://gist.github.com/tuminoid/137f1b4431e89fb36fd3

[kupferk]

I also had a similar problem with Fedora 21 as my host computer. It turned out vagrant-lxc was not able to deteermine the IP address, because of two reasons:

1. The mac address of eth0 of the container cannot be determined, so the method defined in fetch_ip_from_dnsmasq_leases.rb does not work.
2. For some reasons, it seems that obtaining an IP address via DHCP takes a little bit longer than expected, so fetch_ip_with_lxc_attach.rb fails because it effectively times out.

I could temporarily fix the problem simply by increasing the timeout and the repeat count in fetch_ip_with_lxc_attach.rb. Maybe it would help to make this value configurable?

[jchv]

I've found using the libvirt virbr0 adapter to work when literally everything else was failing. Don't know how much of this is necessary, but here's how I got where I am:

sudo pacman -Sy libvirt bridge-utils
sudo systemctl enable libvirtd.service libvirt-guests.service
sudo systemctl start libvirtd.service libvirt-guests.service
sudo virsh net-autostart default

Then set my /etc/lxc/default.conf to the following:

lxc.network.type = veth
lxc.network.link = virbr0
lxc.network.ipv4 = 0.0.0.0/24

I hope some day the networking stuff is a bit more straight forward, but for now it seems piggybacking off of the libvirt stuff is a solid solution.

[bear0330]

@johnwchadwick It works for me on CentOS 7 (of course, use yum).

[Ramblurr]

In Fedora 21 I'm also running into this issue. I've got the libvirt interface setup, however the problem persists.

 INFO subprocess: Starting process: ["/usr/bin/sudo", "/usr/share/vagrant/gems/gems/vagrant-lxc-1.1.0/scripts/vagrant-lxc-wrapper", "lxc-attach", "--name", "VVVlxc_default_1424875316936_46758", "--namespaces", "'NETWORK|MOUNT'", "--", "/sbin/ip", "-4", "addr", "show", "scope", "global", "eth0"]

What do you put in your Vagrantfile for network setup?

[hak8or]

INFO subprocess: Starting process: ["/usr/bin/sudo", "/usr/local/bin/vagrant-lxc-wrapper", "lxc-info", "--name", "vagrant_lxc_main_1425790244109_48867"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stderr: /usr/local/bin/vagrant-lxc-wrapper:34: warning: Insecure world writable dir /home/hak8or in PATH, mode 040777
DEBUG subprocess: stdout: Name:           vagrant_lxc_main_1425790244109_48867
DEBUG subprocess: stdout: State:          RUNNING
DEBUG subprocess: stdout: PID:            5952
DEBUG subprocess: stdout: CPU use:        0.93 seconds
DEBUG subprocess: stdout: BlkIO use:      160.00 KiB
DEBUG subprocess: stdout: Memory use:     3.48 MiB
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
DEBUG fetch_ip_from_dnsmasq_leases: Attempting to load ip from dnsmasq leases (mac: )
DEBUG fetch_ip_from_dnsmasq_leases: 
DEBUG fetch_ip_from_dnsmasq_leases: Ip could not be parsed from dnsmasq leases file
 INFO subprocess: Starting process: ["/usr/bin/sudo", "/usr/local/bin/vagrant-lxc-wrapper", "lxc-info", "--name", "vagrant_lxc_main_1425790244109_48867"]
DEBUG subprocess: Selecting on IO

I was doing what @johnwchadwick said here on Arch Linux but it seems that the service doesn't start.

sudo systemctl status libvirtd.service libvirt-guests.service
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Sun 2015-03-08 00:05:08 EST; 16min ago
     Docs: man:libvirtd(8)
           http://libvirt.org
  Process: 10399 ExecStart=/usr/bin/libvirtd $LIBVIRTD_ARGS (code=exited, status=0/SUCCESS)
 Main PID: 10399 (code=exited, status=0/SUCCESS)

Mar 08 00:05:07 angstrom libvirtd[10399]: libvirt version: 1.2.13
Mar 08 00:05:07 angstrom libvirtd[10399]: Cannot check dnsmasq binary /sbin/dnsmasq: No such file or directory
Mar 08 00:05:08 angstrom libvirtd[10399]: direct firewall backend requested, but /sbin/ebtables is not available: No such file or directory
Mar 08 00:05:08 angstrom libvirtd[10399]: out of memory
Mar 08 00:05:08 angstrom libvirtd[10399]: internal error: Failed to find path for dmidecode binary
Mar 08 00:05:08 angstrom libvirtd[10399]: invalid argument: Failed to parse group 'kvm'
Mar 08 00:05:08 angstrom libvirtd[10399]: Initialization of QEMU state driver failed: invalid argument: Failed to parse group 'kvm'
Mar 08 00:05:08 angstrom libvirtd[10399]: Driver state initialization failed

● libvirt-guests.service - Suspend Active Libvirt Guests
   Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled; vendor preset: disabled)
   Active: active (exited) since Sun 2015-03-08 00:05:07 EST; 16min ago
     Docs: man:libvirtd(8)
           http://libvirt.org
  Process: 10412 ExecStart=/usr/lib/libvirt/libvirt-guests.sh start (code=exited, status=0/SUCCESS)
 Main PID: 10412 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/libvirt-guests.service

Turns out that the services won't start due to this bug so you need to edit your /etc/libvirt/qemu.conf file and comment out group="kvm".

But then you need to handle the ... firewall backend requested, but /sbin/ebtables is not ava out of memory issue, which can be fixed as per here.

Alright, but now etables needs to be fixed, luckily here says just to install ebtables so doing a yaourt -S ebtables installs it.

And ... damn, need dnsmasq too, and dmidecode! Throw in a yaourt -S dnsmasq dmidecode and lets try this again.

~/vagrant_lxc ❯❯❯ vagrant ssh
 INFO global: Vagrant version: 1.7.2
 INFO global: Ruby version: 2.0.0
 INFO global: RubyGems version: 2.0.14
 INFO global: VAGRANT_EXECUTABLE="/opt/vagrant/bin/../embedded/gems/gems/vagrant-1.7.2/bin/vagrant"
 INFO global: VAGRANT_LOG="DEBUG"
 INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/opt/vagrant/bin/../embedded"
....
DEBUG ssh: Checking key permissions: /home/hak8or/vagrant_lxc/.vagrant/machines/main/lxc/private_key
 INFO ssh: Invoking SSH: ["[email protected]", "-p", "22", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "LogLevel=FATAL", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentitiesOnly=yes", "-i", "/home/hak8or/vagrant_lxc/.vagrant/machines/main/lxc/private_key"]
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.18.6-1-ARCH x86_64)

 * Documentation:  https://help.ubuntu.com/
vagrant@vagrant-base-trusty-amd64:~$

Booyeah! Works! So, thanks @johnwchadwick for the fix and all you vagrant-lxc people for making this!

So, in short, what I did was:

• Edit your /etc/libvirt/qemu.conf file and comment out group="kvm".
• Install what's needed by doing yaourt -S ebtables dnsmasq dmidecode
• Do a vagrant destroy
• Restart arch, do a vagrant up and viola, it works!

[sej7278]

getting the same problem on debian jessie. running the command manually seems to show its a namespaces issue:

sudo /usr/local/bin/vagrant-lxc-wrapper lxc-attach --name precise-lxc_default_1436783368668_80763 --namespaces 'NETWORK|MOUNT' -- /sbin/ip -4 addr show scope global eth0
sh: 1: MOUNT: not found

[enricostano]

Hi there, any news about this? I'm getting the same error on Arch Linux. Ping me if you need more debug info. Thanks!

[globin]

@enricostano could you run VAGRANT_LOG=debug vagrant up for more debug information.

Just a note: me and @fpletz are on holiday atm and at least I have quite poor internet connectivity so don't necessarily expect us to respond very fast.

[trojkat]

Full debug log from debian sid:
https://gist.github.com/trojkat/c41009debaa515188f44

I get the same sh: 1: MOUNT: not found error as @sej7278 while doing lxc-attach in console.

Edit: using libvirt instead of lxc-net script works.

[ghost]

Now that we use lxc-info -iH to get IP information and thus offload that complexity to LXC directly, maybe that the issue is fixed or at least changed in nature. Maybe it's time to revisit this?

[fgrehm]

Yeah, I don't remember what exactly lxc-attach is used anymore for but it is about time that we "modernize" the plugin (this has been around since pre 1.0) so I'd be fine with delegating to lxc-info as much as we can 😄

[fgrehm]

Hey, sorry for the silence here but this project is looking for maintainers 😅

As per #499, I've added the ignored label and will close this issue. Thanks for the interest in the project and LMK if you want to step up and take ownership of this project on that other issue 👋