| slangasek | apw, bjf: a lot of autopkgtest failures recently for linux/ppc64el in zesty; are we going to be getting back to green sometime soon? | 02:02 |
|---|---|---|
| bjf | slangasek, please bring that up tomorrow with sforshee and rtg | 02:48 |
| bjf | slangasek, actually, the tests look pretty good to me. the one real failure i'm seeing is with the kernel selftests. it looks like upstream hasn't built it on that platform | 02:57 |
| slangasek | bjf: so could the testsuite itself detect that, so that we don't have to dig into the logs each time to know whether the failure is ignorable? | 04:49 |
| === zyga_ is now known as zyga | ||
| === shadeslayer_ is now known as shadeslayer | ||
| === JanC_ is now known as JanC | ||
| sforshee | slangasek, bjf: the ppc selftests failure on ppc64el is because some of the tests don't build with pie enabled. We have a fix comitted, but since the tests run based on the zesty master branch it won't pass until the current kernel is released and master gets updated. | 12:11 |
| === zyga_ is now known as zyga | ||
| apw | sforshee, is that zesty master ? | 12:45 |
| apw | sforshee, if so you could probabally just shove it out as we care a lot less that that one rebases (which it likely won't anyhow) before release day | 12:46 |
| sforshee | apw: yeah I suppose. I was wondering though if the tests shouldn't be checking out the tag for the kernel under test. | 12:50 |
| apw | sforshee, these are the kernel self-tests right ? | 12:51 |
| sforshee | apw: yes | 12:51 |
| elmo | hey, I just rolled to 4.10! \o/ | 12:52 |
| apw | heh | 12:52 |
| apw | elmo, and you are able to login to tell me so, so something must work | 12:53 |
| rtg | apw, sforshee - will defaulting to consoleblank=0 in Zesty have any deleterious side effects that you can think of ? See https://bugs.launchpad.net/ubuntu/+source/kbd/+bug/869017/comments/14 | 13:16 |
| ubot5 | Ubuntu bug 869017 in kbd (Ubuntu) "Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)" [Medium,Triaged] | 13:16 |
| sforshee | rtg: nothing comes to mind. My guess is that comment is right, that it was probably set up that way to avoid burn-in on CRTs which isn't as much of a concern nowadays | 13:24 |
| rtg | sforshee, I'm sure it'll piss off someone though :) | 13:25 |
| sforshee | rtg: no doubt | 13:25 |
| snoerd | hey, since #ubuntu-boot seems to be abandoned, I'll try my luck here. Does anybody here have any experience with nfs-boot and overlayroot? | 14:37 |
| apw | snoerd, i personally do not but there are people who who likely have played with that kind of thing | 14:47 |
| apw | snoerd, but i would also suggest as people are on wildly different timezones, that | 14:47 |
| apw | snoerd, you ask your question so people don't tell you they know and leave | 14:47 |
| snoerd | apw: thanks, good point. My issue is plain and simple: booting over nfs works ( root dir passed as kernel parameter), as soon as I enable overlayroot, it hangs after successfully enabling overlayroot. It just prints "done" and that's been it | 14:52 |
| snoerd | here's a screenshot: https://postimg.org/image/x14ljvolr/ | 14:53 |
| apw | snoerd, have you tried a "break=bottom" to get a shell at that point and have a look around ? | 14:54 |
| apw | snoerd, look at dmesg that kind of thing | 14:55 |
| snoerd | ahh, didn't know that parameter yet, thx. normally I'm poking around in userspace. gimme a sec | 14:55 |
| apw | it actually is a userspace implemented thing, by initramfs-tools, but goes on the kernel command line for giggles | 14:56 |
| snoerd | apw, sorry, was on the phone. If I use that parameter, I do in fact get a busybox shell at the end. however I cannot see something suspicous. only strange thing is that my nfs share is mounted in /root | 15:06 |
| apw | snoerd, and is the overlay mounted yet ? | 15:06 |
| * apw though bottom was after root was mounted | 15:07 | |
| apw | ie literally the next thing was chroot into it | 15:07 |
| snoerd | doesn't look like it | 15:08 |
| snoerd | i can actually chroot into /root, but I get an "inappropriate ioctl for device" error from bash | 15:11 |
| snoerd | but it still works | 15:11 |
| snoerd | hm | 15:11 |
| snoerd | but no overlay | 15:11 |
| snoerd | ls | 15:12 |
| snoerd | damn :) | 15:12 |
| apw | snoerd, oh that is before bottom, breaks=init instead | 15:13 |
| apw | break=init | 15:13 |
| snoerd | ahh, thanks. I'll try that | 15:18 |
| snoerd | yeah, now I get the overlayroot. | 15:19 |
| apw | now at least you can see if it is working at all | 15:19 |
| snoerd | ahh, i guess there is something severly broken. I just get a scrambled stack trace when I try to chroot into it | 15:20 |
| snoerd | also, i can read in the overlay, but not write | 15:21 |
| snoerd | after a bit of trying a got a readable version of the stacktrace. it happend when I tried to chroot into the overlay. maybe it is of help https://postimg.org/image/kjr8gav3r/ | 15:28 |
| snored | if somebody has a followup on the bug i've posted: I've joined this channel with my regular nick 'jules' | 15:47 |
| apw | jules, hey ... did you put a simple how to reproduce this in your bug ? i assume it is pretty easy | 15:48 |
| apw | jules, if so then i recon that that one can be bisected in a VM or something | 15:48 |
| apw | jules, also what was the bug # ?? | 15:49 |
| jules | apw: I haven't reported it yet. reproducing it should be fairly straight forward, but you have to have a working PXE environment, which is a bit of a hazzle to set up. | 15:53 |
| apw | jules, well if you are able to test kernels for it, we likely can supply them | 15:54 |
| jules | apw: that should be no big deal. I'm writing the bug report now | 15:55 |
| jules | apw: filed as bug #1675086 | 16:29 |
| ubot5 | bug 1675086 in linux (Ubuntu) "Kernel Bug when using nfsroot + overlayroot at the same time" [Undecided,New] https://launchpad.net/bugs/1675086 | 16:29 |
| === mhcerri_ is now known as mhcerri | ||
| === acheronUK is now known as acheronuk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!