[03:48] <dank> Looks like a deadlock in the forest-of-fifos protocol.
[04:52] <cjwatson> dank: ok, possible patch in the bug
[08:27] <psivaa> cjwatson: xnox: our preseeded default installation of amd64 desktop image reports http://pastebin.ubuntu.com/5594979/
[08:28] <psivaa> i did not see any issues with manual installation though
[08:41] <cjwatson> looks like a python2.7 problem to me
[08:42] <cjwatson> but I wonder whether it's consistently reproducible ...
[08:43] <cjwatson> seems to be working fine on my raring laptop
[08:44] <cjwatson> can you get at the target system it's created?
[08:50] <stgraber> the only case where I've seen that was on my pandaboard (cosmic rays changing a couple of bits in a pyc apparently) but that was apport not the encodings module
[08:50] <cjwatson> we see that kind of thing occasionally on arms in the dc; they're crap
[08:51] <cjwatson> you notice it sometimes in build logs e.g.
[09:08] <cjwatson> well, my possible patch at least doesn't regress things in a test VM, although I can't reproduce the original issue
[09:09] <cjwatson> so I guess we wait for Larry to show up and see if he can give it a spin
[10:11] <stgraber> cjwatson: hey, I was looking into an LXC bug that's been annoying us for a while. Basically everytime we create a new container rootfs using debootstrap, the keyboard mode is changed from RAW to Unicode which makes using X a bit of a pain (alt+f4 will both close the window and change the VT).
[10:11] <stgraber> I've always assumed we were doing something wrong but now looking at bug 759674 it looks like it might be console-setup's postinst not doing the right thing
[10:11] <ubot2> Launchpad bug 759674 in console-setup (Ubuntu) "Upgrading console-setup in a chroot breaks X keymap" [Undecided,New] https://launchpad.net/bugs/759674
[10:11] <stgraber> specifically the bit about running "setupcon --force -k" when under X
[10:12] <stgraber> do you have any opinion on the matter? I'd personally be tempted to just drop that call completely (and just keep the --save-only call that requires a reboot) but that's for my specific use case and I don't pretend to see the big picture there
[10:13] <stgraber> (no rush, not planning on getting this for 13.04, or at least not in the release pocket ;))
[10:16] <cjwatson> stgraber: the underlying tool in kbd that that calls is meant to detect this situation and not actually do the ioctl, IIRC
[10:17] <cjwatson> if that isn't working, that's a problem for other reasons because I think that's called from a udev rule
[10:17] <cjwatson> so I think we should fix it rather than remove it
[10:22] <stgraber> cjwatson: ok. I confirmed that calling "/var/lib/dpkg/info/console-setup.postinst configure" from within a chroot definitely changes the kbd mode (fixable with kbd_mode -s afterwards). I'll dig a bit deeper later
[11:15] <stgraber> cjwatson: hmm, so the problem appears to be that "kbd_mode -u < /dev/tty1" in a chroot actually changes the current tty instead of tty1 (and so changes tty7). The same outside the chroot works as expected.
[11:16] <stgraber> I'll have to play with strace a bit to see exactly what's going on as the device nodes for /dev/ttyX look correct (right minor/major)
[12:33] <xnox> ev: are you about? and/or bluefin? got a question about wubi boot helper that is not popping up / offering to help rebooting.
[21:33] <mwharris> im looking for advice on how to make d-i just emit a syslog message
[21:33] <mwharris> im making a PXE target that's basically a test that PXE is set up correctly for a machine
[21:33] <mwharris> and id like to use standard d-i infra, mainly because i need remote syslog
[21:51] <cjwatson> you should just be able to say   logger -t some-tag arbitrary message
[21:53] <antarus> mwharris: I'm confused why you don't just run a custom early_command ?
[21:53] <antarus> mwharris: is your question how to exit?
[21:53] <mwharris> yeah, i suppose so.
[21:53] <mwharris> i don't want to do an install, just emit a syslog message.
[21:54] <mwharris> is early command the way to do that?
[21:54] <antarus> and then...reboot?
[21:54] <antarus> I'm confused what you want to happen afterward
[21:54] <mwharris> yeah
[21:54] <mwharris> reboot afterwards is fine.
[21:54] <antarus> can't you just call logger and then call reboot? :)
[21:54] <mwharris> sure, but how do i do that?
[21:54] <mwharris> make an early_command?
[21:54] <antarus> you would need a custom preseed, yeah
[21:54] <antarus> with a custom early_command
[21:55] <mwharris> ok, cool. i already have a custom preseed, so that's fine.
[21:55] <antarus> not sure if you can preseed the early_command url on pxe?
[21:55] <cjwatson> should be fine
[21:55]  * antarus nods
[21:55] <antarus> mwharris: sorry, I didn't quite grok what you wanted to do earlier ;p
[21:55] <mwharris> heh no worries.
[21:55] <mwharris> thanks for the help
[21:55] <cjwatson> d-i preseed/early_command string logger -t d-i HELLO; reboot
[21:55] <cjwatson> or some such
[21:56] <cjwatson> kind of a heavyweight test, but ...
[21:57] <antarus> we are batshit crazy here
[21:57] <antarus> don't worry about it ;)
[21:57] <mwharris> hehe
[21:57] <antarus> (this is one of our lightest tests, don't poke fun!)
[21:57] <mwharris> basically i want to give people an easy to test PXE setup on a machine
[22:42] <mwharris> hmm, early_command is too early, there's no networking.
[22:42] <mwharris> is there a way i can have early_command run with networking up?