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:19 |
---|---|---|
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:31 |
jibel | trijntje, be patient, 20101020ubuntu161has just been uploaded | 06:34 |
trijntje | jibel: ok, thanks! I didn't know | 06:35 |
jibel | yw | 06:43 |
jibel | new alternate and server images posted to the tracker | 08:44 |
jibel | stgraber, can you verify ltsp ? client fails to boot | 10:47 |
jibel | no dhcp offers were received | 10:47 |
jibel | hm, there is a mix up with the interface | 10:53 |
jibel | s | 10:53 |
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:00 |
RAOF | gema: Certainly | 12:01 |
gema | RAOF: thanks | 12:01 |
=== _salem is now known as salem_ | ||
stgraber | jibel: ltsp on alternate I guess? | 13:11 |
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:12 |
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:13 |
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:15 |
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:17 |
patdk-wk | yay, iscsi tests failing | 13:57 |
jibel_ | oh that was a while ago | 14:01 |
jibel_ | jamespage, ^ | 14:01 |
patdk-wk | hmm? | 14:01 |
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:02 |
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:03 |
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:04 |
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:05 |
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:06 |
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:08 |
patdk-wk | I can't ever get mine to boot, always failing | 14:09 |
* patdk-wk moves on to i386 | 14:09 | |
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:14 |
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:15 |
patdk-wk | they are 90% done install | 14:16 |
jamespage | patdk-wk, I'll raise one now | 14:17 |
patdk-wk | ya, my iso's downloaded at 8MB/sec today :) | 14:18 |
jamespage | patdk-wk, bug 1028458 | 14:20 |
ubot5 | Launchpad bug 1028458 in Ubuntu "iSCSI root based servers fail to boot" [Undecided,New] https://launchpad.net/bugs/1028458 | 14:20 |
patdk-wk | looks same on i386 | 14:20 |
patdk-wk | do you get the ipconfig: no devices to configure, lines? | 14:22 |
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:27 |
patdk-wk | ya, I get no dhcp requests on the network | 14:29 |
patdk-wk | maybe slight difference from you using preseed and I using the normal installer | 14:30 |
patdk-wk | so your just getting warnings, but I'm actually failing | 14:38 |
patdk-wk | guess a dhcp retry or something is working for you | 14:39 |
patdk-wk | ya, there is no dhcp client in my initrd image :( | 14:47 |
patdk-wk | ya, that is the difference :) | 14:50 |
patdk-wk | your using static ip I guess | 14:50 |
stgraber | jibel_: looks like we indeed have a dhcpd problem on quantal... | 14:51 |
jibel | stgraber, what is it ? | 14:51 |
stgraber | jibel: "Can't open /var/lib/dhcp/dhcpd.leases for append." | 14:52 |
stgraber | jibel: apparmor profile kind of problem apparently | 14:53 |
jibel | stgraber, introduced by isc-dhcp 4.2.4 or apparmor ? | 14:53 |
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:55 |
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:58 |
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 | 14:59 |
stgraber | jibel: can you file a bug against apparmor? | 15:02 |
patdk-wk | yep, running that script fixs all of the tests | 15:02 |
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:03 |
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:05 |
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:06 |
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:09 |
stgraber | jibel: doesn't work... apparmor says "a" and "w" are mutually exclusive, fun... | 15:11 |
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:13 |
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:14 |
patdk-wk | na, getting the same exact thing with real (older) hardware | 15:20 |
patdk-wk | oh, your just getting that *long delayed* issue | 15:26 |
patdk-wk | hmm, seems I didnt' file that bug, and can't locate it now | 15:31 |
jamespage | patdk-wk, I don't think so | 15:36 |
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:37 |
patdk-wk | bug #728088 | 15:39 |
ubot5 | 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 |
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? | 15:39 |
=== yofel_ is now known as yofel | ||
jibel | stgraber, to reproduce I installed a fresh ubuntu-server | 16:02 |
jibel | then installed isc-dhcp-server | 16:02 |
jibel | reboot | 16:02 |
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:03 |
jibel | stgraber, ah, yes | 16:04 |
jibel | capname="dac_override" | 16:04 |
stgraber | ok, I'll push a new isc-dhcp fixing that | 16:04 |
jibel | I'll file a bug for reference | 16:05 |
stgraber | jibel: thanks | 16:06 |
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 | 17:45 |
=== zyga is now known as zyga-afk | ||
=== Ursinha` is now known as Ursinha | ||
=== Ursinha is now known as Guest69114 | ||
stgraber | skaet: ltsp works (tested amd64 alternate) | 20:05 |
skaet | thanks stgraber :) | 20:06 |
phillw | skaet: ping | 20:38 |
skaet | phillw, hiya | 20:38 |
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:39 |
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:40 |
stgraber | weren't the images marked for rebuild on the tracker? | 20:41 |
phillw | skaet: it does not sound an unreasonable request | 20:41 |
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:42 |
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:43 |
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 | 20:44 | |
skaet | micahg, Xubuntu desktop's finished building and should be emerging soon. | 21:12 |
micahg | skaet: thanks | 21:13 |
* skaet has kicked off the server rebuilds | 21:18 | |
=== salem_ is now known as _salem | ||
skaet | phillw, looks like we had some contention going on with the builders, which appears to be draining now. | 22:06 |
phillw | skaet: is no problem... all that is asked for is the testers be kept 'in the loop' :) | 22:09 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!