=== dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [07:10] hi all === dendrobates is now known as dendro-afk === daker_ is now known as daker === dendro-afk is now known as dendrobates [13:13] newbie question (cant find in docs): confirmation emails to new users comes with url:http://46.x.x.51/wiki/Special:ConfirmEmail/369f4ed3c6933061ee59c1108e1ff685. How can i change 46... to domain name? it is registered and responding in dns. [13:15] seems no definition in LocalSettings.php responsible for this and this ip arriving automatically from server settings? [13:17] oh... wrong room. sorry. === godber_ is now known as godber [14:34] kim0, :P === dendrobates is now known as dendro-afk === niemeyer is now known as niemeyer_lunch [16:38] hallyn, quick question... [16:38] i'm looking at /etc/init/lxcmount.conf [16:39] y [16:39] http://paste.ubuntu.com/596096/ [16:39] how is 'container' defined ? [16:40] 'container=libvirt' is placed in envp by libvirt [16:40] and then, second question, why does fstab.lxc have nothing in it ? [16:40] bc lxc doesn't need upstart to mount anything [16:41] ok.. [16:42] would one expect that /proc would be populated inside an lxc container? [16:42] yes [16:42] both lxc and libvirt do that for you [16:43] ok. so if you had an entry in fstab.lxc, for /proc, what would happen ? [16:43] you'd presumably just get proc mounted twice [16:43] would init/mountall mount over it ? i would assume it would notice it was already mounted. [16:43] it's possible that it would return an error, and boot would fail [16:43] it does handle that correctly when the kernel mounts /dev/ as a tmpfs [16:44] so it must check at leas that. [16:44] ? [16:44] why would it return error when mounting /dev as tmpfs? [16:45] smoser: are you having a problem with the boot sequence? [16:45] smoser: I was going to ask zul (when I finish some little things) how nova+lxc is going at the moment. [16:46] hallyn, i was saying that in /lib/init/fstab, there exists an entry for '/dev/' as a tmpfs [16:46] but in most cases, the kernel will have already mounted /dev as a tmpfs before upstart comes up [16:47] so it has to be checking to see to avoid duplicate mounts [16:47] yes, thats what i was looking at [16:47] could be, would make sense [16:47] easy enough to test in the proc case :) [16:49] the problem is /var/run is not coming up before cloud-init is bring run so no netowking, so no contacting of the metadata server for the instance [16:50] zul: can cloud-init just wait for mountall to finish before starting? [16:50] hallyn, if upstart behaves sanely, then my theory is that you should have basically the same thing in /lib/init/fstab in /lib/init/fstab.libvirt [16:50] *except* for the things that cause problems. [16:51] smoser: your theory is flawed then, as the obvious experiment has already been done and failed [16:52] oh? [16:52] smoser: the reason your theory is flawed, though, is bc you're not thinking about the namespaces [16:52] upstart can avoid re-mounting /dev and /proc, bc they are mounted where it wnats them [16:52] but a lot of the cruft in /lib/init/fstab is not mounted where upstart wants them in a container [16:52] so it doesn't realize they are already mounted [16:53] example ? [16:53] /dev/root :) [16:55] i did say "except for things that cause problems" [16:59] most of it is simply not appropriate for a container, or already being mounted anyway. I don't see the value in tossing entries back in just because they say 'optional' and aren't even getting mounted on the host - just bc they are on a host's version of the file. === niemeyer_lunch is now known as niemeyer [17:01] here's a q, what does 'showthrough' mean as a mount option [17:01] * hallyn googles [17:01] wow, that's a fascinating one === daker is now known as daker_ [18:37] hi all [18:44] koolhead17: hey === dendro-afk is now known as dendrobates [18:46] supp kim0 [18:46] hey how's it going [18:47] awesome. am loving it :P [18:47] haha :) enjoy [18:48] kim0: few of the bugs got fixed in latest revision [18:49] yeah :/ [18:49] it's such a young product [18:49] but it's moving rapidly [18:59] i am just happy [19:12] hehe [19:29] kim0: which team handles infra of launcpad? [19:30] the launchpad team :) [19:30] #launchpad [19:34] ok cool. next time run to them [20:49] hallyn, around ? [21:39] problem... create a new EC2 instance from the official maverick AMI (ami-cef405a7), run apt-get update & apt-get upgrade, and it results in the following error... [21:40] Errors were encountered while processing: language-selector-common E: Sub-process /usr/bin/dpkg returned an error code (1) [21:40] this gets in the way of, for example, cloud-config puppet bootstrapping, and other stuff as well i'm sure [21:42] looks like an updated language-selector-common package release today === sark_ is now known as nwl [22:07] never mind, i found this... https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/766534 [22:07] Launchpad bug 766534 in language-selector "Regression on maverick when updating to 0.6.7 (security upload)" [Critical,Fix committed] [22:19] smoser: sorry, what's up? [22:19] i have to run, hallyn... [22:19] k [22:19] i'll be on late [22:19] http://paste.ubuntu.com/596245/ [22:19] hallyn, ^ [22:20] that is the diff of 'initctl' list when running under libvirt-lxc and ec2 at the point in which cloud-init-nonet runs (MOUNTED /) [22:20] our problem is that udev isn't running early enough [22:20] i had suspected tha tthat was due to virtual-filesystems not having been emitted [22:21] by mountall. [22:21] but i'm not sure. [22:21] i will be back later to debug [22:23] smoser: interesting. ok. === erichammond1 is now known as erichammond [22:36] smoser: actually i'd wager what is happening is that udev is just slower to start because all containers and the host see the udev events [22:37] and there's nothing to do about that, apart from introducing device namespaces in the kernel