[02:24] <kiwi_> Hi, am trying to build a custom kernel (4.4.20).. for kdump, ie, a crash kernel 
[02:25] <kiwi_> Trouble is, am facing all kinds of issues when the kexec'd kernel boots - mainly to do with config and kernel cmdline params to pass
[02:26] <kiwi_> Is there a specific kernel config file available for the Ubuntu crash kernel image?
[02:28] <kiwi_> specifically, for Ubuntu 16.04 (xenial)
[02:56] <n0c> hey all, can someone refer me to a guide on the current, supported way of customizing a kernel on ubuntu? (xenial, but looking to get 4.10 kernel) preferably from a kernel-source package versus a git checkout?
[03:24] <n0c> well it looks like actually there isn't a source package beyond 4.4 so... git it is
[09:31] <lag> ppisati: Hi
[09:31] <lag> ppisati: ogra_ asked me to ping you
[09:31] <lag> ppisati: Could you tell me all the kernel config options required for Snappy please?
[09:31] <lag> ppisati: Is there a Wiki?
[09:32] <ogra_> i think there was a script actually 
[09:33] <ogra_> lag, it could even be that these scripts are integrated into the snapcraft plugin ... https://github.com/snapcore/snapcraft/blob/master/demos/96boards-kernel/snapcraft.yaml has a demo snapcraft.yaml 
[09:34] <ogra_> (but i'm, not actually sure that checks for all config options, so better wait for ppisati's answer :) )
[09:34] <lag> ogra_: Thanks
[09:46] <ppisati> lag: or here - https://github.com/snapcore/sample-kernels
[09:46] <ppisati> lag: look under kernel/config/snaps
[09:47] <ppisati> *kernel/config/snappy
[09:52] <ogra_> ppisati, heh, you should really change CONFIG_SQUASHFS=m there 
[09:52] <ogra_> so people are not forced to put that into the initrd
[10:03] <ppisati> ogra_: yeah, i need to update the configs there
[10:03] <ppisati> ogra_: probably next week i'll push an update to the AA stuff, and i'll bundle the config chanfges
[10:03] <ogra_> +1
[10:08] <lag> ppisati: Thanks
[12:52] <caribou> Hello, I need to do a bissect on the 4.8 mainline kernel
[12:52] <caribou> what is the quickest way to only rebuild the vmlinuz bisected file w/o all the modules ?
[12:53] <caribou> mainline or our own kernel for that matter so either one  is fine
[12:54] <rtg> caribou, CONFIG_MODULES=n ?
[12:55] <rtg> there is no split in the build between built-in and modules. its just the one call to the kernel makefile
[12:55] <caribou> rtg: cool, thanks
[12:56] <rtg> or, you could do a native build after generating the config, then 'make vmlinuz'
[12:56] <rtg> caribou, I often do something like this:
[12:56] <rtg> fdr clean prepare-generic
[12:56] <rtg> cp debian/build/build-generic/.config .
[12:56] <rtg> make oldconfig scripts prepare
[12:57] <rtg> make vmlinuz
[12:58] <caribou> rtg: great; will try that
[12:58] <caribou> rtg: something has changed in the /proc/vmcore elf representation which breaks makedumpfile (or at least make it spit tons of errors)
[14:24] <sajoupa> Hi, linux-image-generic-lts-yakkety fails ot install on xenial, which I believe is due to its absence from linux-lts-yakkety - 4.8.0-25.27~16.04.1 in https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+packages
[14:24] <sajoupa> ^ apw / rtg I've been told that you were the right guys to ping about it
[14:26] <rtg> sajoupa, how does it fail to install ? missing dependencies ?
[14:26] <sajoupa> rtg: yes
[14:26] <rtg> sajoupa, apw pointed out that I might have uploaded the meta package to the wrong pocket.
[14:26] <rtg> lemme check
[14:26] <sajoupa> https://pastebin.canonical.com/168001/
[14:27] <rtg> indeed I did
[14:31] <rtg> sajoupa, I've uploaded a new version. Give it an hour or so to publish.
[14:31] <sajoupa> rtg: cool, thanks !
[15:07] <sajoupa> rtg: installing fine now
[15:08] <rtg> sajoupa, ack
[15:33] <michael-vb> Hello there.  Sorry if this is the wrong channel for "user questions", but I installed a 32-bit 4.8.0 daily kernel (tested with the 11 October and the 13 October one actually) and it hangs after grub.
[15:33] <michael-vb> Not a single line from the kernel printed, which makes me think that it is not properly loaded.  The 4.8.0 non-git one boots fine.  Does that bring anything to mind?  Including problems between keyboard and chair...
[15:34] <michael-vb> Just to be clear, 4.8.0 works, 4.8.0-999 does not.
[15:40] <apw> michael-vb, we tend to have a more issues with the debug kernels for sure they are built in an automated way
[15:42] <michael-vb> Right.  I was asking here because it looks like the kernel possibly isn't loaded at all, in which case there might be some easy way to solve it (for me).
[15:43] <apw> though the -999s are dalies if i remember the monenclature correctly, those have whatever random crack is in the aossicated tree that day
[15:43] <michael-vb> Of course, I am certainly not shocked, shocked to find one not working.
[15:44] <michael-vb> Or even two.
[15:44] <apw> depending on the day that could even be the middle of the merge window
[15:46] <michael-vb> But the description of a hang after grub but before the first kernel message is printed does not bring anything to mind?
[15:48] <michael-vb> Actually it does a mode set after selecting the kernel in grub and it hangs on an underscore cursor in the top-left corner.  Does grub trigger that, or would it be the kernel at least starting to boot?
[15:51] <apw> michael-vb, when there is a failed boot grub the next boot hands off with the framebuffer blank with just a cursor
[15:52] <apw> so that could easily be cratering in the first bits of the kernel
[15:53] <michael-vb> Thanks.
[16:30] <nacc> query on the overlay stuff in y -- given that overlayfs is no longer recognized, should there be something that goes into /etc/schroot/chroot.d/ and post-install of an appropriate kernel ensures that it says overlay for each schroot? I guess that could be a sbuild change. Wasn't sure if there was already a bug for this