| === himcesjf_ is now known as him-cesjf | ||
| alkisg | Good morning everyone. | 06:11 |
|---|---|---|
| alkisg | Why do Ubuntu installations under UEFI have both linux-generic and linux-signed-generic installed? Actually, isn't linux-signed-generic enough for any installation, either UEFI or BIOS? | 06:11 |
| alkisg | Erm, linux-signed-image-generic depends on linux-image-extra-XXX-generic, which in turn depends on linux-image-XXX-generic. So the packaging prevents us from only having the signed kernel installed. Would that be a bug to be reported? | 06:37 |
| alkisg | I.e. linux-image-extra-XXX-generic should Depend on EITHER the signed or non-signed kernels | 06:37 |
| === himcesjf_ is now known as him-cesjf | ||
| xnox | alkisg, eh linux-signed-generic is no more than a detached signature, that is attached to an image. | 07:54 |
| xnox | alkisg, i wonder if we need linux-image-extra-XXX-generic-signed?! =))))) | 07:55 |
| * xnox thought we do need the image, ah, but i guess the unsigned metapackage is redundant. | 07:55 | |
| xnox | interesting | 07:55 |
| alkisg | xnox: yes, I believe there's no point in having an unsigned version, but at the very least, allow uninstalling it by fixing the dependency there | 08:13 |
| alkisg | (I mean, an unsigned version could of course be available in the archives, but there's no point in ubuntu ever installing it automatically or even having it in live cds) | 08:19 |
| === Elimin8r is now known as Elimin8er | ||
| xnox | alkisg, somehow it feels to me that we only want signed kernels, everywhere, even if nothing knows how to validate that on a given arch. | 08:42 |
| alkisg | xnox: sure, that would be fine; I'm not sure if people building the kernel locally can generate them though, so having the unsigned package in the archives will be needed as well? | 08:43 |
| alkisg | Personally I have no need for the unsigned version... | 08:44 |
| xnox | alkisg, yes, and well we need one too. Cause we build unsigned one first; then kick of a separate build which creates the signed one.... cause otherwise chicken-egg-problem | 08:44 |
| mhzlp | Hi everyone :-) I would like to raise a question here, before starting a launchpad ticket | 09:16 |
| mhzlp | Having a problem with one of my ubuntu machines. It is giving segfaults when loading specific kernel-modules (vendor-drivers for an isdn-card). | 09:16 |
| mhzlp | Output of dmesg states "kernel BUG at /build/linux-fOTvIb/linux-3.13.0/arch/x86/kernel", enclosed in a "---[ cut here ]---" block. | 09:16 |
| mhzlp | Problems started with the Meltdown/Spectre mitigation kernel versions, worked fine for years before that. | 09:16 |
| mhzlp | Do you think it makes sense to submit this as a bug ticket? | 09:16 |
| klebers | mhzlp, Hi! Is this kernel module shipped by Canonical is it compiled out-of-tree? | 09:18 |
| mhzlp | klebers: it is a drivers package which is available for download at the hardware manufacturer. that is why i am asking | 09:21 |
| mhzlp | but they deliver the source code, so i built it with #139 and #141 kernel versions, but it failed. last working was #137 | 09:22 |
| mhzlp | well not the built itself failed, the loading of the module afterwards did | 09:24 |
| klebers | that could be either a bug on the kernel itself or a bug on the driver that's causing the BUG to be called | 09:25 |
| mhzlp | then it would make sense to open up a bug report in launchpad too, right? | 09:28 |
| klebers | mhzlp, yes, please include the full stack trace (the 'cut here' block) and a link to download the driver package | 09:29 |
| klebers | mhzlp, is it possible to reproduce the issue without having the hardware? | 09:29 |
| mhzlp | will do, also have a strace of the module load prepared. to be honest, i am NOT sure about that, didnt try yet. there is a setup involved for the isdn cards, which afaik has some options for the SNs. Not sure if that would affect the module behaviour | 09:32 |
| mhzlp | thanks for the brief evaluation and the hints so far | 09:36 |
| apw | xnox, always signed> yes, and we have work in progress to fix that, but it was stalled awaiting to find out if older powerpc boot laoders will barf if we switc | 09:49 |
| xnox | urgh | 09:50 |
| apw | also it is somewhat back-burnered because of the meltdown debackle too | 09:50 |
| apw | xnox, but yes, there seems to be no obvious reason we cannot ship a single signed binary, well as long as no platform moves to having more than one way to sign | 09:51 |
| apw | xnox, indeed it was my plan-of-record to work on that over the "quiet time" in december ... so much for _that_ | 09:51 |
| alkisg | apw: would it make sense to fix the image-extra dependency in the meantime, as it's a small fix? So that people that want to uninstall the non-signed kernel, are able to? | 09:56 |
| apw | alkisg, you cannot, if you remove that you have no kernel to attach the signature to | 09:57 |
| apw | alkisg, the signed package doens't contain the kernel, only the signature, and copies and attached it in postinst | 09:58 |
| alkisg | Thanks, looking (something still feels strange...) | 09:58 |
| apw | alkisg, trust me, i wrote that bit :) | 09:58 |
| apw | alkisg, the file /boot/vmlinuz-*.signed is not in apt control | 09:59 |
| apw | with highsight this was not a good plan, but it was about saving download time as you need to have bot | 09:59 |
| apw | both on a non-efi system, well ... we only wanted to use the signed one on efi systems | 09:59 |
| apw | to reduce risk when introducing it, now we have experience with it we know it is utterly | 10:00 |
| apw | fine in x86 at least, to boot a kernel with a signature on something which does not understand it | 10:00 |
| alkisg | apw: ok, all is fine, I was thinking that grub would list two kernels etc, but it doesn't, my misunderstanding | 10:01 |
| apw | nope because we did this, we also have to frig grub to hide the duplicate, all in all a poor design choice | 10:02 |
| apw | and one we are going to remedy, likely last decdember, oops | 10:02 |
| alkisg | :D | 10:02 |
| apw | it was actually my number1 priority for 2 days before meltdown was dropped in my lap | 10:03 |
| apw | such is the way of teh world | 10:03 |
| apw | the best laid plans of mice and men | 10:03 |
| alkisg | apw: regarding https://bugzilla.kernel.org/show_bug.cgi?id=198529, there's no response yet from the regression author, yet it affects a whole lot of i5 processors, would we care to fix it downstream? | 10:03 |
| ubot5 | bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New] | 10:03 |
| alkisg | I.e. 32bit Ubuntu no longer loads on a wide range of i5 processors | 10:04 |
| alkisg | I also mailed him, he didn't respond to that either | 10:05 |
| apw | alkisg, we might have found a fix for that, if it is the same issue that wgrant found a fix for | 10:15 |
| apw | smb, do we have any test kernels with that 32bit iommu thing appplied ? | 10:16 |
| smb | apw, I have none | 10:16 |
| alkisg | I'm available for testing, please ping me if someone has such a 32bit test kernel at any time | 10:19 |
| * apw makes one | 10:19 | |
| alkisg | ty! | 10:20 |
| apw | alkisg, what is your bug number ? | 10:21 |
| alkisg | apw: https://bugzilla.kernel.org/show_bug.cgi?id=198529 => I haven't filed one in launchpad | 10:21 |
| ubot5 | bugzilla.kernel.org bug 198529 in x86-64 "Reboot on kernel load due to 92a0f81d" [High,New] | 10:21 |
| apw | alkisg, do you have an ubuntu bug ? | 10:22 |
| alkisg | no | 10:22 |
| apw | smb, do we have a bug for that patch yet ? | 10:22 |
| alkisg | I can file one if you want | 10:22 |
| smb | apw, there were several (i386) not booting | 10:22 |
| smb | https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1744942, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1745118 | 10:24 |
| ubot5 | Ubuntu bug 1744942 in linux (Ubuntu Artful) "Lenovo IdeaPad U460 fails to boot with 4.13.0-31.34~16.04.1" [High,Confirmed] | 10:24 |
| ubot5 | Ubuntu bug 1745118 in linux (Ubuntu Artful) "Unable to boot with i386 4.13.0-25 / 4.13.0-26 / 4.13.0-31 kernel on Xenial / Artful" [High,Triaged] | 10:24 |
| smb | apw, there was a 3rd one but I am too lazy to search for that one as well | 10:25 |
| apw | smb, that 118 one looks the most general | 10:26 |
| smb | apw, yes, though the other one was reported first I believe | 10:26 |
| smb | but on hwe kernel | 10:27 |
| alkisg | I like the wgrant explanation on 118 | 10:27 |
| alkisg | There's a test kernel there | 10:27 |
| alkisg | Should I try it or wait for yours, apw? | 10:27 |
| apw | alkisg, if there is one there, have at it | 10:27 |
| alkisg | Comment #14, https://people.canonical.com/~wgrant/linux-image-4.13.0-31-generic_4.13.0-31.34~16.04.1_i386.deb | 10:28 |
| smb | That probably is already having the fix which he then submitted upstream... or at least close | 10:29 |
| smb | https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798 | 10:31 |
| alkisg | Yeah that blames the same commit that I blamed all right | 10:31 |
| apw | alkisg, yeah i meant to mention it late last night, and forgot ... that is sounded similar enough to be worth testing | 10:32 |
| alkisg | Currently installing, will reboot/test in a few | 10:33 |
| alkisg | Yup, that fixed it. Thanks apw and smb and wgrant :) | 10:38 |
| alkisg | I'll cross-reference the bug reports | 10:38 |
| apw | wgrant is the man on that one | 10:38 |
| apw | alkisg, so that is intended to be in the next xenial/linux-hwe upload | 10:38 |
| alkisg | Very nice. There are still a lot of instabilities with 4.13, but that one was a show-stopper | 10:41 |
| alkisg | apw, smb, is https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/patch/?id=55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798 accepted upstream, i.e. should I close my upstream bug report now? | 10:42 |
| apw | alkisg, it is very nearly ipstream, it is now in the pti branch which normally goes to linus pretty quick | 10:44 |
| apw | alkisg, i would make sure you reference it in your bug | 10:44 |
| alkisg | ty, doing so | 10:45 |
| === mamarley_ is now known as mamarley | ||
| === juergh_ is now known as juergh | ||
| nacc | jsalisbury: fyi, LP: #1746818 is more fallout from the 16.04 HWE change to 4.13, if you wouldn't mind triaging | 22:32 |
| ubot5 | Launchpad bug 1746818 in smb4k (Ubuntu) "smb4k on Kubuntu 16.04 working no longer with new hwe kernel 4.13" [Undecided,New] https://launchpad.net/bugs/1746818 | 22:32 |
| nacc | (or someone else more relevant, if i'm wrong :) | 22:32 |
| TJ- | That reminds me of another: Bug #1743094 | 22:39 |
| ubot5 | bug 1743094 in linux (Ubuntu) "[regression] hibernation (freezes on resume) since 4.13.0-25.29" [Medium,Confirmed] https://launchpad.net/bugs/1743094 | 22:39 |
| oursland | "fakeroot debian/rules binary" fails to build the kernel, giving an error that SPL/ZFS expect a fully built kernel. Any suggestions to get past this error? | 23:02 |
| === mwsb is now known as chu | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!