[06:19] 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] 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] trijntje, be patient, 20101020ubuntu161has just been uploaded [06:35] jibel: ok, thanks! I didn't know [06:43] yw [08:44] new alternate and server images posted to the tracker [10:47] stgraber, can you verify ltsp ? client fails to boot [10:47] no dhcp offers were received [10:53] hm, there is a mix up with the interface [10:53] s [12:00] RAOF: I am off for the rest of the week [12:00] RAOF: can you send me an email so that I can follow up with you next week? [12:00] RAOF: ideally with as many details as you can [12:01] gema: Certainly [12:01] RAOF: thanks === _salem is now known as salem_ [13:11] jibel: ltsp on alternate I guess? [13:12] 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] 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] 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] weird, I thought udev wasn't supposed to do that anymore :) [13:17] 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] maybe it hides something else [13:57] yay, iscsi tests failing [14:01] oh that was a while ago [14:01] jamespage, ^ [14:01] hmm? [14:02] jamespage, did you test it ? [14:02] jibel_, patdk-wk: I just did it now - reboot after install is very flakey [14:02] I got one to boot after a couple of ctrl-alt-del's [14:03] I'll try some more reboots [14:03] so far both failed for me, amd64, with iscsi auth and no auth [14:03] patdk-wk, yeah - same for me [14:04] patdk-wk, just out of interest how are you running your tests? [14:04] you try i386 yet? [14:04] patdk-wk, still waiting for the iso to sync [14:04] (only have 4MBps connection) [14:04] they are vmware vm's, netbooting with the latest ipxe git, against ietd [14:05] patdk-wk, yeah - I do much the same but with tgt [14:05] I gave up using my real iscsi san device for it [14:05] as the installer uses 2 different iscsi names :( 3 if you include ipxe [14:06] patdk-wk, if you are interested - https://code.launchpad.net/~james-page/+junk/iscsi-testing [14:06] I spin everything off the uuid of the VM that gets created [14:08] I just wish the installer, when you select iscsi, would tell you the initiator name [14:08] and then *reuse* that name for the actual install, instead of changing it [14:08] or best it, show and let you edit :) [14:08] I filed a bug about it awhile back [14:09] I can't ever get mine to boot, always failing [14:09] * patdk-wk moves on to i386 [14:14] patdk-wk, I can get 64/auth to boot occasionally [14:14] I can't :( [14:14] I'm 0 for 6 [14:15] patdk-wk, have you raised a bug report yet? [14:15] no [14:15] was waiting for my i386 results [14:16] they are 90% done install [14:17] patdk-wk, I'll raise one now [14:18] ya, my iso's downloaded at 8MB/sec today :) [14:20] patdk-wk, bug 1028458 [14:20] Launchpad bug 1028458 in Ubuntu "iSCSI root based servers fail to boot" [Undecided,New] https://launchpad.net/bugs/1028458 [14:20] looks same on i386 [14:22] do you get the ipconfig: no devices to configure, lines? [14:27] patdk-wk, hmm - no [14:27] In actual fact I think the servers do boot - it just does not look like they do from the console [14:27] no, mine defently are not working with dhcp [14:27] though, I should check tcpdump to be sure :) [14:29] ya, I get no dhcp requests on the network [14:30] maybe slight difference from you using preseed and I using the normal installer [14:38] so your just getting warnings, but I'm actually failing [14:39] guess a dhcp retry or something is working for you [14:47] ya, there is no dhcp client in my initrd image :( [14:50] ya, that is the difference :) [14:50] your using static ip I guess [14:51] jibel_: looks like we indeed have a dhcpd problem on quantal... [14:51] stgraber, what is it ? [14:52] jibel: "Can't open /var/lib/dhcp/dhcpd.leases for append." [14:53] jibel: apparmor profile kind of problem apparently [14:53] stgraber, introduced by isc-dhcp 4.2.4 or apparmor ? [14:55] jibel: trying to figure out that part now, can be any of kernel, apparmor or isc-dhcp... [14:55] yay, respin ! [14:55] I'm surprised server hasn't noticed yet as it should affect them just as much... [14:58] 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] stgraber, ack, keep me informed [14:59] patdk-wk, no static addresses - all dhcp [14:59] actually I figured it [14:59] running, /scripts/local-top/iscsi again, at initramfs prompt, fixs it [14:59] I guess that script is starting too soon [15:02] jibel: can you file a bug against apparmor? [15:02] yep, running that script fixs all of the tests [15:03] that is the issue, that script is bombing out on /run isn't mounted yet [15:03] but /run has time to mount when yo uget the prompt [15:03] so the script runs fine then [15:05] stgraber, the automated test on does a minimal verification [15:05] 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] stgraber, Ill have to setup a new system and that'll take a moment [15:06] 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] stgraber, ah ok, I'll do that [15:06] 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] jibel: let me try something, might be able to get out of that mess with a small policy change in isc-dhcp [15:09] 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] maybe passing it will fix the issue [15:11] jibel: doesn't work... apparmor says "a" and "w" are mutually exclusive, fun... [15:13] patdk-wk, I think you are seeing a different issue to me [15:13] the DHCP bits in my setup are working fine [15:13] hmm [15:14] 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] I should test it on slower hardware [15:20] na, getting the same exact thing with real (older) hardware [15:26] oh, your just getting that *long delayed* issue [15:31] hmm, seems I didnt' file that bug, and can't locate it now [15:36] patdk-wk, I don't think so [15:37] no, I used to have that issue [15:37] it would do that, but ssh worked [15:37] for natty I think it was [15:39] bug #728088 [15:39] Launchpad bug 728088 in open-iscsi (Ubuntu Oneiric) "iscsi root with or without auth fails to boot" [High,Fix released] https://launchpad.net/bugs/728088 [15:39] but your not seeing any of the i/o issues? just the fsck? [15:39] wonder if they are hidden? you checked dmesg? === yofel_ is now known as yofel [16:02] stgraber, to reproduce I installed a fresh ubuntu-server [16:02] then installed isc-dhcp-server [16:02] reboot [16:03] and dhcpd failed to start with denied messages from apparmor [16:03] jibel: dac_override? [16:03] stgraber, ? [16:03] jibel: in the denied message, do you see "dac_override"? [16:04] stgraber, ah, yes [16:04] capname="dac_override" [16:04] ok, I'll push a new isc-dhcp fixing that [16:05] I'll file a bug for reference [16:06] jibel: thanks [17:45] 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 === zyga is now known as zyga-afk === Ursinha` is now known as Ursinha === Ursinha is now known as Guest69114 [20:05] skaet: ltsp works (tested amd64 alternate) [20:06] thanks stgraber :) [20:38] skaet: ping [20:38] phillw, hiya [20:39] 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] phillw, likely, what's being looked for? [20:40] I hope not to get caught by the flame bot... [20:40] The spins are coming too fast, unannounced. If they are pre-announced, [20:40] then I can wait for them to come. If they hit in the middle of a test, [20:40] then I lose the ability to update or complete the test and all that time [20:40] goes for nothing. Is there a way to get more of a heads-up for pending [20:40] spins and ISO images [20:41] weren't the images marked for rebuild on the tracker? [20:41] skaet: it does not sound an unreasonable request [20:42] stgraber, apparently not. [20:42] stgraber: they may be, but at present there is no notification of a spin being scheduled for XX:YY UTC [20:43] 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] 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] it's usually more like, "within 6 hours of package X being published, everything will be rebuilt" [20:44] 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] 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] phillw: http://pad.ubuntu.com/ubuntu-release from #ubuntu-release's topic should answer most of that [20:44] * skaet nods [21:12] micahg, Xubuntu desktop's finished building and should be emerging soon. [21:13] skaet: thanks [21:18] * skaet has kicked off the server rebuilds === salem_ is now known as _salem [22:06] phillw, looks like we had some contention going on with the builders, which appears to be draining now. [22:09] skaet: is no problem... all that is asked for is the testers be kept 'in the loop' :)