=== Madkiss_ is now known as Madkiss
=== tinoco is now known as Guest95688
=== _Traxer is now known as Traxer
=== FourDollars_ is now known as FourDollars
=== _fortis_ is now known as _fortis
=== DalekSec_ is now known as DalekSec
=== davmor2_ is now known as davmor2
=== ogra_` is now known as ogra_
=== smoser` is now known as smoser
=== lifeless_ is now known as lifeless
=== lool- is now known as lool
=== kloeri_ is now known as kloeri
[14:34] <caribou> apw: remember the vm.min_free_kbytes issue with kdump ?
[14:35] <caribou> Bug: #1528101
[14:35] <ubot5`> bug 1528101 in kexec-tools (Ubuntu) "ISST-LTE: kdump failed: second kernel booting hangs after /scripts/init-bottom when large min_free_kbytes value being set" [Undecided,Confirmed] https://launchpad.net/bugs/1528101
[14:36] <apw> caribou, let me say vaguely
[14:42] <caribou> apw: well, whe vm.min_free_kbytes is higher than crashkernel value, OOM kicks in & doesn't let kdump run
[14:43] <caribou> apw: anyhow, it is much more complex to fix than what I thought : nowadays systemd-sysctl systemd unit takes care of loading the sysctl values and not procs
[14:49] <apw> caribou, of course it does
[14:49] <caribou> apw: well, since the bug was reported on Trusty I didn't bother to check Xenial
[14:50] <apw> (i wasn't expecting you to have noticed, just expressing my frustration that systemd had changed the way something worked)
[14:50] <caribou> apw: but just hacking propc to detect /proc/vmcore won't work & I don't feel like changing systemd.service-sysctl
[14:50] <caribou> apw: :)
[14:50] <apw> so you are saying that systemd is reading procps's config files directly and applying them
[14:51] <apw> when we have a perfectly good program to do that alrady
[14:51] <caribou> apw: yes; it applies everything in /etc/sysctl.d & add a symlink in there toward /etc/sysctl.conf
[14:52] <apw> caribou, dammit
[14:53] <apw> caribou, when we boot in kdump world do we boot a different "target" in systemd land
[14:54] <caribou> apw: I force it to go to systemd.unit=kdump-tools.service but in that corner case, it never makes it to that target
[14:55] <caribou> apw: I'm not tempted to bend over backward to fix a corner case where the user has set a kernel value that is not coherent with the use of crashkernel=
[14:55] <caribou> apw: they should just raise crashkernel in that case (which is the workaround I proposed in the bug)
[14:56] <caribou> I can always fix Trusty for that, but it will be a Trusty-only solution
[14:57] <diwic> is it expected to get a "warning: file-aligned section .text extends beyond end of file" when installing linux-signed-image 4.4.0-2.16 ?
[15:00] <diwic> probably not. filed https://bugs.launchpad.net/bugs/1540406
[15:00] <ubot5`> Launchpad bug 1540406 in linux-signed (Ubuntu) "warning: file-aligned section .text extends beyond end of file" [Undecided,New]
[15:01] <apw> diwic, do you have secure-boot enabled, and if so does it at least boot ok ?
[15:02] <diwic> apw, I think secure-boot is disabled
[15:05] <apw> caribou, i think that there are more than one way the cat gets skinned in userspace that we may be forced to do ti in the kernel
[15:05] <apw> *that as there are*
[15:07] <caribou> apw: do we _really_ want to go that far for such a limited set of possibilities ? (though I agree that allowing vm.min_free_kbytes to be larger than the whole memory makes no sense)
[15:07] <apw> right, i am inclined to think we could at least reject that combination and get 95% of the way there
[15:09] <diwic> apw, I enabled secure boot and booted the kernel, seems to work
[15:10] <apw> diwic, ok, so at least that is something, could you shove that info in the bug pls.
[15:10] <caribou> apw: your call; I will propose to add a simple upstart job that sets the value to what they want for Trusty for that bug
[15:10] <diwic> apw, will do
=== dannf` is now known as dannf
=== infinity_ is now known as infinity
=== bdmurray_ is now known as bdmurray