[03:05] <ChrisP1948> Using this command sudo apt-get build-dep linux-image-3.13.0-35-generic which is found at https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel it downloaded 3.13.0-45 the newest instead of *-35. How do I get *-35? I need to bisect *-35 as it's the last good kernel before I stated having issues reported at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1402331
[05:39] <apw> ChrisP1948 (N,BFTL), you are asking for the build-deps for linux, not for the source for that version... so you get the latest bits
[05:40] <apw> as you are never there to hear the answer, and indeed are not reading backscroll, i am sure you will not see this either
[15:25] <shadeslayer> So, I'm using overlayfs and I'm seeing weird errors like failed to whiteout 'CMakeLists.txt
[15:25] <shadeslayer> any ideas how I can investigate what's going wrong
[16:45] <apw> shadeslayer, on what version of the kernel
[16:46] <apw> shadeslayer, what exact string
[16:48] <shadeslayer> apw: moment
[16:49] <shadeslayer> apw: Linux rassilon 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15 17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[16:49] <shadeslayer> [ 1288.304277] overlayfs: ERROR - failed to whiteout 'CMakeLists.txt'
[16:50] <shadeslayer> that's one of many strings it's failing on
[16:50] <apw> shadeslayer, how full is the upper layer
[16:50] <apw> shadeslayer, and is this on the livecd use case, or on a post install overlay
[16:50] <shadeslayer> apw: it's on a AWS EC2 instance
[16:51] <shadeslayer> I'm mounting a jenkins workspace dir inside a schroot using this script : http://paste.ubuntu.com/10056383/
[16:52] <shadeslayer> and : /dev/xvda1      493G  131G  341G  28% / < seems like there's plenty of space 
[16:52] <Free99> Hello all, I have ubuntu 14.04 running on an HP Revolve 810 G2. Having an issue where the stylus moves only diagonally no matter where the stylus actually is on-screen.
[16:53] <apw> shadeslayer, and what are you doing to the upper layer which is failing ...
[16:53] <Free99> I was able to fix the issue by compiling a kernel but editing a line in hid-input.c to force it to be relative vs absolute
[16:53] <Free99> downside is, it messes up X autodetection pretty badly
[16:53] <apw> shadeslayer, and ... could you file a bug "ubuntu-bug linux" and shove all this detail in it, so it doesn't get flushed
[16:53] <Free99> any idea on how to do this fix on a regular ubuntu kernel?
[16:54] <shadeslayer> apw: ok
[16:54] <apw> shadeslayer, shove the bug # in here for me, so i can think about it
[16:55] <shadeslayer> apw: I /think/ it's the underlying cause for http://dci.pangea.pub/job/plasma/job/kservice_source_unstable/13/consoleText
[16:55] <apw> Free99, if you have a way to make it work like that, again a "ubuntu-bug linux" to get the h/w details, and put as much detail in it ... then we can look and see if we cna make it work for you and not break everyeone else
[16:55] <Free99> ok, sure thing apw
[17:03] <Free99> apw by the way I upgraded my kernel to utopic, but this still applied on 3.13-x as well
[17:03] <Free99> think that'll be an issue?
[17:06] <apw> Free99, if it affects the one you are reporting against, no that is fine
[17:12] <shadeslayer> apw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418123
[17:14] <shadeslayer> apw: do you need anything else?
[17:16] <apw> shadeslayer, will update the bug if not
[17:17] <shadeslayer> apw: cheers
[17:17] <shadeslayer> I'll just redesign my schroot setup
[17:23] <Free99> apw, https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418130
[17:24] <Free99> apw thanks for the advice
[17:24] <Free99> question though: if I build something with DKMS, will it follow through kernel upgrades?
[17:24] <Free99> I ask because of https://bugs.launchpad.net/ubuntu/+source/linux-lts-utopic/+bug/1418134
[17:25] <apw> Free99, should do
[17:26] <Free99> apw you mean it ought to follow kernel upgrades, or that first bug report was detailed sufficiently?
[17:27] <apw> Free99, i mean dkms would get rebuilt for each kernel upgrade
[17:27] <apw> Free99, not looked at the bug yet
[17:28] <Free99> apw great, just trying to clarify what you meant :)
[17:28] <Free99> thanks again
[21:11] <kfir> Hello, i'm developing a small kernel module and i'm getting the following error: module verification failed: signature and/or  required key missing How can I bypass this for my module?
[22:26] <blahdeblah> Hi all, is there a PPA or similar repo for tracking mainline builds? I'm currently on 3.19.0-031900rc3-generic trying to see if it solves https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1384342, and I'd prefer to keep tracking those builds for now.
[22:27] <blahdeblah> I had a read through https://wiki.ubuntu.com/Kernel/MainlineBuilds and it seems to say that it's necessary to track http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D and manually install - is there an alternative?
[22:38] <kees> so... anyone around familiar with UEFI -> kernel path? Does UEFI call startup_64 or startup_32 when loading the kernel?
[22:40] <kees> I guess I mean shim and grub...
[22:41] <apw> kees, it calls a specific efi entry doesn't it ?
[22:41] <kees> apw: unclear to me. doesn't Ubuntu's UEFI thingy call shim, which calls grub, which calls the kernel?
[22:42] <apw> kees, yeah, but it either calls "as normal" when not secure i think, and calls a special entry with boot services "available"
[22:42] <kees> efi_pe_entry in the kernel seems to call startup_32.
[22:43] <kees> oh hm, there's also efi64_stub_entry
[22:44] <apw> kees, yeah there is two of 'em
[22:45] <kees> I'm investigating a report of a corner case of a corner case... XD isn't enabled on some person's machine, and I'm looking at paths where that could happen.
[22:46] <kees> it looks like any 64-bit kernel entry points skip fixing XD, since paging has already been started.
[22:47] <kees> I wonder if 64-bit could drop to 32-bit temporarily, fix XD, rewrite the page tables, and switch back....
[22:48] <apw> ugg, nasty
[22:51] <cristian_c> apw, I've collected the info in kernel.org format
[22:51] <cristian_c> apw, as requested
[22:51] <cristian_c> apw, I'd like to know if they are correct
[22:52] <cristian_c> I ca paste them on pastebin
[23:02] <cristian_c> *can
[23:18] <mjg59> kees: The answer is "it depends"
[23:19] <mjg59> kees: "linux" will call startup_32
[23:19] <mjg59> "linuxefi" will call either the 32 or 64 bit offset in the stub, depending on the architecture of the firmware
[23:24] <kees> mjg59: yeah, it sounds like I need to move this code into the common boot path
[23:24] <kees> mjg59: and I don't think it'll require a 64->32->64 to do it. a TLB flush should DTRT...
[23:30] <mjg59> kees: So the current situation is that jumping into the 64 bit EFI stub skips XD?
[23:30] <mjg59> Or just startup_64?
[23:32] <kees> mjg59: all the non-32-bit paths skip the bit of code I wrote to fix broken BIOSes that mask out XD support.
[23:32] <kees> ("XD_DISABLE")
[23:32] <kees> mjg59: so if you have a 64-bit boot on an especially crazy BIOS, you don't get NX support. :(
[23:33] <mjg59> kees: Oh, ok, so in the common case it's fine. That makes sense.
[23:33] <kees> yeah, in the common case, the boot loader did all the right things when setting up paging.
[23:33] <kees> but some seriously brain-dead boot firmware out there is setting XD_DISABLE _and_ booting 64-bit. O_o
[23:34] <mjg59> grub doesn't set up paging in the linuxefi case
[23:34] <kees> in the 32-bit efi boot case? right.
[23:34] <mjg59> 32 or 64
[23:34] <mjg59> That gets left up to the kernel
[23:35] <kees> AIUI, 64-bit boot requires an identity mapped paging setup before starting the kernel.
[23:35] <mjg59> Either that's getting set up by the EFI boot code in the kernel, or that's what the firmware is setting up
[23:35] <mjg59> grub never touches page tables in the linuxefi case
[23:36] <kees> right, if the boot firmware loads grub in 64-bit mode it must have set up identity mappings too
[23:37] <kees> (i.e. grub doesn't need to)
[23:37] <mjg59> Yeah