[Lxc-users] How are pseudorandom MACs selected?
For each lxc.network.type = veth, if you DON'T specify an lxc.network.hwaddr, you get one assigned at random (example below). Are these assignments made from a reserved range (a la 169.254/16 in IPv4), or are they randomized across the entire address space? AFAICT, it MUST be the latter. Further, when manually allocating a static hwaddr (so I can map it to an IP within the DHCP server), is there any particular range I should avoid or stick to? For example, it wouldn't surprise me if some hardware/software did things like hmm, your MAC indicates you're from vendor, and I know vendor doesn't implement jumbo frames correctly, so I won't send you any -- which could result in bizarro issues because my container isn't actually a vendor NIC. # ip -o l | grep veth | tr '\\' '\n' | grep link/ether | sort link/ether 06:f7:5a:69:b8:e5 brd ff:ff:ff:ff:ff:ff link/ether 12:89:2b:60:81:36 brd ff:ff:ff:ff:ff:ff link/ether 1a:be:07:cb:81:50 brd ff:ff:ff:ff:ff:ff link/ether 2e:ea:93:ef:0b:9a brd ff:ff:ff:ff:ff:ff link/ether 46:aa:11:c4:94:ef brd ff:ff:ff:ff:ff:ff link/ether 72:1e:8e:08:7b:e2 brd ff:ff:ff:ff:ff:ff link/ether 7a:24:c3:dc:20:d4 brd ff:ff:ff:ff:ff:ff link/ether 82:53:b7:5d:85:64 brd ff:ff:ff:ff:ff:ff link/ether 86:f8:a4:a6:b0:03 brd ff:ff:ff:ff:ff:ff link/ether 96:b8:59:76:66:02 brd ff:ff:ff:ff:ff:ff link/ether c2:f3:df:47:e4:10 brd ff:ff:ff:ff:ff:ff link/ether d6:df:18:81:12:c1 brd ff:ff:ff:ff:ff:ff link/ether e6:41:f1:ee:7b:0f brd ff:ff:ff:ff:ff:ff link/ether ea:99:00:37:d3:e8 brd ff:ff:ff:ff:ff:ff -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] How are pseudorandom MACs selected?
t...@cybersource.com.au (Trent W. Buck) writes: Further, when manually allocating a static hwaddr (so I can map it to an IP within the DHCP server), is there any particular range I should avoid or stick to? On further reading, I see there are apparently reserved address regions for private use: Universally administered and locally administered addresses are distinguished by setting the second least significant bit of the most significant byte of the address. If the bit is 0, the address is universally administered. If it is 1, the address is locally administered. In the example address 06-00-00-00-00-01 the most significant byte is 06 (hex), the binary form of which is 0110, where the second least significant bit is 1. Therefore, it is a locally administered address.^[4] Consequently, this bit is 0 in all OUIs. If the least significant bit of the most significant octet of an address is set to 0 (zero), the frame is meant to reach only one receiving NIC.^[5] This type of transmission is called unicast. A unicast frame is transmitted to all nodes within the collision domain, which typically ends at the nearest network switch or router. Only the node with the matching hardware MAC address will accept the frame; network frames with non-matching MAC-addresses are ignored, http://en.wikipedia.org/wiki/Mac_address Thus, when setting lxc.network.hwaddr, I should pick a locally- administered unicast address, i.e. one of x2:xx:xx:xx:xx:xx x6:xx:xx:xx:xx:xx xA:xx:xx:xx:xx:xx xE:xx:xx:xx:xx:xx So I might as well start at 02:00:00:00:00:00 and increment by one per container, and the only problem that should occur is if my equipment moves to another ethernet network and its admin chose the same addresses for HIS equipment. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] getting output from lxc-start?
On 02/02/2011 01:15 AM, Trent W. Buck wrote: Daniel Lezcanodaniel.lezc...@free.fr writes: On 02/01/2011 12:04 PM, Dean Mao wrote: Hi, I've been messing around with trying to get the output of lxc-start into a file some. I know that lxc-start produces a log file, as well as the ability to fetch the dmesg file directly from the container's log file directory, but I was curious if it was possible to just run lxc-start in a nohup and use some kind of dummy getty instance to pipe the output into a file. The closest thing I could find was using screen's logging capability. The log file produced by lxc-start doesn't really resemble the output generated from the container boot. Is there dummy getty/terminal thing that I could get the actual output of the container boot process? Ok, I just realize I forget to commit the patch to output the console to a file :) Uh, lxc-start -s lxc.console=/var/log/lxc/foo.console works for me, as at 0.7.3. Gah ! Right, forget this option too :D -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] How are pseudorandom MACs selected?
On 02/02/2011 10:26 AM, Trent W. Buck wrote:
For each lxc.network.type = veth, if you DON'T specify an
lxc.network.hwaddr, you get one assigned at random (example below).
Are these assignments made from a reserved range (a la 169.254/16 in
IPv4), or are they randomized across the entire address space? AFAICT,
it MUST be the latter.
Further, when manually allocating a static hwaddr (so I can map it to an
IP within the DHCP server),
The dhcp relies on an identifier to map the IP, the default is to use
the mac address but you can use another identifier like the hostname for
example. AFAIR, there is an option in the system network configuration
scripts to send the hostname for the dhcp requests.
is there any particular range I should avoid
or stick to?
This is how the kernel allocates the mac address.
/**
* random_ether_addr - Generate software assigned random Ethernet address
* @addr: Pointer to a six-byte array containing the Ethernet address
*
* Generate a random Ethernet address (MAC) that is not multicast
* and has the local assigned bit set.
*/
static inline void random_ether_addr(u8 *addr)
{
get_random_bytes (addr, ETH_ALEN);
addr [0] = 0xfe; /* clear multicast bit */
addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
}
Maybe you can use the mac address range used for the virtual nic of vmware.
Another solution would be to buy a cheaper nic, get its mac address,
break and drop the nic :)
For example, it wouldn't surprise me if some hardware/software did
things like hmm, your MAC indicates you're fromvendor, and I know
vendor doesn't implement jumbo frames correctly, so I won't send you
any -- which could result in bizarro issues because my container isn't
actually avendor NIC.
# ip -o l | grep veth | tr '\\' '\n' | grep link/ether | sort
link/ether 06:f7:5a:69:b8:e5 brd ff:ff:ff:ff:ff:ff
link/ether 12:89:2b:60:81:36 brd ff:ff:ff:ff:ff:ff
link/ether 1a:be:07:cb:81:50 brd ff:ff:ff:ff:ff:ff
link/ether 2e:ea:93:ef:0b:9a brd ff:ff:ff:ff:ff:ff
link/ether 46:aa:11:c4:94:ef brd ff:ff:ff:ff:ff:ff
link/ether 72:1e:8e:08:7b:e2 brd ff:ff:ff:ff:ff:ff
link/ether 7a:24:c3:dc:20:d4 brd ff:ff:ff:ff:ff:ff
link/ether 82:53:b7:5d:85:64 brd ff:ff:ff:ff:ff:ff
link/ether 86:f8:a4:a6:b0:03 brd ff:ff:ff:ff:ff:ff
link/ether 96:b8:59:76:66:02 brd ff:ff:ff:ff:ff:ff
link/ether c2:f3:df:47:e4:10 brd ff:ff:ff:ff:ff:ff
link/ether d6:df:18:81:12:c1 brd ff:ff:ff:ff:ff:ff
link/ether e6:41:f1:ee:7b:0f brd ff:ff:ff:ff:ff:ff
link/ether ea:99:00:37:d3:e8 brd ff:ff:ff:ff:ff:ff
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] How are pseudorandom MACs selected?
On 2/2/2011 6:20 AM, Daniel Lezcano wrote:
On 02/02/2011 10:26 AM, Trent W. Buck wrote:
For each lxc.network.type = veth, if you DON'T specify an
lxc.network.hwaddr, you get one assigned at random (example below).
Are these assignments made from a reserved range (a la 169.254/16 in
IPv4), or are they randomized across the entire address space? AFAICT,
it MUST be the latter.
Further, when manually allocating a static hwaddr (so I can map it to an
IP within the DHCP server),
The dhcp relies on an identifier to map the IP, the default is to use
the mac address but you can use another identifier like the hostname for
example. AFAIR, there is an option in the system network configuration
scripts to send the hostname for the dhcp requests.
is there any particular range I should avoid
or stick to?
This is how the kernel allocates the mac address.
/**
* random_ether_addr - Generate software assigned random Ethernet address
* @addr: Pointer to a six-byte array containing the Ethernet address
*
* Generate a random Ethernet address (MAC) that is not multicast
* and has the local assigned bit set.
*/
static inline void random_ether_addr(u8 *addr)
{
get_random_bytes (addr, ETH_ALEN);
addr [0]= 0xfe; /* clear multicast bit */
addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
}
Maybe you can use the mac address range used for the virtual nic of vmware.
I just use 02:00:ip address which ends up being automatically unique
enough to not collide with anything else on your subnet assuming you
already know the ip's you want to use
IP=192.168.0.50 # container nic IP
HA=`printf 02:00:%x:%x:%x:%x ${IP//./ }` # generate a MAC from the IP
The assumption is that you are already prepared to manage IP's somehow
and wish the MAC's would be automatic yet at least relatively stable to
keep from breaking things too often that track macs. So this way as you
provision vm's, the macs will never collide without you having to
actually track them manually, yet they aren't generated randomly and
they stay the same as long as a given vm's ip stays the same.
--
bkw
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
[Lxc-users] Network configuration
Hello My host is configured with two networks as below: eth0: external network a.b.c.d/24 eth1: internal network 10.1.0.0/16 I would like to configure my containers to belong to a third network (say, 10.2.0.0/16), and then set up two NAT rules (one for eth0 and one for eth1) to allow them to access the apropriate networks. Is this possible? On all example configurations I found, the containers always belong to a network that the host also belongs too, using bridges. Is this a requirement? Thanks Andre -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] How are pseudorandom MACs selected?
Daniel Lezcano daniel.lezc...@free.fr writes:
On 02/02/2011 10:26 AM, Trent W. Buck wrote:
For each lxc.network.type = veth, if you DON'T specify an
lxc.network.hwaddr, you get one assigned at random (example below).
Are these assignments made from a reserved range (a la 169.254/16 in
IPv4), or are they randomized across the entire address space? AFAICT,
it MUST be the latter.
Further, when manually allocating a static hwaddr (so I can map it to an
IP within the DHCP server),
The dhcp relies on an identifier to map the IP, the default is to use
the mac address but you can use another identifier like the hostname
for example.
Good idea, although that would make configuring my DHCP server (dnsmasq)
a little more fiddly. Currently I just populate ethers(5) on the DHCP
server, and dnsmasq automagically uses that mapping (as opposed to
adding lines into the dnsmasq.conf).
AFAIR, there is an option in the system network configuration scripts
to send the hostname for the dhcp requests.
There is; it's ``send host-name foo;''
On Ubuntu this is even the default: they have patched their ISC dhclient
package to allow ``send host-name hostname;'', which sends the same
string as `hostname' emits.
This is how the kernel allocates the mac address.
static inline void random_ether_addr(u8 *addr)
{
get_random_bytes (addr, ETH_ALEN);
addr [0] = 0xfe; /* clear multicast bit */
addr [0] |= 0x02; /* set local assignment bit (IEEE802) */
}
Cool, thanks.
Maybe you can use the mac address range used for the virtual nic of
vmware. Another solution would be to buy a cheaper nic, get its mac
address, break and drop the nic :)
Hehe. I'll try just assigning from the local unicast range, and see if
I run into problems.
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Ubuntu sshd template
Gary Ballantyne gary.ballant...@haulashore.com writes: # /usr/bin/lxc-execute -n foo -f /usr/share/doc/lxc/examples/lxc-veth.conf /bin/bash The container fired up, and I could ping to/from the host. However, when I left the container (with exit) things got weird. In a second terminal (already connected to the host), I got repeated errors of the form: [ 1396.169010] unregister_netdevice: waiting for lo to become free. Usage count = 3. I don't know about that one, sorry. IIRC I got the lxc-ssh container to DTRT on 10.04, but it's entirely possible I was getting those dmesg errors and not seeing them, because I wasn't on a local tty. UPDATE: oh, I see you're just using lxc-veth for bash... I dunno anything about that. I guess you could be getting that when bash tries to initialize itself (e.g. setting $HOSTNAME)? Do you get the same problems with /bin/dash or (say) /bin/pwd instead? Where the bracketed number changes for each error. (A new error appears every 10 seconds or so). The bracketed number is the number of seconds since boot. The message is being emitted by the kernel. Any suggestions? Show us your .conf. Maybe show us some diagnostics, too lxc-ps auxf lxc-netstat --name foo -nlp netstat -nlp ip l ip a ip r -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] How are pseudorandom MACs selected?
Brian K. White br...@aljex.com writes:
I just use 02:00:ip address which ends up being automatically unique
enough to not collide with anything else on your subnet assuming you
already know the ip's you want to use
IP=192.168.0.50 # container nic IP
HA=`printf 02:00:%x:%x:%x:%x ${IP//./ }` # generate a MAC from the IP
I think I'll adopt a slight variation of this -- computing the MAC from
the hostname, which are guaranteed by my site policy to be [a-z]{5}.
Where 06 is an arbitrarily chosen local unicast range,
$ f () { python -c print '06%010x' % int('$(LC_ALL=C tr $1 a-z
0-9a-p)',26); }
$ f zorba
06b240be
This allows my DHCP server to continue mapping MAC-IP, while actually
getting it from a hostname (which policy says won't change).
And I'll do this for all my containers, so that even containers that
have automatically assigned IPs will be relatively persistent (because
dnsmasq remembers MAC-IP leases and re-uses them preferentially).
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
___
Lxc-users mailing list
Lxc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] concurrent aptitude/dpkg runs in separate containers -- bork bork bork
Daniel Lezcano daniel.lezc...@free.fr writes: On 01/12/2011 07:39 AM, Trent W. Buck wrote: Mikedeb...@good-with-numbers.com writes: Trent W. Buck wrote: I can provision a new LXC container, which includes running a few aptitude install foo lines (inside the containers), and it Just Works. If I try to provision two containers at the same time, both containers appear to hang with a dpkg process in the D state[0]. My config for each container looks like this: lxc.mount.entry = /home /srv/lxc/proud/home none bind Doesn't aptitude write into the home directory that you're sharing across containers? locks ~/.aptitude/cache? Possibly, but dhclient's running aptitude as uid 0, whose home is in /root, which is not shared between hosts. In any case, IIRC I export HOME=`mktemp -d` before aptitude runs, as a fugly workaround for etckeeper. I suppose if containers' /tmp are tmpfses, aptitude might be running into some problem with locking on tmpfs, although I'm not aware of any bogus operational semantics for tmpfs... Can you give, for each process in D state, the content of /proc/pid/stack ? That may help to understand where the lock occurs in the kernel I ran into it again today, accidentally. I was recently reminded that dpkg doesn't mix well with ext4 and btrfs, because it calls sync/fsync all the time. Now, my containers are on different ext4 LVs, but maybe 1 process calling f/sync all the time is enough to slow them both down. I'm being a bit more patient than last time, and I think they ARE proceeding, just REALLY slowly. Meanwhile aptitude consumes a 100% of a core busy-waiting for a response from dpkg :-/ They look like this: $ ssh omega cat /proc/7713/stack Warning: Permanently added 'omega,192.168.155.22' (RSA) to the list of known hosts. [811669b7] sync_inodes_sb+0x87/0xb0 [8116b292] __sync_filesystem+0x82/0x90 [8116b379] sync_filesystems+0xd9/0x130 [8116b431] sys_sync+0x21/0x40 [810121b2] system_call_fastpath+0x16/0x1b [] 0x $ ssh omega cat /proc/5619/stack Warning: Permanently added 'omega,192.168.155.22' (RSA) to the list of known hosts. [81222865] jbd2_log_wait_commit+0xc5/0x150 [811d7a2c] ext4_sync_file+0x13c/0x2e0 [8116b051] vfs_fsync_range+0xa1/0xe0 [8116b0fd] vfs_fsync+0x1d/0x20 [8116b13e] do_fsync+0x3e/0x60 [8116b190] sys_fsync+0x10/0x20 [810121b2] system_call_fastpath+0x16/0x1b [] 0x I couldn't capture 1 pid from the same ps run before one or the other vanished. The ps output of D states looks like this: $ ssh omega lxc-ps auxf | grep ' D ' root 465 0.0 0.0 0 0 ?DJan12 0:04 \_ [kdmflush] root 476 0.0 0.0 0 0 ?DJan12 0:01 \_ [kdmflush] root 591 0.0 0.0 0 0 ?DJan12 0:10 \_ [jbd2/dm-0-8] root 1437 0.0 0.0 0 0 ?DJan12 0:11 \_ [jbd2/dm-3-8] root 2278 0.0 0.0 0 0 ?DJan12 0:21 \_ [kdmflush] root 2293 0.0 0.0 0 0 ?DJan12 1:06 \_ [jbd2/dm-21-8] root 26611 0.0 0.0 0 0 ?D15:27 0:00 \_ [kdmflush] root 26635 0.0 0.0 0 0 ?D15:27 0:00 \_ [jbd2/dm-6-8] template-amd64 root 4763 0.7 0.0 17708 6064 ?D15:47 0:00 | | \_ /usr/bin/dpkg --status-fd 34 --unpack --auto-deconfigure /srv/mirror/ubuntu/pool/main/u/udev/udev_151-12.3_amd64.deb /srv/mirror/ubuntu/pool/main/l/lvm2/dmsetup_1.02.39-1ubuntu4.1_amd64.deb /srv/mirror/ubuntu/pool/main/g/glib2.0/libglib2.0-0_2.24.1-0ubuntu1_amd64.deb /srv/mirror/ubuntu/pool/main/libu/libusb/libusb-0.1-4_0.1.12-14ubuntu0.2_amd64.deb /srv/mirror/ubuntu/pool/main/p/plymouth/plymouth_0.8.2-2ubuntu2.2_amd64.deb /srv/mirror/ubuntu/pool/main/libp/libpng/libpng12-0_1.2.42-1ubuntu2.1_amd64.deb /srv/mirror/ubuntu/pool/main/p/plymouth/libplymouth2_0.8.2-2ubuntu2.2_amd64.deb /srv/mirror/ubuntu/pool/main/m/mountall/mountall_2.15.3_amd64.deb /srv/mirror/ubuntu/pool/main/u/upstart/upstart_0.6.5-8_amd64.deb /srv/mirror/ubuntu/pool/main/u/util-linux/bsdutils_2.17.2-0ubuntu1.10.04.2_amd64.deb greed root 4325 0.7 0.1 14296 8880 ?D15:45 0:01 | \_ /usr/bin/dpkg --status-fd 35 --unpack --auto-deconfigure /srv/mirror/ubuntu/pool/main/x/xorg/x11-common_7.5+5ubuntu1_all.deb /srv/mirror/ubuntu/pool/main/f/freetype/libfreetype6_2.3.11-1ubuntu2.4_amd64.deb /srv/mirror/ubuntu/pool/main/t/ttf-dejavu/ttf-dejavu-core_2.30-2_all.deb /srv/mirror/ubuntu/pool/main/f/fontconfig/fontconfig-config_2.8.0-2ubuntu1_all.deb
Re: [Lxc-users] concurrent aptitude/dpkg runs in separate containers -- bork bork bork
t...@cybersource.com.au (Trent W. Buck) writes: I'm being a bit more patient than last time, and I think they ARE proceeding, just REALLY slowly. Meanwhile aptitude consumes a 100% of a core busy-waiting for a response from dpkg :-/ They look like this: $ ssh omega cat /proc/7713/stack Warning: Permanently added 'omega,192.168.155.22' (RSA) to the list of known hosts. [811669b7] sync_inodes_sb+0x87/0xb0 [8116b292] __sync_filesystem+0x82/0x90 [8116b379] sync_filesystems+0xd9/0x130 [8116b431] sys_sync+0x21/0x40 [810121b2] system_call_fastpath+0x16/0x1b [] 0x $ ssh omega cat /proc/5619/stack Warning: Permanently added 'omega,192.168.155.22' (RSA) to the list of known hosts. [81222865] jbd2_log_wait_commit+0xc5/0x150 [811d7a2c] ext4_sync_file+0x13c/0x2e0 [8116b051] vfs_fsync_range+0xa1/0xe0 [8116b0fd] vfs_fsync+0x1d/0x20 [8116b13e] do_fsync+0x3e/0x60 [8116b190] sys_fsync+0x10/0x20 [810121b2] system_call_fastpath+0x16/0x1b [] 0x And here's one that is well and truly wedged: root@omega:~# cat /proc/31430/stack [811669b7] sync_inodes_sb+0x87/0xb0 [8116b292] __sync_filesystem+0x82/0x90 [8116b379] sync_filesystems+0xd9/0x130 [8116b431] sys_sync+0x21/0x40 [810121b2] system_call_fastpath+0x16/0x1b [] 0x In that case, even kill -SEGV'ing upstart won't stop it. I got that with only a single dpkg run (i.e. no concurrency), after switching the container's rootfs from ext4 to ext3, and forcing dpkg[0] to be upgraded before anything else. Sigh... I'm THIS CLOSE to giving up and wrapping apt-get in libeatmydata. [0] I did this because I noticed that lucid's dpkg still suffers from http://bugs.debian.org/578635 http://bugs.debian.org/605009 https://launchpad.net/bugs/570805 But lucid-updates lucid-security both contain a version that contains CLAIMS to address the first of those. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
