[01:19] <AfterDarkness> hello i have a question: i want to apply pf patch and update my kernel to 3.19, how can i do that while ensuring the amd drivers still work? 
[01:20] <AfterDarkness> when i upgraded the kernel i had to purge fglrx in tty as my disktop will not load
[09:06] <ppisati> kees: i'm a bit confused about ARM_KERNMEM_PERMS (and DEBUG_RODATA) vs DEBUG_SET_MODULE_RONX
[09:08] <ppisati> kees: if i read it correctly, they do the same thing (make all sections but text NX and RO)
[09:09] <ppisati> kees: but the second seem to be geared towards modules only (IOW it seems to to the same dinamically on module loading etc)
[09:09] <ppisati> kees: are these options complementary? can i turn on all of the or ARM_KERNMEM_PERMS (and DEBUG_RODATA) suffice to cover all the cases?
[09:10] <ppisati> kees: and, last question, what happens when some legit code try to patch a text section? (e.g. JUMPLABELs)? does it handle that case too?
[16:43] <Zhenech> Heya, there is a bug in a DKMS package for Vivid: https://bugs.launchpad.net/ubuntu/+source/sysdig/+bug/1419402 - I proposed a patch, how do we get from there?
[16:56] <apw> Zhenech, is that already uploaded to debian ?
[16:57] <Zhenech> apw, debian has no problem, as debian does not ship .19 in jessie
[16:57] <Zhenech> .19 is in experimental, and sysdig is fixed there too
[16:57] <Zhenech> (debian bug for experimental is linked in lp)
[17:00] <apw> bah, rmadison is hating me for debian
[17:02] <apw> Zhenech, ok, using the right machine it works much better
[17:03] <Zhenech> become a DD and use dak on some debian.org host ;-)
[17:03] <apw> heh .. one day indeed
[17:04] <apw> Zhenech, anyhow, first step is bringing it to my attention
[17:04] <apw> Zhenech, and i'll have a look
[17:04] <Zhenech> check :)
[17:04] <Zhenech> I hoped subscribing kernel team would be good enough
[17:09] <apw> Zhenech, we get a heck of a lot of bugs subbed to us, it is easy to miss them, cirtianly coming here gets our attentoin
[17:52] <Odd_Bloke> bjf: I'm seeing a kernel test failure (when running in GCE): http://paste.ubuntu.com/10622256/  Is that an actual problem?
[17:55] <bjf> Odd_Bloke, which series?
[17:56] <Odd_Bloke> bjf: trusty.
[17:59] <bjf> Odd_Bloke, i'm not seeing that particular error with my testing. sbeattie ^ ?
[18:00]  * sbeattie looks
[18:01] <sbeattie> yeah, that's a problem if true. I've not seen it in my testing, either.
[18:02] <sbeattie> Odd_Bloke: can you verify that wine and qemu-kvm-extras-static are not installed?
[18:02] <Odd_Bloke> Checking.
[18:04] <Odd_Bloke> Neither is installed at instance spin-up, let me wait for the test script to finish and I'll check then as well.
[18:06] <sbeattie> Does GCE run our kernel or google special sauce?
[18:06]  * sbeattie hasn't looked at GCE before.
[18:06] <Odd_Bloke> Our kernel, I believe.
[18:07] <Odd_Bloke> Neither installed after the test has run.
[18:07] <Odd_Bloke> sbeattie: You should be able to get to ubuntu@130.211.100.128, if you want to have a poke around.
[18:11] <sbeattie> Odd_Bloke: this looks to be the culprit:
[18:11] <sbeattie>  /etc/sysctl.d/99-gce.conf:# randomizes addresses of mmap base, heap, stack and VDSO page
[18:11] <sbeattie>  /etc/sysctl.d/99-gce.conf:vm.mmap_min_addr = 0
[18:12] <apw> isn't that below the minimum we allow ?
[18:12] <sbeattie> kees: do you know why GCE would be doing that?
[18:13] <Odd_Bloke> This is following the recommendation at https://cloud.google.com/compute/docs/tutorials/building-images#kernelbuild
[18:13] <Odd_Bloke> Which has "CONFIG_DEFAULT_MMAP_MIN_ADDR=65536" and 'echo "vm.mmap_min_addr = 0" > /etc/sysctl.d/mmap_min_addr.conf' as equivalent recommendations.
[18:14] <Odd_Bloke> Or maybe not equivalent, I don't know enough about sysctl to make that statement.
[18:14] <Odd_Bloke> Would it make sense for that 0 to be a typo?
[18:15] <sbeattie> I would hope it's a typo. They're definitely not equivalent.
[18:16] <Odd_Bloke> OK, I'll run it past someone at Google to try and work out what they mean.
[18:17] <sbeattie> Or at least, if not a typo, an insufficient explanation of how to disable it for the very few applications that break because it's set to non-zero.
[18:20] <sbeattie> Odd_Bloke: I'm logged out of your instance.
[18:21] <Odd_Bloke> sbeattie: Ack; thanks for taking a look.
[18:22] <sbeattie> Odd_Bloke: sure thing, thanks for raising the issue.
[18:38] <Odd_Bloke> sbeattie: Have filed an internal issue for it, and subscribed you; should be fixed soon.
[18:39] <sbeattie> Odd_Bloke: thanks!
[18:46] <kees> sbeattie: omg, wtf! no, it should NOT be doing that!
[18:46] <kees> sbeattie: where is that sysctl coming from? did google build that?
[18:48] <sbeattie> kees: I think the thing to get fixed is the MMAP_MIN_ADDR section in https://cloud.google.com/compute/docs/tutorials/building-images#kernelbuild
[19:10] <mterry> Hello!  I'm trying to boot an Ubuntu Snappy image off a thumb drive.  I seem to be getting some kernel panic and a reboot during boot.  How do I dig deeper / work around it?
[19:10] <mterry> I can't clearly see the panic because it reboots...
[19:10] <mterry> And there isn't a grub menu so I can modify kernel parameters
[19:10] <mterry> Though I can edit the thumb drive manually, I'm less familiar with that bit
[19:11] <apw> mterry, hmmm well i'd suggest taking pictures, and depending on the board does it have one of those header serial ports 
[19:11] <apw> either of those might get you the panic and a clue
[19:11] <apw> what are you booting it on as well ?
[19:11] <mterry> apw, I'm just trying to boot on my laptop
[19:12] <apw> hmmm
[19:12] <mterry> apw, I can't take a picture, because the screen disappears so quickly
[19:12] <mterry> I suppose I could take a movie and take a frame
[19:12] <apw> a video might get it if you are lucky
[19:12] <apw> deperate times and all that
[19:12]  * mterry tries out Ubuntu Touch's video capability
[19:12] <apw> have you asked in #snappy in case someone else is seeing it ?
[19:12] <mterry> apw, I sent quick email to the snappy list, no replies yet
[19:13] <mterry> apw, I don't think this is commonly done yet in snappy world?  I think most people just use beagleboards or kvm
[19:14] <apw> mterry, right that would be my expectation too  ... so i am not supprised its not perfect
[19:14] <mterry> apw, asked on #snappy in case I get lucky.  Meanwhile will try to get a pic
[19:14] <mterry> apw, thanks for help so far!  :)
[19:21] <mterry> apw, https://chinstrap.canonical.com/~mterry/snappy-panic.png  -- snappy-devel just said "Aren't we using just the generic kernel pkg on x86? If so, you are missing all the modules from the generic-extra pkg, thus my bet is on a missing module"
[19:22] <mterry> Does that panic look like that makes sense?  If so, I guess my next step is wondering how to get snappy to let me install those modules
[19:23] <apw> so that looks like systemd exited
[19:26] <mterry> apw, yeah, says "attempted to kill init"
[19:26] <infinity> mterry: That's failing to pivot out of the initrd.
[19:26]  * mterry is super unfamiliar with debugging systemd
[19:27] <infinity> mterry: systemd isn't even in play yet.
[19:27] <mterry> ok
[19:27] <ppisati> mterry: mount the img, download the linux-image-extra pkg corresponding to the kernel used in that img
[19:27] <ppisati> mterry: and install it
[19:27] <infinity> mterry: Where's the image you're booting?
[19:28] <ppisati> mterry: IOW, boot into ubuntu, plug the usb stick, chroot in it, install the pkg, etc
[19:28] <infinity> Also, how on earth is that taking 3 seconds to get out of the initrd?  What evil is snappy perpetrating?
[19:28] <mterry> ppisati, well installing on snappy via apt, even using /usr/bin/apt directly, has been unsuccessful for me.  read-only mounts and such.  I guess I can just remount them all rw
[19:29] <ppisati> mterry: yep, and apt is a symlink but you can find the original apt in /usr/local
[19:29] <mterry> infinity, http://cdimage.ubuntu.com/ubuntu-core/preview/ubuntu-core-alpha-02_amd64-virt.img is a qcow2 file that I'm booting 
[19:29] <mterry> ppisati, I think you have that reveresd
[19:32] <mterry> infinity, I can't speak to the evils of snappy yet ;)
[19:32]  * ppisati just bought an xps 13
[19:32] <ppisati> lovely
[19:33] <mterry> ppisati, they are good laptops besides this oddity!  :)  I also tried booting on another Dell I have here, same result
[19:34] <ppisati> mterry: ping lool, i know he did some work for snappy and real x86 hw
[19:34] <infinity> mterry: Right, so that boots fine in kvm.  I'm sure it's failing to find your USB controller due to the fact that someone decided linux-image-virtual was good enough.
[19:34] <infinity> mterry: s/linux-image-virtual/linux-image-generic/ in the build scripts would likely make it happy for you.
[19:35] <infinity> Though the -virt in the filename sort if implies it's not meant for real hardware.
[19:36] <infinity> The tarball builds have the full kernel in them.
[19:36] <infinity> I'm guessing this "preview" is old?
[19:36] <mterry> infinity, maybe?  It's still the one the snappy site recommends
[19:37] <infinity> Well, it's 3.18.0-9, so it's not new.
[19:38] <mterry> infinity, maybe I need to find out how to build my own new preview then, with -generic.  Thanks for the pointers!
[19:41] <infinity> mterry: FWIW, snappy switched from -virtual to -generic on Jan 28, and that kernel is from Jan 12.
[19:41] <infinity> mterry: So, the image is just old and predates the fix.
[19:41] <infinity> mterry: Sort out how to get someone to make a fresh one, and you'll likely be set (or find instructions on how to turn the daily tarball into a bootable image)
[19:42]  * mterry hugs infinity for his detective work
[20:26] <apw> infinity, nice thanks
[21:23] <kees> sbeattie: yikes
[21:23] <kees> sbeattie: I'll get them to fix that.
[21:23] <kees> sbeattie: who did the sysctl file in the ubuntu image? was that someone else reading the "documentation" or was that generated by someone in google?
[21:24] <sbeattie> Odd_Bloke: do you know the answer to kees' question?
[22:31] <kees> sbeattie: fire started, docs should be changing shortly, and when cansecwest is over, existing images will likely get reviewed.
[23:29] <sbeattie> kees: w00t, thanks!