[01:03] <infinity> ev / cjwatson : Okay, so that bug was entirely misrepresented to me as somehow relating to us using the debconf frontend which, in fact, upon testing locally, it's pretty clear we don't.  Not a seed issue, per se (we use default seed), but a live-build config issue.
[08:57] <ev> jibel: would you be so kind as to reproduce bug 743359, and get a `ps auxf > ps.log` at the time of the crash? I'm surprised that my proposed fix didn't solve it. Not sure what else it could be.
[08:58] <ubot2> Launchpad bug 743359 in ubiquity "Installer: LockFailedException: Failed to lock /target/var/cache/apt/archives/lock" [High,Triaged] https://launchpad.net/bugs/743359
[11:47] <jibel> ev, that's weird, I can reproduce the LockFailedException with Beta2 but not today's images. Ubiquity is 2.6.35 on both (2.6.36 failed to build)
[11:47] <jibel> I'll try to fully update beta2 before installing to check if that makes a difference.
[11:49] <jibel> s/2.6/2.7
[13:19] <jibel> I applied all updates (excepted kernel) before installation and then Beta 2 installation didn't failed. I'll update the bug report with the logs when ubiquity crashes.
[14:08] <stgraber> cjwatson: looking at bug 848072 I'm now wondering if it's not caused by netcfg flushing the addresses and routes only when using static addressing (if I'm reading netcfg's code properly)
[14:08] <ubot2> Launchpad bug 848072 in netcfg "[oneiric] net-installer dhcp client fails with a DHCPDECLINE" [Medium,Confirmed] https://launchpad.net/bugs/848072
[14:10] <stgraber> is there any reason not to have netcfg flush all the addresses and routes before attempting autoconfiguration, at least for dhcpv4 (v6 might be a bit trickier because of slaac)
[14:10] <cjwatson> stgraber: could be.  I think the dhclient-script at least sometimes flushes addresses but not routes
[14:10] <cjwatson> it sounds like it makes sense, from ten seconds' thought :-)
[14:13] <stgraber> I'll try to hack netcfg to always flush everything on startup, then run that through my tests and see if something breaks :) having dhclient-script do it only works if we do DHCP twice, not if you have some mix of static and DHCP (tftp says DHCP but then kickstart says static)
[14:16] <cjwatson> right
[15:07] <stgraber> cjwatson: is there a reason why netcfg would be started more than twice when using kickstart for preseeding?
[15:09] <cjwatson> more than twice?  I don't think so.  twice, yes
[15:11] <stgraber> cjwatson: http://paste.ubuntu.com/697929/ (grep "Starting netcfg" in /var/log/syslog)
[15:11] <stgraber> cjwatson: http://paste.ubuntu.com/697930/ full syslog
[15:12] <stgraber> cjwatson: I'm mostly looking at what's happening around the DHCPDECLINE and I see 3 "Starting netcfg" around that time
[15:12] <cjwatson> hmmmm.
[15:14] <superm1> jibel, i'd think you can generate on beta2 but not today's because beta2 has more updates to download, whereas today's includes more of them
[15:14] <superm1> so the apt-get upgrade process runs longer on b2
[15:16] <cjwatson> I really can't see why that's happening
[15:16] <cjwatson> it's not execing itself AFAICS, and kickseed only calls netcfg.postinst once
[15:20] <stgraber> running the exact same setup without kickstart starts netcfg twice, so still one more time than it should
[15:25] <jibel> superm1, agree. ev's fix yesterday should have fixed it, but it seems apt still holds the lock.
[15:26] <superm1> jibel, well when the dash process gets send the terminate signal, does it also terminate children?
[15:29] <cjwatson> if it has to, that usually indicates a bug elsewhere
[15:29] <cjwatson> perhaps failure to work around python's SIGPIPE bug?
[15:29] <jibel> superm1, no it doesn't
[15:31] <jibel> superm1, it continues to run hence the crash when ubiquity tries to install other packages like langpacks
[15:33] <stgraber> cjwatson: http://paste.ubuntu.com/697948/ (the "with arg: %s" part shows argv[1])
[15:34] <CIA-45> wubi: evand * r237 trunk/ (4 files in 2 dirs): Removed unused Ubuntu Netbook images (symlinks).
[15:35] <stgraber> got to run, will be back in an hour
[17:21] <stgraber> cjwatson: ok, so I also see netcfg being called with 255.255.255.0 as first parameter when booting without ks=, I did a quick grep through the initrd to try and find what's doing that call but couldn't find any match. Any idea?
[18:27] <cjwatson> stgraber: I'm as puzzled as you are; I'll continue thinking about it
[18:28] <stgraber> cjwatson: I guess I'll just strace the whole install process and see what I get...
[18:28] <cjwatson> it'd be nice to know the parent of the offending netcfg processes
[18:53] <stgraber> cjwatson: /sbin/dhclient-script is the parent (unless I messed up my very hackish PPID check :))
[18:56] <stgraber> cjwatson: ok, found it: new_mask="/$(ptom $new_subnet_mask)"
[18:58] <stgraber> so that's not something to be worried about, though I guess netcfg should be changed not to print it's "Starting netcfg..." message when only the ptom function is used
[19:03] <cjwatson> ah, right, got it.  easy fix, I'll do that later
[20:26] <stgraber> cjwatson: when you have a sec, can you look at the patch in bug 848072 it seems to fix the bug and doesn't seem to regress anything obvious
[20:26] <ubot2> Launchpad bug 848072 in netcfg "[oneiric] net-installer dhcp client fails with a DHCPDECLINE" [Medium,Confirmed] https://launchpad.net/bugs/848072