[06:19] <trijntje> I got a new build notification via email taking me here, but the download link on the page is dead. http://iso.qa.ubuntu.com/qatracker/milestones/226/builds/19281/testcases
[06:31] <trijntje> this is actually the second one I got, I got another one yesterday which did work. Could the last mail have been a mistake?
[06:34] <jibel> trijntje, be patient, 20101020ubuntu161has just been uploaded
[06:35] <trijntje> jibel: ok, thanks! I didn't know
[06:43] <jibel> yw
[08:44] <jibel> new alternate and server images posted to the tracker
[10:47] <jibel> stgraber, can you verify ltsp ? client fails to boot
[10:47] <jibel> no dhcp offers were received
[10:53] <jibel> hm, there is a mix up with the interface
[10:53] <jibel> s
[12:00] <gema> RAOF: I am off for the rest of the week
[12:00] <gema> RAOF: can you send me an email so that I can follow up with you next week?
[12:00] <gema> RAOF: ideally with as many details as you can
[12:01] <RAOF> gema: Certainly
[12:01] <gema> RAOF: thanks
[13:11] <stgraber> jibel: ltsp on alternate I guess?
[13:12] <jibel_> stgraber, yes, I tried another install which looked good but I couldn't see the end, my machine died of a memory burnout :/
[13:13] <stgraber> jibel_: fun... I'll give it a shot a bit later. LTSP hasn't changed since precise so I'm not really expecting any regression. Though I uploaded isc-dhcp 4.2, so if something broke, it's likely because of that.
[13:15] <jibel_> stgraber, right and that was my first guess, but investigating further showed the eth switched during boot and dhcp was attached to the wrong one.
[13:15] <stgraber> weird, I thought udev wasn't supposed to do that anymore :)
[13:17] <jibel_> well, usually I have eth0: intel eth1: amd so I know which is which but this time I had during installation eth0: amd eth1: intel, I picked intel as primary but after installation the order was different
[13:17] <jibel_> maybe it hides something else
[13:57] <patdk-wk> yay, iscsi tests failing
[14:01] <jibel_> oh that was a while ago
[14:01] <jibel_> jamespage, ^
[14:01] <patdk-wk> hmm?
[14:02] <jibel_> jamespage, did you test it ?
[14:02] <jamespage> jibel_, patdk-wk: I just did it now - reboot after install is very flakey
[14:02] <jamespage> I got one to boot after a couple of ctrl-alt-del's
[14:03] <patdk-wk> I'll try some more reboots
[14:03] <patdk-wk> so far both failed for me, amd64, with iscsi auth and no auth
[14:03] <jamespage> patdk-wk, yeah - same for me
[14:04] <jamespage> patdk-wk, just out of interest how are you running your tests?
[14:04] <patdk-wk> you try i386 yet?
[14:04] <jamespage> patdk-wk, still waiting for the iso to sync
[14:04] <jamespage> (only have 4MBps connection)
[14:04] <patdk-wk> they are vmware vm's, netbooting with the latest ipxe git, against ietd
[14:05] <jamespage> patdk-wk, yeah - I do much the same but with tgt
[14:05] <patdk-wk> I gave up using my real iscsi san device for it
[14:05] <patdk-wk> as the installer uses 2 different iscsi names :( 3 if you include ipxe
[14:06] <jamespage> patdk-wk, if you are interested - https://code.launchpad.net/~james-page/+junk/iscsi-testing
[14:06] <jamespage> I spin everything off the uuid of the VM that gets created
[14:08] <patdk-wk> I just wish the installer, when you select iscsi, would tell you the initiator name
[14:08] <patdk-wk> and then *reuse* that name for the actual install, instead of changing it
[14:08] <patdk-wk> or best it, show and let you edit :)
[14:08] <patdk-wk> I filed a bug about it awhile back
[14:09] <patdk-wk> I can't ever get mine to boot, always failing
[14:09]  * patdk-wk moves on to i386
[14:14] <jamespage> patdk-wk, I can get 64/auth to boot occasionally
[14:14] <patdk-wk> I can't :(
[14:14] <patdk-wk> I'm 0 for 6
[14:15] <jamespage> patdk-wk, have you raised a bug report yet?
[14:15] <patdk-wk> no
[14:15] <patdk-wk> was waiting for my i386 results
[14:16] <patdk-wk> they are 90% done install
[14:17] <jamespage> patdk-wk, I'll raise one now
[14:18] <patdk-wk> ya, my iso's downloaded at 8MB/sec today :)
[14:20] <jamespage> patdk-wk, bug 1028458
[14:20] <patdk-wk> looks same on i386
[14:22] <patdk-wk> do you get the ipconfig: no devices to configure, lines?
[14:27] <jamespage> patdk-wk, hmm - no
[14:27] <jamespage> In actual fact I think the servers do boot - it just does not look like they do from the console
[14:27] <patdk-wk> no, mine defently are not working with dhcp
[14:27] <patdk-wk> though, I should check tcpdump to be sure :)
[14:29] <patdk-wk> ya, I get no dhcp requests on the network
[14:30] <patdk-wk> maybe slight difference from you using preseed and I using the normal installer
[14:38] <patdk-wk> so your just getting warnings, but I'm actually failing
[14:39] <patdk-wk> guess a dhcp retry or something is working for you
[14:47] <patdk-wk> ya, there is no dhcp client in my initrd image :(
[14:50] <patdk-wk> ya, that is the difference :)
[14:50] <patdk-wk> your using static ip I guess
[14:51] <stgraber> jibel_: looks like we indeed have a dhcpd problem on quantal...
[14:51] <jibel> stgraber, what is it ?
[14:52] <stgraber> jibel: "Can't open /var/lib/dhcp/dhcpd.leases for append."
[14:53] <stgraber> jibel: apparmor profile kind of problem apparently
[14:53] <jibel> stgraber, introduced by isc-dhcp 4.2.4 or apparmor ?
[14:55] <stgraber> jibel: trying to figure out that part now, can be any of kernel, apparmor or isc-dhcp...
[14:55] <jibel> yay, respin !
[14:55] <stgraber> I'm surprised server hasn't noticed yet as it should affect them just as much...
[14:58] <stgraber> jibel: I'll go talk to #security... the profile looks good AFAICT, and I don't get any apparmor DENIED in the log, but disabling apparmor makes it work again... sounds like a kernel bug to me
[14:58] <jibel> stgraber, ack, keep me informed
[14:59] <jamespage> patdk-wk, no static addresses - all dhcp
[14:59] <patdk-wk> actually I figured it
[14:59] <patdk-wk> running, /scripts/local-top/iscsi again, at initramfs prompt, fixs it
[14:59] <patdk-wk> I guess that script is starting too soon
[15:02] <stgraber> jibel: can you file a bug against apparmor?
[15:02] <patdk-wk> yep, running that script fixs all of the tests
[15:03] <patdk-wk> that is the issue, that script is bombing out on /run isn't mounted yet
[15:03] <patdk-wk> but /run has time to mount when yo uget the prompt
[15:03] <patdk-wk> so the script runs fine then
[15:05] <jamespage> stgraber, the automated test on does a minimal verification
[15:05] <jibel> stgraber, sure, but I lost everything with my machine crash and it clearly fails to boot now. something like 'panic early exception rip 10'
[15:05] <jibel> stgraber, Ill have to setup a new system and that'll take a moment
[15:06] <stgraber> jibel: to reproduce, all you need is a working dhcpd, rm /var/lib/dhcp/*, touch /var/lib/dhcp/dhcpd.leases, chown dhcpd.dhcpd /var/lib/dhcp/dhcpd.leases, then start dhcpd
[15:06] <jibel> stgraber, ah ok, I'll do that
[15:06] <stgraber> and you'll get the "Can't open /var/lib/dhcp/dhcpd.leases for append.". doing "/etc/init.d/apparmor stop && /etc/init.d/apparmor teardown" fixes it.
[15:09] <stgraber> jibel: let me try something, might be able to get out of that mess with a small policy change in isc-dhcp
[15:09] <stgraber> jibel: it currently as "lrw" as allowed modes for dhcpd.leases (link, read, write), which you'd think would include append, but there's a separate "a" flag for that
[15:09] <stgraber> maybe passing it will fix the issue
[15:11] <stgraber> jibel: doesn't work... apparmor says "a" and "w" are mutually exclusive, fun...
[15:13] <jamespage> patdk-wk, I think you are seeing a different issue to me
[15:13] <jamespage> the DHCP bits in my setup are working fine
[15:13] <patdk-wk> hmm
[15:14] <jamespage> ipxe DHCP's OK; mounts the iSCSI volume and then boots the image - I then see what I think is a normal set of DHCPREQUEST|DISCOVER|ACK 's
[15:14] <patdk-wk> I should test it on slower hardware
[15:20] <patdk-wk> na, getting the same exact thing with real (older) hardware
[15:26] <patdk-wk> oh, your just getting that *long delayed* issue
[15:31] <patdk-wk> hmm, seems I didnt' file that bug, and can't locate it now
[15:36] <jamespage> patdk-wk, I don't think so
[15:37] <patdk-wk> no, I used to have that issue
[15:37] <patdk-wk> it would do that, but ssh worked
[15:37] <patdk-wk> for natty I think it was
[15:39] <patdk-wk> bug #728088
[15:39] <patdk-wk> but your not seeing any of the i/o issues? just the fsck?
[15:39] <patdk-wk> wonder if they are hidden? you checked dmesg?
[16:02] <jibel> stgraber, to reproduce I installed a fresh ubuntu-server
[16:02] <jibel> then installed isc-dhcp-server
[16:02] <jibel> reboot
[16:03] <jibel> and dhcpd failed to start with denied messages from apparmor
[16:03] <stgraber> jibel: dac_override?
[16:03] <jibel> stgraber, ?
[16:03] <stgraber> jibel: in the denied message, do you see "dac_override"?
[16:04] <jibel> stgraber, ah, yes
[16:04] <jibel> capname="dac_override"
[16:04] <stgraber> ok, I'll push a new isc-dhcp fixing that
[16:05] <jibel> I'll file a bug for reference
[16:06] <stgraber> jibel: thanks
[17:45] <bdmurray> gema: I just fixed an issue with http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/precise-milestone-bugs.html and was wondering if you all actually use it since it was broken for a while afaict
[20:05] <stgraber> skaet: ltsp works (tested amd64 alternate)
[20:06] <skaet> thanks stgraber :)
[20:38] <phillw> skaet: ping
[20:38] <skaet> phillw,  hiya
[20:39] <phillw> hiyas skaet I've had little 'complaint' from one of our testers. As it is about communication I think it could be resolved very easily?
[20:39] <skaet> phillw,  likely,  what's being looked for?
[20:40] <phillw> I hope not to get caught by the flame bot...
[20:40] <phillw> The spins are coming too fast, unannounced.  If they are pre-announced,
[20:40] <phillw> then I can wait for them to come.  If they hit in the middle of a test,
[20:40] <phillw> then I lose the ability to update or complete the test and all that time
[20:40] <phillw> goes for nothing.  Is there a way to get more of a heads-up for pending
[20:40] <phillw> spins and ISO images
[20:41] <stgraber> weren't the images marked for rebuild on the tracker?
[20:41] <phillw> skaet: it does not sound an unreasonable request
[20:42] <skaet> stgraber,  apparently not.
[20:42] <phillw> stgraber: they may be, but at present there is no notification of a spin being scheduled for XX:YY UTC
[20:43] <stgraber> phillw: that's because spins aren't scheduled for XX:YY UTC ;) if we knew when we'd respin ahead of time, we'd publish a schedule :)
[20:43] <skaet> phillw,   problem is our infrastructure isn't letting us nicely predict when the spins are scheduled,  however the images we've decided to respin should certainly be marked
[20:43] <stgraber> it's usually more like, "within 6 hours of package X being published, everything will be rebuilt"
[20:44] <phillw> stgraber: then maybe, a 'meet in the middle' and annouce that spins will happen in 1 hour from now? I'm sure you guys do take a little time to decide upon a respin?
[20:44] <skaet> we've pretty much got the last batch out of the build infrastructure now (just waiting for WUBI),  so I'll go ahead and mark the ones we'll do the respin on now.
[20:44] <stgraber> phillw: http://pad.ubuntu.com/ubuntu-release from #ubuntu-release's topic should answer most of that
[20:44]  * skaet nods
[21:12] <skaet> micahg,  Xubuntu desktop's finished building and should be emerging soon.
[21:13] <micahg> skaet: thanks
[21:18]  * skaet has kicked off the server rebuilds
[22:06] <skaet> phillw,  looks like we had some contention going on with the builders,  which appears to be draining now.
[22:09] <phillw> skaet: is no problem... all that is asked for is the testers be kept 'in the loop' :)