[lxc-devel] [ lxc-Bugs-3388933 ] Script lxc-debian don't create /dev/shm/network
Bugs item #3388933, was opened at 2011-08-09 07:48 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3388933&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexey Vazhnov (vazhnov) Assigned to: Nobody/Anonymous (nobody) Summary: Script lxc-debian don't create /dev/shm/network Initial Comment: Sorry for my English. Host system: Debian6 amd64 lxc 0.7.2-1 I take script lxc-debian from lxc-0.7.4.1 (rename lxc-debian.in to lxc-squeeze and replace all «@LOCALSTATEDIR@» to «/var») because I need Debian squeeze in LXC. When I start lxc: Configuring network interfaces...ifup: failed to open statefile /etc/network/run/ifstate: No such file or directory /etc/network/run/ — symlink to /dev/shm/network Then I run: mkdir /dev/shm/network and problem solved. -- Comment By: Alexandre () Date: 2011-08-15 21:42 Message: I have noticed that, on Debian outside lxc, /etc/network/run is a regular directory, and not a symlink. I think we should look into where this link is created. -- Comment By: Alexey Vazhnov (vazhnov) Date: 2011-08-09 08:47 Message: After guest restarting, directory is absent again. Not so simple :( -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3388933&group_id=163076 -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3411497 ] random veth device MAC addresses cause bridge problems
Bugs item #3411497, was opened at 2011-09-19 14:18 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3411497&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gary Richards () Assigned to: Nobody/Anonymous (nobody) Summary: random veth device MAC addresses cause bridge problems Initial Comment: Hi, I've recently spent some time debugging an LXC test setup. The problem that we were having is that sometimes (not every time) that we started or stopped a container, the host networking would 'freeze' (for want of a better term) for anywhere from 10-30 seconds. To cut a long story short, we eventually realised that the following was happening: - LXC creates a veth device for our container on a random MAC address - LXC adds the veth device into the bridge that we've specified in our configuration - If the MAC address of the veth device in the host (not the MAC address of the virtual device in the container) is 'lower' than the MAC address of the bridge, the bridge would change to this new 'lower' MAC address. Obviously until everything else on the network made new arp requests, it would make it appear as if the networking for the host system had 'frozon'. - The same thing happens when shutting down a container that had a 'lower' MAC address than the bridge original had setup. On removal of the veth device from the bridge, the bridge then realises that it no longer has a device with its MAC address and reconfigures itself with the next 'lowest' MAC address. I looked into why i've never seen this problem with KVM virtual machines (when using similar techniques for their networking). I'm unsure if it's KVM/qemu itself that does this or something in libvirt, but a VM configured with a MAC address of 52:54:aa.bb.cc.dd would get its associated veth device created as fe:54:aa:bb:cc:dd. I assume that they default to using fe:... because it creates the device with a very 'high' numbered MAC address and therefore mostly guards against the problem that I describe above due to all VM veth interfaces coming up with a number that's pretty much guaranteed to be higher than any real device that you might have associated with a bridge. For the time being, we worked around this issue by forcing the MAC address of the bridge to the MAC of the attached real network interface. Gary -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3411497&group_id=163076 -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3411497 ] random veth device MAC addresses cause bridge problems
Bugs item #3411497, was opened at 2011-09-19 10:18 Message generated for change (Comment added) made by mhwarfield You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3411497&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gary Richards () Assigned to: Nobody/Anonymous (nobody) Summary: random veth device MAC addresses cause bridge problems Initial Comment: Hi, I've recently spent some time debugging an LXC test setup. The problem that we were having is that sometimes (not every time) that we started or stopped a container, the host networking would 'freeze' (for want of a better term) for anywhere from 10-30 seconds. To cut a long story short, we eventually realised that the following was happening: - LXC creates a veth device for our container on a random MAC address - LXC adds the veth device into the bridge that we've specified in our configuration - If the MAC address of the veth device in the host (not the MAC address of the virtual device in the container) is 'lower' than the MAC address of the bridge, the bridge would change to this new 'lower' MAC address. Obviously until everything else on the network made new arp requests, it would make it appear as if the networking for the host system had 'frozon'. - The same thing happens when shutting down a container that had a 'lower' MAC address than the bridge original had setup. On removal of the veth device from the bridge, the bridge then realises that it no longer has a device with its MAC address and reconfigures itself with the next 'lowest' MAC address. I looked into why i've never seen this problem with KVM virtual machines (when using similar techniques for their networking). I'm unsure if it's KVM/qemu itself that does this or something in libvirt, but a VM configured with a MAC address of 52:54:aa.bb.cc.dd would get its associated veth device created as fe:54:aa:bb:cc:dd. I assume that they default to using fe:... because it creates the device with a very 'high' numbered MAC address and therefore mostly guards against the problem that I describe above due to all VM veth interfaces coming up with a number that's pretty much guaranteed to be higher than any real device that you might have associated with a bridge. For the time being, we worked around this issue by forcing the MAC address of the bridge to the MAC of the attached real network interface. Gary -- Comment By: Michael H. Warfield (mhwarfield) Date: 2011-09-19 21:07 Message: This is documented and by design in the Linux kernel and applies to all bridges. To avoid it, you have to assign mac addresses higher than that of the host address. Using purely "random" mac addresses has always been a crap shoot. VMware, Virtual Box, and OpenVZ get around this by using a "Vendor ID" field (most of the first 3 bytes) that's higher than most assigned mac vendor codes. I always pick a high vendor code and then assign the lower 3 bytes to a random number (and make sure the 02 bit in the first byte is set and the 01 byte is clear to conform to the mac address standard of setting the locally administered bit and clearing the multicast bit). If you want LXC to assign "random" mac addresses, they will have to be restricted mac addresses and can not be truly 48 bits of random data. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3411497&group_id=163076 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3411497 ] random veth device MAC addresses cause bridge problems
Bugs item #3411497, was opened at 2011-09-19 14:18 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3411497&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gary Richards () Assigned to: Nobody/Anonymous (nobody) Summary: random veth device MAC addresses cause bridge problems Initial Comment: Hi, I've recently spent some time debugging an LXC test setup. The problem that we were having is that sometimes (not every time) that we started or stopped a container, the host networking would 'freeze' (for want of a better term) for anywhere from 10-30 seconds. To cut a long story short, we eventually realised that the following was happening: - LXC creates a veth device for our container on a random MAC address - LXC adds the veth device into the bridge that we've specified in our configuration - If the MAC address of the veth device in the host (not the MAC address of the virtual device in the container) is 'lower' than the MAC address of the bridge, the bridge would change to this new 'lower' MAC address. Obviously until everything else on the network made new arp requests, it would make it appear as if the networking for the host system had 'frozon'. - The same thing happens when shutting down a container that had a 'lower' MAC address than the bridge original had setup. On removal of the veth device from the bridge, the bridge then realises that it no longer has a device with its MAC address and reconfigures itself with the next 'lowest' MAC address. I looked into why i've never seen this problem with KVM virtual machines (when using similar techniques for their networking). I'm unsure if it's KVM/qemu itself that does this or something in libvirt, but a VM configured with a MAC address of 52:54:aa.bb.cc.dd would get its associated veth device created as fe:54:aa:bb:cc:dd. I assume that they default to using fe:... because it creates the device with a very 'high' numbered MAC address and therefore mostly guards against the problem that I describe above due to all VM veth interfaces coming up with a number that's pretty much guaranteed to be higher than any real device that you might have associated with a bridge. For the time being, we worked around this issue by forcing the MAC address of the bridge to the MAC of the attached real network interface. Gary -- Comment By: https://www.google.com/accounts () Date: 2011-10-11 23:13 Message: Here is more info about the issue, incl. fixes for libvirt (KVM/qemu): https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/584048 https://www.redhat.com/archives/libvir-list/2010-July/msg00450.html -- Comment By: Michael H. Warfield (mhwarfield) Date: 2011-09-20 01:07 Message: This is documented and by design in the Linux kernel and applies to all bridges. To avoid it, you have to assign mac addresses higher than that of the host address. Using purely "random" mac addresses has always been a crap shoot. VMware, Virtual Box, and OpenVZ get around this by using a "Vendor ID" field (most of the first 3 bytes) that's higher than most assigned mac vendor codes. I always pick a high vendor code and then assign the lower 3 bytes to a random number (and make sure the 02 bit in the first byte is set and the 01 byte is clear to conform to the mac address standard of setting the locally administered bit and clearing the multicast bit). If you want LXC to assign "random" mac addresses, they will have to be restricted mac addresses and can not be truly 48 bits of random data. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3411497&group_id=163076 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3477687 ] Cannot mount if rootfs is an image
Bugs item #3477687, was opened at 2012-01-23 03:39 Message generated for change (Comment added) made by dennisbirkholz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dennis Birkholz (dennisbirkholz) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot mount if rootfs is an image Initial Comment: I use an image as my lxc rootfs. If i try to mount something via lxc.mount.entry or using a fstab-file with lxc.mount i always get the error 'ignoring mount point XXX'. I dumped rootfs->path in the mount_entry_on_absolute_rootfs-function in conf.c which is set to the name of the image and not to the value of lxc.rootfs.mount so it seems your currently can not use any mount points if your rootfs is an image file. -- >Comment By: Dennis Birkholz (dennisbirkholz) Date: 2012-01-23 03:48 Message: Just for curiosity i used the path of the image instead of the target directory in my mount points and that is working. So the statement in the man page "If the rootfs is an image file or a device block and the fstab is used to mount a point somewhere in this rootfs, the path of the rootfs mount point should be prefixed with the /usr/lib/lxc/root default path or the value of lxc.rootfs.mount if specified." is wrong. -- Comment By: Dennis Birkholz (dennisbirkholz) Date: 2012-01-23 03:42 Message: FYI: i downloaded the 0.7.5 source package and compiled it myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3485741 ] autogen.sh fails with automake-1.11.3
Bugs item #3485741, was opened at 2012-02-08 06:13 Message generated for change (Tracker Item Submitted) made by ahippo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3485741&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Mazo (ahippo) Assigned to: Nobody/Anonymous (nobody) Summary: autogen.sh fails with automake-1.11.3 Initial Comment: Running autogen.sh gives: ./autogen.sh + test -d autom4te.cache + rm -rf autom4te.cache + aclocal -I config + autoheader + autoconf + automake --add-missing --copy src/lxc/Makefile.am:98: `pkglibdir' is not a legitimate directory for `PROGRAMS' src/lxc/Makefile.am:114: variable `lxc_init_SOURCES' is defined but no program or src/lxc/Makefile.am:114: library has `lxc_init' as canonical name (possible typo) + exit 1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3485741&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3485741 ] autogen.sh fails with automake-1.11.3
Bugs item #3485741, was opened at 2012-02-08 06:13 Message generated for change (Comment added) made by ahippo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3485741&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Mazo (ahippo) Assigned to: Nobody/Anonymous (nobody) Summary: autogen.sh fails with automake-1.11.3 Initial Comment: Running autogen.sh gives: ./autogen.sh + test -d autom4te.cache + rm -rf autom4te.cache + aclocal -I config + autoheader + autoconf + automake --add-missing --copy src/lxc/Makefile.am:98: `pkglibdir' is not a legitimate directory for `PROGRAMS' src/lxc/Makefile.am:114: variable `lxc_init_SOURCES' is defined but no program or src/lxc/Makefile.am:114: library has `lxc_init' as canonical name (possible typo) + exit 1 -- Comment By: Andrey Mazo (ahippo) Date: 2012-02-10 04:38 Message: Quite strange, the attached patch applies clearly with patch -p1 and with git am. But ArchLinux patch is absolutely the same and can be applied instead. -- Comment By: Jon Nordby (jonnor) Date: 2012-02-10 04:19 Message: The patch attached here seems to be corrupted or something. Here is a working patch, used in the lxc-git package in ArchLinux. http://pastie.org/private/lgaxgq70teyl9kd35xkbhg -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3485741&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3463349 ] lxc-destroy crosses filesystem boundaries
Bugs item #3463349, was opened at 2011-12-21 04:26 Message generated for change (Comment added) made by dlezcano You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3463349&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Andrea Rota (hotzeplotz) Assigned to: Nobody/Anonymous (nobody) Summary: lxc-destroy crosses filesystem boundaries Initial Comment: if any portions of the host's filesystem are bind-mounted within an LXC container, lxc-destroy will wipe the host's contents under the mounted folders. the proposed straightforward patch below should limit lxc-destroy's action to a single filesystem. this could not be the desired effect if people mount other stuff - not bind-mount - in the container, but in my opinion it's safer to remove the least possible, especially when it comes to bind-mounts that people within a container might not even be aware of. stuff mounted from within the container might need to be treated differently, but at least for the latter information would be available in mtab) >From 85bec9f97091d333656655f5806313edb247af72 Mon Sep 17 00:00:00 2001 From: andrea rota Date: Wed, 21 Dec 2011 12:10:47 + Subject: [PATCH] limit rm to rootfs, avoiding nuking of any bind mounts from the host --- src/lxc/lxc-destroy.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/lxc/lxc-destroy.in b/src/lxc/lxc-destroy.in index dda48e6..c662c1f 100644 --- a/src/lxc/lxc-destroy.in +++ b/src/lxc/lxc-destroy.in @@ -87,4 +87,4 @@ if [ -b $rootdev -o -h $rootdev ]; then fi fi # recursively remove the container to remove old container configuration -rm -rf --preserve-root $lxc_path/$lxc_name +rm -rf --one-file-system --preserve-root $lxc_path/$lxc_name -- 1.7.5.4 -- >Comment By: Daniel Lezcano (dlezcano) Date: 2012-02-15 14:11 Message: Thanks for the fix. It is in the tree. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3463349&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3477687 ] Cannot mount if rootfs is an image
Bugs item #3477687, was opened at 2012-01-23 03:39 Message generated for change (Comment added) made by dlezcano You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dennis Birkholz (dennisbirkholz) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot mount if rootfs is an image Initial Comment: I use an image as my lxc rootfs. If i try to mount something via lxc.mount.entry or using a fstab-file with lxc.mount i always get the error 'ignoring mount point XXX'. I dumped rootfs->path in the mount_entry_on_absolute_rootfs-function in conf.c which is set to the name of the image and not to the value of lxc.rootfs.mount so it seems your currently can not use any mount points if your rootfs is an image file. -- >Comment By: Daniel Lezcano (dlezcano) Date: 2012-02-15 14:10 Message: Yes, that's right. I think the man page is not up-to-date. -- Comment By: Dennis Birkholz (dennisbirkholz) Date: 2012-01-23 03:48 Message: Just for curiosity i used the path of the image instead of the target directory in my mount points and that is working. So the statement in the man page "If the rootfs is an image file or a device block and the fstab is used to mount a point somewhere in this rootfs, the path of the rootfs mount point should be prefixed with the /usr/lib/lxc/root default path or the value of lxc.rootfs.mount if specified." is wrong. -- Comment By: Dennis Birkholz (dennisbirkholz) Date: 2012-01-23 03:42 Message: FYI: i downloaded the 0.7.5 source package and compiled it myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3477687 ] Cannot mount if rootfs is an image
Bugs item #3477687, was opened at 2012-01-23 03:39 Message generated for change (Comment added) made by dennisbirkholz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dennis Birkholz (dennisbirkholz) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot mount if rootfs is an image Initial Comment: I use an image as my lxc rootfs. If i try to mount something via lxc.mount.entry or using a fstab-file with lxc.mount i always get the error 'ignoring mount point XXX'. I dumped rootfs->path in the mount_entry_on_absolute_rootfs-function in conf.c which is set to the name of the image and not to the value of lxc.rootfs.mount so it seems your currently can not use any mount points if your rootfs is an image file. -- >Comment By: Dennis Birkholz (dennisbirkholz) Date: 2012-01-23 03:42 Message: FYI: i downloaded the 0.7.5 source package and compiled it myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3477687 ] Cannot mount if rootfs is an image
Bugs item #3477687, was opened at 2012-01-23 03:39 Message generated for change (Tracker Item Submitted) made by dennisbirkholz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dennis Birkholz (dennisbirkholz) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot mount if rootfs is an image Initial Comment: I use an image as my lxc rootfs. If i try to mount something via lxc.mount.entry or using a fstab-file with lxc.mount i always get the error 'ignoring mount point XXX'. I dumped rootfs->path in the mount_entry_on_absolute_rootfs-function in conf.c which is set to the name of the image and not to the value of lxc.rootfs.mount so it seems your currently can not use any mount points if your rootfs is an image file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3477687&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3483542 ] Physical WIFI NIC gets renamed on container start
Bugs item #3483542, was opened at 2012-02-02 22:24 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3483542&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: netns Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://me.yahoo.com/a/wZWnCDI8 () Assigned to: Nobody/Anonymous (nobody) Summary: Physical WIFI NIC gets renamed on container start Initial Comment: Having a config like so lxc.network.type = phys lxc.network.link = wlan0 lxc.network.name = wifi0 will cause the link on the host to be renamed upon container start. When then container is stopped, the link will not be renamed to its original name. Doing so using ip link set wifi0 name wlan0 and then trying to ifup wlan0 again, will no longer work on the host, the interface seems to be disfunct. AFAIK, only a reboot helps to get the card working again. I do not know whether this is also true for non wireless adapters (this one is a an external usb card using a realtek 8191 chipset). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3483542&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3483542 ] Physical WIFI NIC gets renamed on container start
Bugs item #3483542, was opened at 2012-02-02 22:24 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3483542&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: netns Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: https://me.yahoo.com/a/wZWnCDI8 () Assigned to: Nobody/Anonymous (nobody) Summary: Physical WIFI NIC gets renamed on container start Initial Comment: Having a config like so lxc.network.type = phys lxc.network.link = wlan0 lxc.network.name = wifi0 will cause the link on the host to be renamed upon container start. When then container is stopped, the link will not be renamed to its original name. Doing so using ip link set wifi0 name wlan0 and then trying to ifup wlan0 again, will no longer work on the host, the interface seems to be disfunct. AFAIK, only a reboot helps to get the card working again. I do not know whether this is also true for non wireless adapters (this one is a an external usb card using a realtek 8191 chipset). -- >Comment By: https://me.yahoo.com/a/wZWnCDI8 () Date: 2012-02-03 12:58 Message: Duplicate of #3198796. Will close as duplicate. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3483542&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3485741 ] autogen.sh fails with automake-1.11.3
Bugs item #3485741, was opened at 2012-02-08 06:13 Message generated for change (Comment added) made by jonnor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3485741&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrey Mazo (ahippo) Assigned to: Nobody/Anonymous (nobody) Summary: autogen.sh fails with automake-1.11.3 Initial Comment: Running autogen.sh gives: ./autogen.sh + test -d autom4te.cache + rm -rf autom4te.cache + aclocal -I config + autoheader + autoconf + automake --add-missing --copy src/lxc/Makefile.am:98: `pkglibdir' is not a legitimate directory for `PROGRAMS' src/lxc/Makefile.am:114: variable `lxc_init_SOURCES' is defined but no program or src/lxc/Makefile.am:114: library has `lxc_init' as canonical name (possible typo) + exit 1 -- Comment By: Jon Nordby (jonnor) Date: 2012-02-10 04:19 Message: The patch attached here seems to be corrupted or something. Here is a working patch, used in the lxc-git package in ArchLinux. http://pastie.org/private/lgaxgq70teyl9kd35xkbhg -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3485741&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3483548 ] Unable to connect via external USB wireless adapter
Bugs item #3483548, was opened at 2012-02-02 22:38 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3483548&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://me.yahoo.com/a/wZWnCDI8 () Assigned to: Nobody/Anonymous (nobody) Summary: Unable to connect via external USB wireless adapter Initial Comment: Having a config like so lxc.network.type = phys lxc.network.flags = up lxc.network.link = wlan0 lxc.network.name = wlan0 and, on the guest side a properly configured wpa_supplicant.conf and in /etc/network/interfaces a configuration like so auto wlan0 iface wlan0 inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf And then, upon networking start in the guest, the system will try to contact the DHCP server, but it will never receive any leases. In fact, the wlan0 interface seems to be disfunct. The interface itself was down when starting the guest. The same happens when the interface was already brought up on the host. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3483548&group_id=163076 -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3605123 ] Failed to umount 'dev/pts' when running lxc-execute
Bugs item #3605123, was opened at 2013-02-17 14:56 Message generated for change (Tracker Item Submitted) made by rjmccabe3701 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3605123&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: rmccabe3701 (rjmccabe3701) Assigned to: Nobody/Anonymous (nobody) Summary: Failed to umount 'dev/pts' when running lxc-execute Initial Comment: I am running Fedora 17 with LXC version 7.5 and lxc-execute stopped working: [root@rmccabe]# echo "lxc.pts = 128" > /tmp/lxc.conf [root@rmccabe]# lxc-execute -f /tmp/lxc.conf --name test /bin/bash lxc-execute: Device or resource busy - failed to umount 'dev/pts' lxc-execute: failed to setup the new pts instance lxc-execute: failed to setup the container lxc-execute: invalid sequence number 1. expected 2 lxc-execute: failed to spawn 'test' This looks to be the bug described on https://bugzilla.redhat.com/show_bug.cgi?id=824909. It seems the problem has something do with an update to util-linux which supposedly fixed a bug with mount, but must have exposed a bug in LXC Here is my package versions: [root@emane2 1]# rpm -q lxc lxc-libs util-linux lxc-0.7.5-1.fc17.x86_64 lxc-libs-0.7.5-1.fc17.x86_64 util-linux-2.21.2-3.fc17.x86_64 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3605123&group_id=163076 -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3610837 ] lxc-execute hangs with interactive shell
Bugs item #3610837, was opened at 2013-04-14 07:46 Message generated for change (Tracker Item Submitted) made by sm111 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3610837&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: lxc cli Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Somnath (sm111) Assigned to: Nobody/Anonymous (nobody) Summary: lxc-execute hangs with interactive shell Initial Comment: When lxc-execute is issued with a non-interactive shell it works fine. / # cd tmp /tmp # cat > lxc.conf << EOF > lxc.utsname = beta > lxc.network.type = empty > lxc.rootfs = / > EOF /tmp # lxc-execute -n foobar -f lxc.conf -l info -o output -- echo "Hello World" Hello World But when it is issued with an interactive shell it just hangs: /tmp # lxc-execute -n foobar -f lxc.conf -l info -o output -- /bin/sh / # lxc-execute: Input/output error - failed to read I am running lxc version 0.9.0 on ARM Cortex A9 Linux 3.6.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3610837&group_id=163076 -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3612432 ] LXC 0.9.0 fails to build on CentOS6 if -Werror is used
Bugs item #3612432, was opened at 2013-05-01 12:07 Message generated for change (Tracker Item Submitted) made by robbiesz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Szabo (robbiesz) Assigned to: Nobody/Anonymous (nobody) Summary: LXC 0.9.0 fails to build on CentOS6 if -Werror is used Initial Comment: Compilation on CentOS6 (gcc 4.4.6) fails with these two errors: gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-conf.o -MD -MP -MF .deps/liblxc_so-conf.Tpo -c -o liblxc_so-conf.o `test -f 'conf.c' || echo './'`conf.c cc1: warnings being treated as errors conf.c: In function 'setup_caps': conf.c:1725: warning: comparison is always false due to limited range of data type conf.c:1725: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-conf.o] Error 1 AND gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-caps.o -MD -MP -MF .deps/liblxc_so-caps.Tpo -c -o liblxc_so-caps.o `test -f 'caps.c' || echo './'`caps.c cc1: warnings being treated as errors caps.c: In function '_real_caps_last_cap': caps.c:204: warning: comparison is always false due to limited range of data type caps.c:204: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-caps.o] Error 1 Configuration options: $ ./configure --prefix=/software/lxc/0.9.0/linux.centos6.x86_64 --with-pic --disable-apparmor --with-config-path=/var/lib/lxc --with-rootfs-path=/var/lib/lxc/rootfs --disable-doc The attached patch attempts fix these errors by changing the variable type to 'long'. Rob -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3612432 ] LXC 0.9.0 fails to build on CentOS6 if -Werror is used
Bugs item #3612432, was opened at 2013-05-01 12:07 Message generated for change (Settings changed) made by robbiesz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: liblxc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Robert Szabo (robbiesz) Assigned to: Nobody/Anonymous (nobody) Summary: LXC 0.9.0 fails to build on CentOS6 if -Werror is used Initial Comment: Compilation on CentOS6 (gcc 4.4.6) fails with these two errors: gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-conf.o -MD -MP -MF .deps/liblxc_so-conf.Tpo -c -o liblxc_so-conf.o `test -f 'conf.c' || echo './'`conf.c cc1: warnings being treated as errors conf.c: In function 'setup_caps': conf.c:1725: warning: comparison is always false due to limited range of data type conf.c:1725: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-conf.o] Error 1 AND gcc -DHAVE_CONFIG_H -I. -I../../src-fPIC -DPIC -I../../src -DLXCROOTFSMOUNT=\"/var/lib/lxc/rootfs\" -DLXCPATH=\"/var/lib/lxc\" -DLXC_GLOBAL_CONF=\"/software/lxc/0.9.0/linux.centos6.x86_64/etc/lxc/lxc.conf\" -DLXCINITDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/libexec\" -DLXCTEMPLATEDIR=\"/software/lxc/0.9.0/linux.centos6.x86_64/share/lxc/templates\" -DLOGPATH=\"/software/lxc/0.9.0/linux.centos6.x86_64/var/log/lxc\"-g -O2 -Wall -Werror -MT liblxc_so-caps.o -MD -MP -MF .deps/liblxc_so-caps.Tpo -c -o liblxc_so-caps.o `test -f 'caps.c' || echo './'`caps.c cc1: warnings being treated as errors caps.c: In function '_real_caps_last_cap': caps.c:204: warning: comparison is always false due to limited range of data type caps.c:204: warning: comparison is always false due to limited range of data type make[4]: *** [liblxc_so-caps.o] Error 1 Configuration options: $ ./configure --prefix=/software/lxc/0.9.0/linux.centos6.x86_64 --with-pic --disable-apparmor --with-config-path=/var/lib/lxc --with-rootfs-path=/var/lib/lxc/rootfs --disable-doc The attached patch attempts fix these errors by changing the variable type to 'long'. Rob -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3612432&group_id=163076 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
[lxc-devel] [ lxc-Bugs-3611609 ] Configuration files are comment-location sensative
Bugs item #3611609, was opened at 2013-04-22 14:38 Message generated for change (Tracker Item Submitted) made by marphod You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3611609&group_id=163076 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: liblxc Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Galen G. Brownsmith (marphod) Assigned to: Nobody/Anonymous (nobody) Summary: Configuration files are comment-location sensative Initial Comment: Platform: CentOS6.4, with a 3.8.8 Xen-enabled Kernel (kernel-xen repository) LXC Version: 0.8.0-rc2 (rpmforge repository) Command line: lxc-start -n centos-template -l DEBUG -o start.log The entire content of the error log was (set at DEBUG) when starting the container: lxc-start 135027.366 ERRORlxc_confile - Success - invalid ipv4 broadcast address: 192.168.253.9 lxc-start 135027.366 ERRORlxc_start_ui - failed to read configuration file (The logging level of the first line is a separate issue, but problematic. Probably should be NOTICE or INFO) In the end, I discovered that the lines in my config file that were problematic were lxc.network.hwaddr=4A:59:43:49:30:BF # REMEMBER TO CHANGE FOR EACH INSTANCE lxc.network.ipv4=192.168.253.9/24# REMEMBER TO CHANGE FOR EACH INSTANCE It did not matter where in the config file these lines were located (that is, it didn't matter if there were valid config lines following or preceeding these lines). Removing the comment (or moving it to its own line) was sufficient to fix the problem. (I'm guessing that this is liblxc, rather than some other category. It could quite possibly be a bug in a 3rd party tool used to parse the config files.) (summary: config files, probably low priority, probably should document if not fixed.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=826303&aid=3611609&group_id=163076 -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
