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