[02:02] <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:48] <bjf> slangasek, please bring that up tomorrow with sforshee and rtg
[02:57] <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
[04:49] <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?
=== zyga_ is now known as zyga
=== shadeslayer_ is now known as shadeslayer
=== JanC_ is now known as JanC
[12:11] <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.
=== zyga_ is now known as zyga
[12:45] <apw> sforshee, is that zesty master ?
[12:46] <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:50] <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:51] <apw> sforshee, these are the kernel self-tests right ?
[12:51] <sforshee> apw: yes
[12:52] <elmo> hey, I just rolled to 4.10! \o/
[12:52] <apw> heh
[12:53] <apw> elmo, and you are able to login to tell me so, so something must work
[13:16] <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:24] <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:25] <rtg> sforshee, I'm sure it'll piss off someone though :)
[13:25] <sforshee> rtg: no doubt
[14:37] <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:47] <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:52] <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:53] <snoerd> here's a screenshot: https://postimg.org/image/x14ljvolr/
[14:54] <apw> snoerd, have you tried a "break=bottom" to get a shell at that point and have a look around ?
[14:55] <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:56] <apw> it actually is a userspace implemented thing, by initramfs-tools, but goes on the kernel command line for giggles
[15:06] <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:07]  * apw though bottom was after root was mounted
[15:07] <apw> ie literally the next thing was chroot into it
[15:08] <snoerd> doesn't look like it
[15:11] <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:12] <snoerd> ls
[15:12] <snoerd> damn :)
[15:13] <apw> snoerd, oh that is before bottom, breaks=init instead
[15:13] <apw> break=init
[15:18] <snoerd> ahh, thanks. I'll try that
[15:19] <snoerd> yeah, now I get the overlayroot. 
[15:19] <apw> now at least you can see if it is working at all
[15:20] <snoerd> ahh, i guess there is something severly broken. I just get a scrambled stack trace when I try to chroot into it
[15:21] <snoerd> also, i can read in the overlay, but not write
[15:28] <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:47] <snored> if somebody has a followup on the bug i've posted: I've joined this channel with my regular nick 'jules' 
[15:48] <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:49] <apw> jules, also what was the bug # ??
[15:53] <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:54] <apw> jules, well if you are able to test kernels for it, we likely can supply them
[15:55] <jules> apw: that should be no big deal. I'm writing the bug report now
[16:29] <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
=== mhcerri_ is now known as mhcerri
=== acheronUK is now known as acheronuk