[00:46] <smoser> slangasek, around ?
[00:46] <smoser> http://paste.ubuntu.com/1191848/
[00:46] <smoser> so it seems like 2 issues. a.) network is already up, so i think ifup decides it doesn't need to bring the network up, and b.) mountall doesn't like me doing mounts for it.
[00:55] <slangasek> smoser: how do you mean, "network is already up"?
[00:55] <smoser> iscsi root.
[00:55] <smoser> it came up in the initramfs
[00:55] <slangasek> smoser: right; ifupdown doesn't consider that "up"
[00:56] <smoser> hm..
[00:56] <slangasek> to ifupdown, it's only up if ifup has been called
[00:56] <smoser> i'd have thought.
[00:56] <slangasek> which is not to say that the network already being up can't be causing problems for ifupdown
[00:56] <slangasek> or maybe iscsi even injects state?
[00:57] <smoser> injects state?
[00:58] <smoser> hm..
[00:58] <slangasek> smoser: yes, as in, perhaps the open-iscsi initramfs script scribbles something in /run to tell ifupdown to under no circumstances bounce the interface
[00:58] <smoser> i dont think so.
[00:58] <smoser> but clearly it cannot bounce the interface.
[01:00] <smoser> but i dont know what i thought was wrong. about mountallnot liking me
[01:02] <slangasek> smoser: dunno... there's some noise about filesystems already mounted, but coincidentally these are all optional mounts
[01:03] <slangasek> smoser: looks like mountall itself succeeds, it's just the network not happening
[01:03] <smoser> right.
[01:03] <smoser> it was the "busy" stuff that i was confused by.
[01:04] <smoser> i'll look foranything iscsi might be doing to protect
[01:04] <smoser> or maybe ifupdown somehow just "knows"that it has non-local filesystems
[01:05] <smoser> although it appears to have tricked mountal
[01:05] <slangasek> smoser: should I be seeing full upstart logging here?  there's nothing after 37.584470, at which point udev has not actually succeeded in starting and therefore ifupdown is not being triggered
[01:05] <slangasek> smoser: upstart-udev-bridge is 'start on starting udev'; it never completes
[01:07] <slangasek> at least, not that's shown in this log
[01:09] <smoser> well, it still hasnt then (looking at that log now)
[01:10] <slangasek> smoser: what's 'status upstart-udev-bridge' show?
[01:11] <smoser> hm.. start/running
[01:11] <slangasek> ok
[01:11] <slangasek> so maybe the log output went somewhere else
[01:11] <slangasek> (in which case... we probably need to see that log output, wherever it is, to get the whole picture)
[01:12] <smoser> yeah.
[01:12] <smoser> i have had thoughts that i was not getting all of output
[01:18] <smoser>  /var/log/syslog: http://paste.ubuntu.com/1191875/ /var/log/kern.log: http://paste.ubuntu.com/1191876/
[01:19] <xnox> anything interesting in /var/log/upstart/* ?
[01:20] <xnox> cause that's where it's going by default....
[01:22] <smoser> $ ls -l /var/log/upstart -d
[01:22] <smoser>  ls: cannot access /var/log/upstart: No such file or directory
[01:40] <slangasek> smoser: um?  where'd you put that directory then?  It's shipped by the upstart package
[01:41] <smoser> well... i changed the timeout waiting for static-networking-up back to 120 seconds (i had put it to 10) in cloud-init-nonet.conf
[01:41] <smoser>  http://paste.ubuntu.com/1191899/
[01:41] <smoser> well, i didn't put that directory anywaere.
[01:41] <smoser> suck.
[01:41] <smoser> so this is definitely a bug. some cleaning out of images. in the build process kills that.
[01:41] <smoser> so i'll open a bug on that.
[01:42] <smoser> i changed that timeout back to 120 seconds
[01:43] <smoser> and http://paste.ubuntu.com/1191889/ is the result
[01:43] <smoser> its more obvious that there something is still blocking, waiting for that.
[01:43] <smoser> probably for mounted / to finish
[01:45] <slangasek> smoser: so http://paste.ubuntu.com/1191875/ shows a correct udev-based bring-up of the networking
[01:46] <slangasek> but the timing is a bit odd
[01:46]  * slangasek looks at the latest
[01:47] <slangasek> smoser: hah; udevtrigger waits to find out if you're in a container
[01:47] <slangasek> smoser: /etc/init/container-detect.conf has an explicit check for mounted MOUNTPOINT=/run instead of virtual-filesystems
[01:47] <slangasek> smoser: try twiddling it to use virtual-filesystems instead
[01:47] <smoser> bah.
[01:48] <slangasek> smoser: that seems like a change we can easily make in the distro - if it works
[01:48] <smoser> well, it might be by design.
[01:48] <smoser> in that it can run earlier than virtual-filesystems (much earlier)
[01:48] <slangasek> nah
[01:49] <smoser> altougho i guess nothing (as we see) is gonna guarantee that anyway.
[01:49] <slangasek> I mean, it is, but there's nothing in the design that requires the rest of mountall to wait for the container answer
[01:49] <slangasek> and changing the container-detect job is better than making your workaround job double-emit the mounted event
[01:49] <smoser> so.. https://bugs.launchpad.net/ubuntu/+bug/1047707 is to cover /var/log/upstart in the images.
[01:49] <ubottu> Launchpad bug 1047707 in Ubuntu "/var/log/upstart deleted from cloud images" [High,Triaged]
[01:50] <smoser> well i had my work around in place there.
[01:50] <smoser> and i think its required to get to the point.
[01:50] <infinity> smoser: I assume that's a symptom of a larger "purging stuff willy-nilly" bug?
[01:50] <infinity> smoser: Unless you were explicitly removing that one directory for some reason...
[01:50] <smoser> yeah, it is.
[01:50] <slangasek> smoser: yes, and your workaround does NOT emit the 'mounted' event, it emits virtual-filesystems
[01:50] <smoser> no. its like rm -Rf /var/log/*
[01:50] <smoser> right.
[01:50] <infinity> smoser: Gah.
[01:50] <slangasek> which we should bring container-detect into alignment with
[01:50] <smoser> right.
[01:50] <smoser> one thing that i'm running into
[01:51] <smoser> the cloud-init-nonet job has 'output console'
[01:51] <smoser> but its output is *not* getting to console
[01:51] <smoser> where console=/dev/ttyS0 (per that command line).
[01:51] <smoser> i had to explicitly | tee /dev/ttyS0 to get it to the console.
[01:52] <smoser> i'll try the change on container and boot
[02:08] <smoser> slangasek, that seems to fix the proble.
[02:09]  * slangasek nods
[02:09] <smoser> well, with the hack-emit-virtual-filesystems.
[02:09] <slangasek> it certainly should have been the last thing left that could be a problem :)
[02:09] <smoser> so i can get where i need to go now, i think.
[02:10] <smoser> so you want a bug against upstart for container-detect?
[02:10] <slangasek> smoser: can you file a bug on upstart about container-detect and /run vs. virtual-filesystems?
[02:10] <slangasek> yes please :)
[02:10] <smoser> i'll open one, but i'd appreciate if you fill in some better debug and justfication.
[02:10] <smoser> so that some time from now when i'm trying to trace steps i'll have some info
[02:12] <slangasek> smoser: ack
[02:14] <smoser> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1047712
[02:14] <ubottu> Launchpad bug 1047712 in upstart (Ubuntu) "container-detect.conf should be 'start on virtual-filesystems'" [Undecided,New]
[02:16] <smoser> slangasek, what woudl you think about trying to make mountall happier by running my virtual-filesystems-emitter on 'starting mountall'
[02:16] <smoser> (in addition to cloud-init-nonet. it should just prep the system so mountall doesn't htink it should have to mount those filesystems)
[02:53] <smoser> slangasek, well. one more piece of my puzzle (i'm stillnot getting resolv.confworked out).
[02:53] <smoser> but /etc/init/iscsi-network-interface.conf is a bit of info
[02:55] <smoser> http://paste.ubuntu.com/1191973/
[03:13] <slangasek> smoser: 'start on starting mountall' should be fine for that, yeah
[03:13] <slangasek> smoser: right, that's kinda what I was expecting to see from iscsi
[03:14] <slangasek> and it's skipping the ifupdown hooks, which is a problem
[03:14] <slangasek> though from the comment, it seems that may have been deliberate
[03:21] <smoser> slangasek, yeah. i'm poking around.
[03:22] <smoser> i'm in initramfs now.
[03:22] <smoser> was hoping i could get it to store off the dns server responses
[03:22] <smoser> from the dhcp request.
[03:23] <smoser> they get printed. and "configure_networking" pretends that "Ip-Config tries to create this file and when it succeds" (/run/net-"${DEVICE}".conf)
[03:23] <smoser> but it sure doesn't look like it does to me. i'm in an initramfs and dont see any such stuff getting created.
[03:26] <smoser> shoot.
[03:26] <smoser> it loo like our initramfs is busted in that respect
[03:26] <smoser> it writes /tmp/net-eth0.conf
[03:26] <smoser> at least in precise
[03:27] <slangasek> so, where does ipconfig come from? busybox?
[03:27] <smoser> klibc
[03:28] <smoser> http://paste.ubuntu.com/1191999/
[03:30] <slangasek> smoser: fixed in quantal; seems klibc-utils and initramfs-tools were out of sync on this in precise
[03:30] <slangasek> smoser: sounds like that should be cherry-picked from klibc-utils
[03:30] <smoser> ah. so the klibc-utils updated to /run
[03:30] <slangasek> klibc 2.0-2, in Debian
[03:30] <slangasek> yes
[03:30] <smoser> i'm opneing a bug for that.
[03:31] <smoser> easiest thing might be to just update to lok in 2 places
[03:31] <slangasek> no, just update klibc to use /run
[03:31] <slangasek> that's the right place for it to be
[03:31] <slangasek> and nothing relies on the current behavior in precise
[03:35] <smoser> slangasek, are you sure this is "fix-released" ?
[03:35] <smoser> https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1047722
[03:35] <ubottu> Launchpad bug 1047722 in klibc (Ubuntu) "configure_networking net-DEVICE.conf in /run, but ipconfig writes in /tmp" [Undecided,New]
[03:36] <slangasek> smoser: I've checked the source in quantal, it's definitely writing to /run onw
[03:36] <slangasek> now
[03:36] <smoser> k.
[03:38] <smoser> so i thin i shoudl be able to get that information from the dhcp response (dns info)
[03:38] <smoser> and store it somewhere
[03:38] <smoser> and then replay it to resolvconf
[03:40] <slangasek> in fact, so long as you're getting it written to /run, I believe the initramfs should be mount -omove'ing that for you
[03:42] <smoser> yeah, i wondered about that. so i dont have to store it even.
[03:42] <slangasek> yep
[03:42] <slangasek> you do have to make sure you're not mounting something else over /run ;)
[03:42] <smoser> i think i'm gonna close this laptop now.
[03:42] <smoser> you've been very helpful, slangasek
[03:42] <smoser> thanks.
[03:42] <slangasek> y/w
[03:42] <slangasek> have a good evening
[03:43] <smoser> evening for 8 more minutes here
[03:43] <smoser> then am
[03:43] <smoser> later.
[03:56] <slangasek> looking at the dictionaries-common code makes me very angry
=== cpg is now known as cpg|away
=== cpg|away is now known as cpg
=== cpg is now known as cpg|away
=== cpg|away is now known as cpg
=== wzssyqa1 is now known as wzssyqa
=== wzssyqa is now known as Guest43660
[07:31] <malkauns> can someone point me to how i can create animated progressbars in gtk-3?
=== iulian is now known as Guest54251
=== Guest54251 is now known as iulian
=== mcclurmc_away is now known as mcclurmc
=== cpg is now known as cpg|away
=== korn_ is now known as c_korn
[11:10] <Daviey> jtaylor: thanks for doing asterisk
[11:11] <jtaylor> np but it needs doing for precise
[11:11] <jtaylor> unfortunately it are ~8 CVEs and the simple diff are 10000 lines ...
[11:11] <jtaylor> I have no time for that and no idea how to test anything
[11:13] <Daviey> jtaylor: Well, if you are able to prepare an update.. I'm happy to test it?
[11:16] <jtaylor> thanks, I'll come back to you if an update gets prepared
[11:17] <Daviey> super!
=== doko_ is now known as doko
[13:51] <penguin42> doko: Which gcc package version were you using for bug 1019725 ?
[13:51] <ubottu> Launchpad bug 1019725 in gcc-4.6 (Ubuntu) "tiny STL code sample segfaults cc1plus" [Medium,Triaged] https://launchpad.net/bugs/1019725
=== yofel_ is now known as yofel
[15:07] <pcarrier> is it just me, or is canonical trying to get rid of the gnome ecosystem and quantal a step toward more and more components in qt?
[15:22] <ScottK> Any particular examples in mind?
[15:34] <alkisg> I'm trying ubuntu-defaults-image, and it's working ok except that the generated .iso doesn't have the following files:
[15:34] <alkisg> autorun.inf boot dists install pics pool preseed README.diskdefines ubuntu wubi.exe
[15:34] <alkisg> ...can I do something to include those as well?
[16:14] <phaidros> is there any reason that 12.04 LTS comes without CONFIG_CIFS_ACL kernel setting ?!
=== cpg|away is now known as cpg
[19:15] <penguin42> jamespage: Thanks for fixing the iPXE
[19:16] <jamespage> penguin42, np
[19:17] <penguin42> jamespage: What's your setup like; I'm running two kvm vm's one with tgt, and I've got two different clients; one disk less, and the other with disk - the diskless install doesn't seem to have setup the inittab properly yet (from last weeks iso)
[19:18] <jamespage> penguin42, I run tgt on the KVM host alongside libvirt and I use diskless kvm vms with a scripted ipxe setup todo automated iscsi root installs for testing
[19:19] <jamespage> penguin42, its a bit hacky but it works - https://code.launchpad.net/~james-page/+junk/iscsi-testing
[19:22] <penguin42> jamespage: Have you had any problem with boot order issues on tgt? I seem to need to restart tgt after server boot for it to pick the disk up
[19:23] <jamespage> penguin42, I'd not noticed anything like that - but my test cases don't normally persist between boots :-)
[19:23] <jamespage> I don't make the tgt configuration persistent
[19:24] <jamespage> penguin42, BTW have you tried 12.04 against a quantal tgt target? I'm wondering whether I need to SRU that fix to 12.04 as well
[19:24] <penguin42> jamespage: No I haven't; I haven't got a 12.04 host to try
[19:25] <penguin42> (I guess I could go nuts and go nested kvm...)
[19:25] <jamespage> penguin42, thats my prob as well
[19:25] <jamespage> I probably will try that; I have access to a cloud which supports it
[19:25] <penguin42> jamespage: I've done nested kvm before - it's surprisingly easy; other than getting the default netmask right, it just works if you stack 12.04's
[19:30] <penguin42> jamespage: I suspect the other thing the people running iscsi in the real world would want to do automatically in the installer is get multipath going
[19:33] <jamespage> penguin42, I have lots of experience with multipath in fibre channel based SAN's - but zip with iscsi
[19:35] <penguin42> jamespage: I don't know much about it - my server setup does have two net interfaces and I've bound it to both 'portals' - and in the non-root version I've got I have it log in once on each interface and see both instances as separate discs in /proc/scsi/scsi so I assume multipath would sort it out into one device
[19:36] <penguin42> jamespage: I think like FC there is a lot of 'magic' knowledge of timeouts and stuff with particular vendors
[19:37] <penguin42> jamespage: The only other commonality is that multipath is renowned as a pain
=== cpg is now known as cpg|away
=== ml|vacation is now known as ml|transit
[20:42] <penguin42> jamespage: Bug 1047998 is my problem with the server install on iscsi root
[20:42] <ubottu> Launchpad bug 1047998 in debian-installer (Ubuntu) "iscsi root: iscsi not started in initramfs" [Undecided,New] https://launchpad.net/bugs/1047998
[21:02] <penguin42> jamespage: and bug 1048008 for tgt needing a restart
[21:03] <ubottu> Launchpad bug 1048008 in tgt (Ubuntu) "tgt needs restart to find LUN" [Undecided,New] https://launchpad.net/bugs/1048008
[21:06] <pcarrier> ScottK: ubuntu-sso-client-qt, ubuntuone-control-panel-qt, apparently libaccounts
=== jtechidna is now known as JontheEchidna
=== jtechidna is now known as JontheEchidna
=== cpg|away is now known as cpg