[07:39] <tjaalton> which initramfs hook installs the firmware?
[07:40] <tjaalton> i915/* is missing
[07:59] <smb> tjaalton, i915 needs firmware therese days?
[07:59] <tjaalton> skylake does
[07:59] <tjaalton> and broxton next year
[08:00] <tjaalton> well, it works without but complains
[08:00] <tjaalton> bug 1496163
[08:00] <smb> now that I call a step backwards... errm. 
[08:01] <smb> Not sure here but probably depends were the binary comes from... would that not be the linux-firmware package
[08:01] <tjaalton> it doesn't install any hooks at least
[08:04] <TJ-> The hook is via /usr/share/initramfs-tools/hook-functions::manual_add_modules() 
[08:04] <tjaalton> I guess it's udev
[08:05] <smb> tjaalton, ok, so the file of that name (or better link to skl_dmc_ver1_19.bin) is in the linux-firmware package
[08:05] <tjaalton> yes, checking with -v
[08:05] <tjaalton> smb: yep
[08:05] <smb> the loading would be triggered by the driver
[08:06] <tjaalton> Adding firmware /lib/firmware/i915/skl_dmc_ver1.bin
[08:06] <tjaalton> huh
[08:07] <tjaalton> lib/firmware/i915/ is still empty
[08:07] <tjaalton> maybe because skl_dmc_ver1.bin is a symlink
[08:07] <smb> tjaalton, have you unpacked the produced initrd to sanity check whether or what might be missing?
[08:07] <tjaalton> yes
[08:08] <smb> ok so you say that is completely empty
[08:08] <tjaalton> yes the dir is empty
[08:08] <TJ-> I wonder if it's a hanging symlink? That 'file' is a sylink in /lib/firmware/i915/
[08:08] <tjaalton> no, it points to a real file
[08:08] <smb> TJ-, maybe though at least for the source of the package its there
[08:09] <smb> tjaalton, can you look whether the W system has the right link
[08:09] <smb> to the ver1_19?
[08:09] <TJ-> Yes, that's what I mean. The source is there, but in the initrd image is it a dangling symlink
[08:09] <tjaalton> should use cp -aL
[08:09] <smb> TJ-, as I understand tjaalton there is nothing there
[08:10] <smb> not even the link
[08:10] <tjaalton> lib/firmware/i915 is empty in initrd
[08:11] <smb> tjaalton, let me finish that coffee and bring up a system actually running W...
[08:11] <TJ-> I see:
[08:11] <TJ-> Adding module /lib/modules/4.2.0-10-lowlatency/kernel/drivers/gpu/drm/i915/i915.ko
[08:11] <TJ-> Adding firmware /lib/firmware/i915/skl_dmc_ver1.bin
[08:12] <tjaalton> yep, modifying the copy command to use 'cp -aL' fixed it
[08:12] <tjaalton> so adding the L
[08:13] <TJ-> Yes, confirmed here too. Empty initrd
[08:13] <smb> tjaalton, is that -aL getting you a softlink in initrd or a file
[08:14] <tjaalton> smb: a file
[08:14] <smb> tjaalton, hm, which might not be exactly what we want but of course better than nothing
[08:15] <tjaalton> well, in this case it's the best there is
[08:15] <tjaalton> no need to add several versions of the fw in initrd
[08:15] <smb> normally I'd expect -a to preserve things and get everything... a bit odd
[08:15] <tjaalton> doesn't follow links
[08:15] <tjaalton> but odd that it doesn't even copy the link
[08:15] <caribou> apw: remember Bug 1496317 from yesterday ?
[08:16] <tjaalton> maybe it's cleaned afterwards
[08:16] <smb> tjaalton, Oh I understand only used on a specific path
[08:16] <smb> caribou, he may as soon as he becomes concious
[08:17] <caribou> smb: :)
[08:18] <apw> tjaalton, does cpio represent those i wonder
[08:18] <apw> caribou, yep
[08:18] <smb> apw, I thought it should 
[08:19] <smb> apw, but I try to look there in a min
[08:19] <caribou> apw: so using MODULES=dep in initramfs.conf brings down the size of the initrd to 12M and it fixes the problem
[08:20] <apw> caribou, that does sound like a good option for such a resource constrained space ... but we'd need to actually have one
[08:21] <caribou> "have one" ?
[08:21] <caribou> I'm a bit concerned to change the initrd for such a corner case.
[08:22] <caribou> apw: the other option is to raise the value of crashkernel again. 
[08:22] <caribou> apw: but at the moment, we're shipping wily with a broken crash dump mechanism
[08:23] <apw> tjaalton, there is a changelog entry saying broken symlinks will be removed
[08:23] <apw>   * mkinitramfs: Filter out looping or broken symlinks from the
[08:23] <apw>     initramfs. (closes: #575157)
[08:24] <apw> tjaalton, so i would say either -L is appropriate, or we need to detect and add the file it points to as well
[08:24] <smb> Oh, yeah sounds plausible
[08:24] <tjaalton> yeah
[08:24] <apw> tjaalton, do you want to file a bug against initramfs-tools for this
[08:24] <tjaalton> apw: I reused the bug above
[08:25] <tjaalton> https://launchpad.net/bugs/1496163
[08:25] <apw> bug 149616
[08:25] <apw> bug 1496163  
[08:25]  * apw slaps ubot5
[08:25] <apw> tjaalton, thanks
[08:26] <apw> tjaalton, i assume i have this firmware on my wily boxes already, right?
[08:26] <tjaalton> yep
[08:26] <tjaalton> and vivid/trusty
[08:29] <UNIm95> Hi 2 all. I think kernel 3.13-64-generic has bug. I'm getting kernel panic with this kernel on 2 different PC's.
[08:29] <UNIm95> One Desktop with Athlon x2 4800+, other toshiba tecra laptop.
[08:29] <UNIm95> This all comes randomly.
[08:29] <UNIm95> The strangest thing is that desktop has 32 bit kernel and laptop 64 bit.
[08:29] <UNIm95> The only same thing is that begin to happen after 3.13-63 to 3.13-64 update.
[08:32] <apw> UNIm95, ok if it was introduced by an update like that and its detectible then it should be findable
[08:33] <apw> UNIm95, can you file a bug against the kernle "ubuntu-bug linux" for us, and put that info in it
[08:33] <apw> UNIm95, if you have a picture or something of the kernel panic can you put that in
[08:33] <apw> UNIm95, we might know what it is from that
[08:36] <UNIm95> apw:  with next panic i will make screen photo of panic. 
[08:36] <UNIm95> But every time i get different messages. The most strange message i saw was Kernel tried to execute NX-protocol page - exploit attempt?
[08:36] <UNIm95> It is strange cause i saw it on CPU Athlon x2 64 4800+ than was produced in 2006
[08:38] <apw> UNIm95, it may be somewhat random you never know
[08:39] <UNIm95> apw: Ok. I will wait for another panic.
[21:02] <manjo> bjf, wily will be released with 4.2 correct ? 
[21:03] <bjf> manjo, correct
[21:03] <manjo> thanks
[21:04] <manjo> bjf, and 16.04 will be based on 4.5 ? any idea ?
[21:05] <bjf> manjo, you can probably assume 4.4 ... don't know about 4.5. it's possible
[21:05] <manjo> ok yep thanks a ton for that info