=== dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [01:58] infinity, slangasek: I've put some test packages that enable amd64 flash here, and would really appreciate your invaluable comments, especially for the oneiric version : https://launchpad.net/~mdeslaur/+archive/64bitflash === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [04:14] Good morning [04:15] morning pitti [05:17] ev: congrats, bcmwl wifi is now rather painless indeed! [05:17] ev: seems it's one tiny step away from perfection :) (bug 872119) [05:17] Launchpad bug 872119 in ubiquity (Ubuntu) ""Error occurred while copying the network settings" on bcmwl machine" [Undecided,New] https://launchpad.net/bugs/872119 [05:52] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg === tkamppeter__ is now known as tkamppeter [07:07] good morning [08:00] pitti: argh. that one is entirely my fault and will take all of two seconds to fix [08:00] ev: not a dealbreaker; it makes it a whole lot more easy to use broadcom cards :) [08:01] ev: does that only affect bcmwl, or other wifi (such as intel), too? [08:03] pitti: the copying of network-manager's brain to the installed system is broken, so it'll affect any card [08:03] so the user will have to re-enter their wifi password [08:03] and they'll all see that error dialog [08:04] ev: that more or less just copies /etc/NetworkManager/system-connections/*, or is there more to it? [08:08] pitti: correct [09:21] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [09:22] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Final Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev === MacSlow is now known as MacSlow|lunch === Riddelll is now known as Riddell [11:08] can someone in ubuntu-branches please reject https://code.launchpad.net/~bones/ubuntu/natty/radiotray/fix-for-722886/+merge/70107 [11:08] and mark https://code.launchpad.net/~jtaylor/ubuntu/natty/meld/meld-sru/+merge/72410 as merged (or whatever we do for SRUs targetted at the release branch) === dholbach_ is now known as dholbach [11:15] https://code.launchpad.net/~jtaylor/ubuntu/natty/pycryptopp/sru-811721/+merge/75850 is also uploaded [11:18] https://code.launchpad.net/~rye/ubuntu/natty/bindwood/update-firefox-6-compat-fix/+merge/76055 appears to be rejected [11:22] Laney, did you sort out the cairo-dock debian/upstream miscommunication? [11:28] cjwatson / james_w: two more to mark Merged: https://code.launchpad.net/~brunoqc/ubuntu/natty/lfm/lfm-fix-786491/+merge/77859 https://code.launchpad.net/~jtaylor/ubuntu/natty/singularity/fix-576504/+merge/78286 [11:28] that's it [11:39] doko: no, we should get on that as well === dendro-afk is now known as dendrobates === MacSlow|lunch is now known as MacSlow === Zic_ is now known as Zic === dendrobates is now known as dendro-afk === plars-holiday is now known as plars === dendro-afk is now known as dendrobates === dholbach_ is now known as dholbach [14:19] tumbleweed: done all but the bindwood one; what's with that one? [14:34] pitti: I guess micahg is the pbest person to answer that one, but I'm assuming the fix is going into a different sourcepackage... === kancerman_ is now known as kancerman [14:41] jamespage: before setting plymouth:debug, were you able to reproduce bug #849414 consistently? [14:41] Launchpad bug 849414 in plymouth (Ubuntu Precise) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Incomplete] https://launchpad.net/bugs/849414 [14:42] slangasek: I was able to; however I appear to have stopped hitting that issue [14:42] jamespage: so reverting plymouth:debug doesn't cause it to reappear either? :( [14:43] slangasek, I running with it off now with no issues [14:43] slangasek, so I was thinking about what had changed; I was getting an ugly text based splash when I saw the issue [14:44] ah [14:44] setting debug turned that off - and the issue went away [14:44] that's helpful info :) [14:44] right, I don't think setting debug turned it off, I think something else I did turned it off :) [14:44] and your debug change just happened to coincide with other initramfs fixes [14:44] slangasek, quite possibly [14:46] jamespage: you could try re-breaking the graphics display by removing the plymouth-theme-ubuntu-logo package [14:46] slangasek, sure - give me a couple of minutes [14:47] slangasek, do you want me to turn debug on as well? [14:48] jamespage: I'd try first without turning on debug (in case it's timing-sensitive), then if that reproduces the issue, turn on debug [14:48] slangasek, ack === Girly-Girl is now known as GirlyGirl === sagaci_ is now known as sagaci [14:54] slangasek, hmm - not able to reproduce [14:55] jamespage: and it was 100% reproducible before? [14:55] slangasek, yes - I turned debug mode on an off and the came and went [14:55] jamespage: can I get apt logs, plus a big "here's where I turned on debugging" arrow, to try to work out what else changed on your system? [14:55] jamespage: also, what's your video? [15:00] slangasek, video is ATI Mobility Radeon HD 5400 Series [15:01] jamespage: binary video drivers? [15:05] slangasek, digging logs now [15:05] slangasek, not sure whether its relevant but when I got the issues I had a really low res text based splash as well [15:05] when I just tested it was much higher res [15:05] slangasek, http://paste.ubuntu.com/706151/ [15:06] slangasek, I think I first saw this issue on the 04/11 (indeed that is the date of the crash file that jhunt and I looked at earlier) [15:06] I turned debug mode on then - and did a few reboots and could not reproduce [15:06] oh heh [15:07] higher res> so you've got vesafb loading and a framebuffer console, that's going to change things for sure [15:07] slangasek, thats what I figured [15:07] jamespage: this is with the cryptsetup package installed, right? [15:07] slangasek, no [15:07] hmm [15:08] not sure why you would have gotten plymouth text without vesafb in that case [15:08] are you using binary drivers? [15:08] slangasek, yes [15:09] slangasek, just to prove it - https://launchpadlibrarian.net/81898994/firegl-crash.jpg [15:10] :-) [15:10] thats from a diff bug [15:11] looking at what i wrote on bug 865984 [15:11] Launchpad bug 865984 in Ubuntu "firegl_sig_notifier crash on shutdown or reboot" [Undecided,New] https://launchpad.net/bugs/865984 [15:12] slangasek: if you get a moment, can smoser and I ping you about a glibc bug and the likelyhood of it being considered fixable by upstream? [15:12] I appear to have had a vesafb/framebuffer console until shortly before the 04/11 [15:13] I raised that bug the same day I did the plymouth debug stuff [15:17] hallyn_: just ask directly please :-) [15:19] seb128, is there still time to get the libgrip fix into oneiric? or should it be an sru? [15:20] cnd, sru [15:20] ok [15:20] cnd, which is fine we already got a stack of srus uploaded [15:20] including compiz [15:20] ok [15:20] I'll prepare an sru upload then [15:21] Laney: wow, I wouldn't have expected breezy to top the upload score -- we had way fewer devs back then [15:21] Laney: well, maybe we uploaded 25 sets of langpacks :) [15:22] yeah, not sure what that is about [15:22] let me do the last query but s/oneiric/breezy/ [15:22] actually, it would be interesting to filter out all language-pack-* stuff [15:22] the data is all in udd ;-) [15:23] slangasek: I'm seeing a lot of complaints on arm from apps such as gconf and metacity looking for gconfd-2 in /usr/lib/i386-linux-gnu/libgconf2-4/ instead of using /usr/lib/arm-linux-gnueabi/libgconf2-4/. There must be something wrong with my multi-arch setup here. Any ideas? (not a symlink works around the problem) [15:24] mdeslaur: Bug 871847, I assume needs to wait for an SRU at this point? :) [15:24] Launchpad bug 871847 in virt-viewer (Ubuntu) "Bad port '0' upon connect qemu+ssh" [High,Confirmed] https://launchpad.net/bugs/871847 [15:25] slangasek: ok, i'm about to be afk for a few mins, but the problem basically is that grantpt in glibc starts out with a check for whether /dev/pts/{ptnum} is a valid slave. WIth /dev/pts being hardcoded. So if you call grantpt on /chroot/dev/pts/0, and /dev/pts/0 does not exist, the call will fail. [15:25] hallyn_: yep, universe just went into freeze [15:25] mdeslaur: zounds! [15:25] ok, thanks :) [15:25] pitti: I don't think langpacks appear in -changes? [15:26] Laney: they don't [15:26] then they wouldn't be in these stats [15:26] Laney: ah, it's based on -changes@, not soyuz [15:26] slangasek: this is only a problem when using a newly cloned devpts, so i'm not sure if glibc will deem that valid? [15:26] right [15:26] maybe autosyncs were announced back then? [15:26] tseliot: uh? i386-linux-gnu vs. arm-linux-gnueabi, what's that about? You're saying you have an arm system, with i386 packages installed? [15:26] Laney: was just going to say :) [15:26] slangasek: the workaround is doable but hacky - gotta fork, unshare a new mounts ns (with privilege), bind-mount /dev/pts, and then do the grantpt [15:27] Laney: right, see https://lists.ubuntu.com/archives/breezy-changes/2005-April/thread.html [15:27] stgraber: should bug 813065 be Fix Released - comment 9 leads me to think no [15:27] Launchpad bug 813065 in ubiquity (Ubuntu Oneiric) "Live session switches to VT console briefly" [High,Fix released] https://launchpad.net/bugs/813065 [15:27] hallyn_: why do you call grantpt against a chroot? [15:27] for the other months, too [15:27] I don't think I understand the problem, sorry [15:27] let me exclude that then [15:27] slangasek: no, they're all for arm [15:27] slangasek: libvirt's parent process sets up /dev/pts/0 in the container's rootfs as a console for 'virsh console' to connect to [15:28] a much different picture emerges [15:28] bdmurray: comment #9 was before Steve sent me a merge proposal fixing it properly which got merged and uploaded (comment #10) [15:28] slangasek: though in any case, since thamanpage doesn't mention anything, glibc definately is *wrong*. [15:28] pitti: http://paste.debian.net/135733/ [15:28] tseliot: but you said "There must be something wrong with my multi-arch setup here" - have you *done* some special multiarch setup? [15:28] stgraber: okay then what is going on with bug 871936? [15:29] Launchpad bug 871936 in ubiquity (Ubuntu) "Live session switches to VT console [nvidia]" [Undecided,New] https://launchpad.net/bugs/871936 [15:29] Laney: still respectable, compared to warty and hoary [15:29] slangasek: (but glibc might demand the manpage fix rather than the code fix :) [15:29] it's actually remaining fairly steady [15:29] bdmurray: I'm not sure, maybe slangasek has an idea but AFAIK ubiquity-dm now does the right thing, it may simply be an nvidia specific flicker bug [15:29] slangasek: no, I did nothing at all to set up multiarch. It's just that somehow apps are looking for that path [15:29] but oneiric moves up to fifth :-) [15:30] hallyn_: heh, indeed... I don't know, sorry [15:30] slangasek: nm, i guess i should join the m-l rather than bug you about it :) thanks [15:31] tseliot: what's the exact error message? [15:31] slangasek: "failed to activate configuration server: Failed to execute program /usr/lib/i386-linux-gnu/libgconf2-4/gconfd-2: Success [15:31] stgraber: okay the patch didn't seem hardware specific to me [15:31] slangasek: this comes from gnome-settings-daemon, metacity, etc. [15:32] bdmurray: indeed, it fixes flickerless for any graphic card that does work correctly with flickerless [15:32] bdmurray: which AFAIK isn't the case of nvidia [15:33] heh, i see, there really is no m-l [15:33] tseliot: does i386-linux-gnu show up anywhere in config files under $HOME? [15:33] libc-alpha it is. (weird name) [15:34] slangasek, tseliot: I know what it is [15:34] seb128: oh? [15:34] slangasek, well, maybe not [15:34] slangasek, /usr/share/dbus-1/services/org.gnome.GConf.service is in gconf2-common which is arch all [15:35] but "Exec=/usr/lib/libgconf2-4/gconfd-2" there [15:35] jamespage: when you said "04/11", you meant "04/10", right? [15:35] seb128: hmm [15:36] slangasek, hrm - yep [15:36] seb128, slangasek: but then how would it look for i386-linux-gnu ? [15:36] tseliot, the arch all is built on i386 [15:36] so it would have the i386 path [15:36] tseliot: I don't know; and I've not seen such an error on amd64 [15:36] but that doesn't seem to be it [15:36] the .service has non multiarch paths [15:36] that was just an idea, ignore me ;-) [15:36] seb128, slangasek: having a hardcoded path shouldn't be too good anyway [15:38] slangasek, i think i saw the same issue being discussed in #linaro this weekend [15:38] there must be a bug open for it already [15:38] tseliot, ogra_, slangasek: is linaro or somebody shipping a multiarched version of gconf? [15:38] our libgconf is not on multiarch [15:39] that's a good question [15:39] but it seems the service in arch all binary would lead to that question if somebody did a multiarch build without changing it to arch any [15:39] seb128, no idea, i think they are still working on switching their image builds to oneiric [15:39] that's the only way I could explain it [15:39] (linaro is one release behind since they do monthly releases) [15:39] question->error [15:40] ogra_, well, we need multiarched gconf [15:40] so that's not being "behind" [15:40] slangasek: and no, I can't find any references to i386 in $HOME [15:40] jamespage: are you sure you don't have cryptsetup installed? [15:40] it seems somebody has a custom multiarch version of gconf [15:40] the error showed up for them after switching to oneiric [15:40] tseliot: hmm [15:40] ogra_, can you ask them their version of gconf? [15:40] i didnt follow that deeply, but i know they opened a bug [15:40] slangasek, yes - http://paste.ubuntu.com/706181/ [15:41] seb128: what do you mean by "multiarched gconf"? We should only have one copy of the daemon running... [15:41] ogra_: right, I can only reproduce the problem in oneiric [15:41] slangasek, the service is dbus activated, if the path was multiarch specific but they have a .service in arch:all that would lead to such issues [15:41] ok [15:41] slangasek, dbus would be trying to spawn the i386 location [15:42] right; so when multiarching gconf, the daemon should be split out of the library package... [15:42] or the .service should be in an arch:all binary [15:42] so it gets the right location for each arch [15:43] the latter sounds easier [15:43] slangasek, the daemon is already splitted out of the library [15:43] the issue is that the dbus service which has the service location is in gconf2-common arch:all [15:43] we should just move the .service with the daemon when we multiarch it [15:44] well, that's just guess work on what their issue is, but "/usr/lib/i386-linux-gnu/libgconf2-4/" doesn't make sense if gconf has not been changed for multiarch [15:44] so I guess somebody did that work in a ppa or something [15:46] ogra_, tseliot, slangasek: [15:46] https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09 [15:46] "Convert to multiarch, gconf: DONE" [15:47] so yeah, "linaro bug" I guess [15:47] seb128, i dont see that bug here and have no issues [15:47] i just saw it being discussed by the linaro gusy [15:47] ogra_, well that didn't land in Ubuntu for sure [15:47] *guys [15:47] ogra_, their workitem is DONE so I guess they have their own version somewhere [15:47] in any case not an Oneiric issue ;-) [15:47] oh, its a linaro spec [15:47] * ogra_ missed that [15:49] there it is [15:49] bug 871892 [15:49] Launchpad bug 871892 in Linaro "org.gnome.GConf.service contains i386 pathname" [Undecided,New] https://launchpad.net/bugs/871892 [15:50] ogra_, seb128, slangasek: that's the exact bug that I'm seeing here [15:50] tseliot, what do you use? linaro or Ubuntu? [15:51] it was actually discussed yesterday ... [15:51] seb128: ubuntu [15:51] tseliot, dpkg -l | grep gconf [15:51] seb128, linaro builds their oneiric images from our archive plain, no additions but HW bits yet [15:51] they only start to work on oneiric this week [15:52] ogra_, that doesn't make sense, gconf is not multiarch in Ubuntu, if it was I would knew it [15:52] seb128, right [15:52] seb128: it doesn't seem to return anything [15:52] tseliot, you don't have gconf installed? how did you do your install? [15:52] seb128, i dont kno wabout multiarch, what i know is that linaro only starts working on a release once ubuntu released it [15:52] we still have a stack of things in the default install using it [15:52] so atm what they use should be plain ubuntu [15:53] since they only switched image builds to oneiric this week [15:53] ogra_, well with their own layer or ppa on top I guess [15:53] for kernel and bootloaders,. yep [15:53] ogra_, seeing https://blueprints.launchpad.net/linaro-ubuntu/+spec/multiarch-porting-11.09 they need multiarch conversions over what oneiric has [15:53] but no desktop bits yet [15:54] right, that might be, i can only comment on what i observed ... i dont work in linaro :) [15:54] seb128: apt-cache show gconf shows the installed size among other things [15:54] seb128: err... gconf2 [15:54] tseliot, how did you do your install? it's puzzling that you don't have gconf installed... are you sure you didn't type dpkg -l | grep gconf? [15:55] type->typo [15:56] seb128: yes, I typed it 3 times. I used our installer (which is probably the same as linaro) [15:56] no [15:57] linaro doesnt use any installer, they just install a metapackage in a chroot and tar that up [15:57] ogra_: we're doing something similar, through the usual live-helper though [15:58] well, ubuntu installs tasks etc ... might get you minimally different results [16:16] slangasek, just for the record it's indeed a linaro ppa with a multiarched version which has the .service in the arch all binary [16:17] slangasek, i.e not an Ubuntu bug (tseliot get the issue on a custom build, not on an Ubuntu install) [16:17] * tseliot nods [16:25] seb128: ah, heh [16:25] jamespage: did you for any reason set FRAMEBUFFER=y manually in your initramfs config? [16:26] slangasek: no - I've not touched it [16:27] jamespage: mmk [16:27] SpamapS: I just posted the generate /etc/network/interfaces to bug 870214 [16:27] Launchpad bug 870214 in open-iscsi (Ubuntu Oneiric) "iSCSI root installation creates manual eth0 configuration + long boot" [High,New] https://launchpad.net/bugs/870214 [16:27] SpamapS: is it normal that the boot waits for 2 minutes with a /etc/network/interfaces like this one? [16:28] jamespage: oh - could you try setting 'gfxpayload=text' manually in your /boot/grub/grub.cfg, instead of the default gfxpayload=$linux_gfx_mode? [16:28] slangasek: OK [16:28] stgraber: it is normal that it would be waited on if eth0 doesn't exist [16:29] stgraber: since we're waiting for the full configuration of eth0. While its waiting, has eth0 been initialized by the kernel? [16:29] SpamapS: hmm, I don't know for jamespage's setup, but I'm pretty sure eth0 existed in his case [16:29] SpamapS: it's netboot with root on iscsi, so yes eth0 is initialized by ipconfig in the initramfs [16:30] Hm, so is it possible that we never get an 'ifup eth0' for that? [16:30] I would have thought 'ifup -a' would catch it in /etc/init/networking.conf [16:32] sadly my test environment here lets me install over iscsi but not boot from it (I'm missing my usual PXE server ;)) [16:32] oh, actually I guess I can extract the kernel and initrd and have kvm boot that directly [16:32] stgraber, SpamapS: I still have one of the test images locally if you want me to poke it in any way [16:33] SpamapS, stgraber: there should still be a network-device-add event which should still cause upstart to trigger an 'ifup eth0' - but what happens if you run 'ifup eth0' for this? [16:33] I'd guess then that the problem is ifup -a doesn't, for whatever reason, see eth0 as needing to come up.. and so doesn't execute the if-up.d jobs. [16:33] it's not even an ifup -a [16:33] it's /etc/init/network-interface.conf [16:33] Oh so you still get the network-device-added ? [16:33] of course [16:33] that comes from udev from coldplugging [16:33] well then wtf :) [16:34] is it possible thats happening before virtual-filesystems ? [16:34] no [16:34] ah right, udev starts on virtual filesystems [16:37] jamespage: is commented the two lines for eth0 in /etc/network/interfaces fixing the issue for you? [16:38] (looking for a workaround) [16:38] stgraber: rings a bell - lemme try [16:39] slangasek, SpamapS, jamespage: Current discussion here (with Daviey) is that we could probably just release note the workaround for now, then SRU a fix if that doesn't involve changing /etc/network/interfaces, otherwise just have it fixed for P [16:40] assuming commenting these lines workarounds the issue for jamespage [16:40] stgraber: I don't think that its an issue thats going to impact alot of people so thats prob fine [16:41] slangasek, just tried gfxpayload=text == no seg fault [16:41] jamespage: yeah, it's also a case where if you boot a server, you'll already wait 5 minutes for your BIOS, waiting 2 minutes for your first boot shouldn't be too bad (assuming you know the workaround and apply it then) [16:41] jamespage: did you get the 640x480 text again? === deryck is now known as deryck[lunch] [16:42] slangasek, I think so - ssd so boots fast - lemme double check [16:43] stgraber: commenting the entries in /etc/network/interfaces works around the issue for me [16:44] SpamapS: ok, so we at least have a workaround [16:45] stgraber: why do we want this 'manual' entry in /e/n/i? [16:47] slangasek: I can't think of a good reason for that, though I still think "inet manual" should work as it's valid syntax [16:48] should work, but it's meant for interfaces where you're going to actually *do* something via up/down rules [16:48] AFAICS this is a misuse of it; so if we can fix the bug by dropping that generated entry... [16:48] slangasek: double checked - did boot in 640x480 text mode [16:48] jamespage: and still no crash? Great, I'll mark the bug as fixed ;P [16:49] slangasek: no crash [16:49] slangasek: well, then I'll be happy to file another bug when I upgrade my servers where I have "inet manual" with a post-up and pre-down entry [16:49] as they'll be affected by the same bug with a config that actually does something [16:49] stgraber: or open an ifupdown task to go with the open-iscsi one [16:50] and we can fix open-iscsi pre-release, and fix ifupdown post-release [16:50] slangasek: agreed on that, an empty manual entry is a place holder we don't need [16:50] Could it be that ifupdown agrees, and ignores it? [16:51] dunno, testing [16:52] jcastro, ping [16:52] andreasn: hi [16:52] SpamapS: I do see if-up.d scripts being run for my ifup of a manual interface, anyway [16:59] SpamapS: and 'ifup foo' gets me a static-network-up event, so... dunno [16:59] stgraber: ^^ [16:59] what about the upstart udev bridge [17:00] stgraber: I'd suggest throwing some debugging into /etc/network/if-up.d/upstart to dump to a per-interface log file and see what's going on [17:00] is it racing with udev ? [17:00] like.. [17:00] it starts on starting udev .. [17:00] jamespage: can you try that ^ [17:00] but does it return before its actually bridging? [17:00] SpamapS: no, it always starts *before* udev and sits waiting on the netlink socket [17:00] er [17:00] SpamapS: I hope not :P I guess I can look [17:00] * SpamapS peeks at it too [17:00] slangasek: still working on getting my laptop back into a usable stage (for some reason my last reboot broke something) and then I'll try to get a complete iscsi setup for testing [17:01] stgraber: ok :) [17:02] slangasek: no, as I would have expected, it adds the udev monitor before daemonizing [17:03] SpamapS: right - I think we would be hearing about more things broken than just this, otherwise :) [17:04] if booting with --verbose , do we see the network-device-added event ? [17:11] stgraber, SpamapS: I've changed my mind; there are legitimate corner case reasons why we want the entry for the interface... so network-manager doesn't even try to touch it :P [17:11] stgraber: so I don't think we should change open-iscsi for release, but instead just SRU ifupdown (once we figure out what the problem is!) [17:12] slangasek: sounds good. I'll mark the bug as invalid for open-iscsi, we already have a task for ifupdown and the release notes [17:16] smoser: I emailed the glibc-alpha m-l about the grantpt issue. We'll see what they say [17:16] stgraber, I logged some debug output with the manual entry in /e/n/i present and commented - neither generates any log data for eth0 from /etc/network/if-up.d/upstart [17:16] (I'm expecting a spanking, tbh, but hopefully not) [17:16] only get a file for lo [17:17] SpamapS: ^ [17:17] hallyn_, link ? [17:19] smoser: http://www.cygwin.com/ml/libc-alpha/2011-10/msg00008.html [17:24] jamespage: can you boot with --verbose and look in /var/log/boot.log for the net-device-added event ? [17:24] SpamapS, sure [17:24] stgraber, jamespage, SpamapS: I notice that open-iscsi installs an if-up.d hook of its own [17:24] which sorts lexically before upstart [17:25] I wonder if it's broken? [17:25] the lo hook fired... [17:26] well, the hook special-cases lo ;) [17:26] slangasek: oh, actually, the upstart script shipped by open-iscsi looks like it could break the boot [17:26] oh excellent [17:27] Oh dear [17:27] I didn't even notice that thing before but that can explain a lot of things ;) [17:27] http://paste.ubuntu.com/706245/ [17:28] I'm guessing that as the interface is already in /run/network/ifstate, it's going to be entirely ignored by ifupdown and so we won't get the event... [17:28] yes, it forcibly bypasses if-up.d, it writes to /run/network/ifstate without locking, and it fails to use a proper 'instance' declaration for network-interface [17:29] I'm wondering if just removing it would be enough [17:29] stgraber: so it looks like an open-iscsi-specific failure after all [17:29] jamespage: can you try that? ^ [17:29] stgraber: just doing the verbose boot - one second [17:30] cjwatson: you seem to have written /etc/init/iscsi-network-interface.conf; do you recall why you were trying to prevent /etc/network/if-up.d scripts from being run for an iscsi interface? [17:31] slangasek: we are going for dinner now, if it's confirmed that it works fine without the upstart job, I'll just remove it and upload to -proposed [17:31] bug #457767 [17:31] Launchpad bug 457767 in partman-iscsi (Ubuntu Karmic) "karmic: iSCSI root: boot hangs on starting iscsid" [High,Fix released] https://launchpad.net/bugs/457767 [17:31] stgraber: enjoy :) [17:31] slangasek: I would concurr with stgraber's assessment, this script does look like its our culprit. [17:32] slangasek: or, your assessment, somebody's [17:32] SpamapS: yep - question is how we fix it... we shouldn't just drop it without taking care on upgrade to make sure users don't have configuration for the interface in /etc/network/interfaces that's going to cause the system to blow up on next boot [17:33] yeah this bug-ectomy requires some delicate scalpel work [17:34] I'm not sure why the author wanted to avoid the *.d scripts [17:34] "the author" being cjwatson [17:34] ok, so we can ask him. :) [17:35] because that is precisely the issue we have, is that they were avoided [17:35] yep === deryck[lunch] is now known as deryck [17:37] SpamapS, stgraber, slangasek: --verbose boot - http://paste.ubuntu.com/706249/ === dendrobates is now known as dendro-afk [17:38] jamespage: yep, that's consistent with our theory. kill /etc/init/iscsi* and try again? [17:39] slangasek, appears to be much happier [17:40] stgraber: ^^ [17:40] no network failsafe and I can see log data for eth0 as well as lo [17:43] jamespage: thanks; can you send that info to the bug? [17:46] slangasek, done [17:46] jamespage: cheers :) [17:46] np [17:51] slangasek: I don't see anything in the default server install that would be "bad" during if-up.. I was thinking though, don't we need to make sure eth0 is never brought down? [17:52] SpamapS: certainly [17:53] I don't think it will be brought down but wondering if maybe some scripts down/up the interface. [17:55] nothing should for interfaces not explicitly configured to have such things done [17:55] (e.g., bridge interfaces) [17:55] just trying to reason why we'd want to avoid those scripts [17:55] a lot of them make some pretty strong assumptions [17:56] though one might be able to argue that most iSCSI root boxes don't share the iscsi interface with the general network connection... it should still be possible [17:57] well, as cjwatson admits in his comment, this is a layering violation... and now it's biting us :) [18:44] jamespage: I've struck out as far as finding anything in your apt log that will explain it; the only relevant change I see is fglrx, and the only effect that had should have been reproducible with the gfxpayload change. Could you try downgrading fglrx to version 2:8.881-0ubuntu3, to see if it does bring back the segfault? [18:52] smoser: do you mind if i fwd your testcase for the libvirt pty probelm to the m-l? [18:56] oh sure, they'll have a field day. [18:56] :) [18:57] do you have your latest version somewhere? [18:59] otherwise i can just use the first version, that's fine. [19:00] i ended up trashing the instance that had your iprovements [19:01] https://gist.github.com/1251979 is where ih ad what i had. [19:01] smoser: thanks much [19:09] pitti: what was the question for me, I seem to have missed it? === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan === dendro-afk is now known as dendrobates === SanbarCo1puting is now known as SanbarComputing [20:18] pitti: it seems that librpc-xml-perl was demoted prematurely [20:19] pitti: oh, nevermind.. === chrisccoulson_ is now known as chrisccoulson === plars is now known as plars-afk [20:47] cjwatson: when we merge dpkg for P, are we going to get the hardening flags emitted like Debian is doing? === dendrobates is now known as dendro-afk [20:50] slangasek,SpamapS,stgraber: all I can really say from this vantage is that it caused a problem at the time, as noted in the comment in the script; I'm having trouble parsing my comment about /etc/network/*.d/ scripts, so it's entirely possible I was just confused [20:51] micahg: I intend to keep the flags in the environment for precise, because otherwise we'll have to convert too many packages to avoid lossage [20:51] cjwatson: i.e. different behavior than Debian? [20:51] micahg: for P, yes [20:52] although packages that have been converted to the new scheme in Debian shouldn't break; at worst, they'll have the flags specified twice [20:52] cjwatson: is this for stuff we already have in our environment or everything? My concern is that Debian is starting to abandon hardening-wrapper usage and starting to use the dpkg buildflags [20:53] micahg: packages that ask for dpkg-buildflags output will get it, don't worry [20:53] cjwatson: awesome, thanks :) [20:53] I'm just not going to remove stuff that wew already have in our environment [20:53] not until Q [20:53] yeah, that makes sense for an LTS [20:54] stgraber: it's possible I regarded manual as a hack and didn't want to depend on it [20:54] but I don't appear to have recorded my thought process very clearly, sorry [20:54] cjwatson: maybe we should just leave it in the env unless it'll break stuff, ideally we do want hardening by default (but we can save that discussion for UDS Q :)) [20:54] stgraber: I am a little concerned that there may be upgraded systems around that don't use the manual method [20:54] micahg: the things in the environment at the moment aren't hardening [20:55] ah [20:55] they're default optimisation settings and -Wl,-Bsymbolic-functions [20:55]