[00:00] <tsimonq2> .ir
[00:00] <tsimonq2> whoops
[05:32] <thresh> jsalisbury, thank you.  I wont be able to test them until this Sunday, sadly.
[06:12] <tomreyn> good morning. do yuo think this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 and the linked kernel.org bug are actually the same? i would think they are actually unrelated issues.
[06:13] <tomreyn> also, do you think the ubuntu bug could be ubuntu specific, or could be worked around in ubuntu? the workaround discussed in this bug report seems reliable to me.
[06:16] <tomreyn> in my experience diabling ALSR is not necessary, and i would think CONFIG_RCU_NOCB_CPU is an acceptable compromise (for this cpou type)
[06:25] <tomreyn> got disconnected, so i'll type it again:
[06:26] <tomreyn> good morning. do yuo think this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085 and the linked kernel.org bug are actually the same? i would think they are actually unrelated issues because one of these occurs only in high load (bugzilla.linux.org), the other only in low load (bugs.launchpad.net) situations.
[06:26] <tomreyn> also, do you think the ubuntu bug could be ubuntu specific, or could be worked around in ubuntu? the workaround discussed in this bug report seems reliable to me.
[06:26] <tomreyn> in my experience diabling ALSR is not necessary, and i would think CONFIG_RCU_NOCB_CPU is an acceptable compromise (for this cpou type)
[08:44] <alkisg> On 16.04 a school reports that it cannot boot with vmlinuz-4.13.0-26-generic, is there an even newer kernel that they could try?
[08:53] <apw> alkisg, there is a -28, but i would be supprised if that sorts any boot issues, not impossible, but supprising
[08:54] <alkisg> apw, thank you... I'll also try with some from the mainline then
[08:55] <apw> alkisg, do you get anything other than reports of "doesn't boot", and sort of diagnostics someone might be able to look at ?
[08:57] <alkisg> apw: unfortunately the school IT teachers don't have a lot of linux exprertise, so I would have to travel there (e.g. half an hour drive) and do it myself... I'm doing that of course when the need is great, but usually not when an easy workaround exists
[08:58] <apw> alkisg, we have never (as a linux community) entirely sensible about making the diagnostics easy for an end-user to report
[08:58] <apw> alkisg, we did (in the pub over beer) talk about encoding panic stacks as QR codes and showing those
[08:58] <alkisg> I have set up a very easy way for user-initiated vnc access, but of course that part only works when it boots
[08:59] <alkisg> I've also worked once with a kvm/ip switch that gave me remote access even before the computer boots, but it's too costly for wide deployment
[08:59] <alkisg> QR codes sound amazing
[09:01] <alkisg> Another trick I'm using is: "boot from a live cd. apt install x11vnc kvm; x11vnc -connect srv1-dide.ioa.sch.gr; kvm -m 1024 /dev/sda"
[09:01] <alkisg> So if they can boot from a live cd and the problem is reproducible under kvm, I can see it remotely
[09:02] <apw> like that one
[09:32] <f_g> alkisg: what was the last kernel which did boot? 4.13 has a bug with some SCSI controllers that panic on b oot
[09:32] <alkisg> f_g: the 4.10.something kernel that 16.04 had
[09:32] <alkisg> (before the 4.13 bump)
[09:33] <f_g> as do 4.12, 4.14 and I think 4.15. I saw some patches flying around on LKML that might solve it, Debian's 4.9 and our downstream 4.13 just reverted the buggy commit for now
[09:33] <alkisg> I can get the exact number if needed
[09:33] <alkisg>  4.10.0-42 afaik
[09:35] <f_g> alkisg: see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1726519
[09:36] <f_g> most systems failing to boot 4.13 that I have seen were that one
[09:36] <f_g> and a simple revert fixes it
[09:39] <f_g> just added the likely upstream fix as well as a comment, but AFAICT it has not been merged upstream yet.
[09:39] <f_g> https://patchwork.kernel.org/patch/10154587/ in case you want to test it yourself ;)
[09:40] <f_g> alkisg jsalisbury ^^
[09:55] <alkisg> f_g: thanks, that would explain why I can't reproduce it in a VM
[10:29] <f_g> alkisg: it's entirely possible it's some other HW-related issue though. but if you need to go there to investigate, I'd recommend having a build with the cherry-pick and one with the revert handy to test :P
[11:18] <f_g> the Spectre/IBRS/IBPB commits in the pti branch have been picked from upstream's pti tip? or straight from LKML? or ... ?
[11:58] <apw> they are patches we receieved from Intel, they are not likely the final solution
[12:20] <f_g> apw: thanks for the info. it seems like the first round is getting finalized for upstream inclusion and might make it into -rc8, if it does will you rebase the non-s390 stuff to match what lands upstream?
[12:21] <apw> f_g, will have to see what lands, if it is reptoline without ibrs (which i assume it is) it will depend how hard it is to merge them, as upstram will put ibrs on the top next
[12:22] <apw> f_g, in large part it is effort and risk against timescales 
[12:23] <f_g> tip/pti is currently retpoline only
[12:24] <apw> right, and there is some concern that reptoline in its current form is not sufficient, so we ahve to err on the side of safe and slow
[12:24] <apw> we are following along, and assuming we will go that way as soon as humanly sensible
[12:25] <f_g> right. thanks!
[12:26] <apw> though google appears to be of the opinion the westmere escapes are highly unlikely, and likely can be fixed by improving reptoline ...
[12:48] <jsalisbury> f_g, alkisg I built a test kernel with the patch posted here:
[12:48] <jsalisbury> https://marc.info/?l=linux-scsi&m=151557324907914
[12:48] <jsalisbury> The test kernel can be downloaded from:
[12:48] <jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1742630
[12:48] <jsalisbury> Can you test this kernel and see if it resolves this bug?
[14:07] <gpiccoli> Hi, I was reading: https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel
[14:08] <gpiccoli> It shows a table with multiple flavours of kernel, like -lowlatency, -rt and -generic. Thne it mentions "the first 3 above are provided through official Ubutu archives", meaning -generic, -preempt and -rt
[14:09] <gpiccoli> I could only find -generic and -lowlatency though; is the information obsolete?
[14:09] <gpiccoli> It could be edited in order to be more accurate, if it's the case.
[14:09] <gpiccoli> tnx in advance for any clarification!
[14:10] <alkisg> jsalisbury: I don't have any amd64 school installation to test with, they're all i386... :/
[14:15] <jsalisbury> alkisg, I'll build a 32 bit kernel for you and let you know when it's ready.
[14:15] <alkisg> jsalisbury: thank you
[14:16] <alkisg> I'll go to the school and test on Monday then, when it opens
[15:19] <jsalisbury> alkisg, There is an i386 version of the test kernel available now.  It can be downloaded from:
[15:19] <jsalisbury> http://kernel.ubuntu.com/~jsalisbury/lp1742630/i386
[15:19] <alkisg> jsalisbury: thank you, I can test this on Monday
[15:20] <jsalisbury> alkisg, great, thanks!
[16:55] <VulcanRidr> Quick question. I have noticed in the recent past that kernel upgrades do not seem to be writing a /run/reboot-required. Is this an intentional thing? Is there a new method of knowing the system needs a reboot? I'm working mostly on 14.04 boxes.
[17:01] <TJ-> VulcanRidr: is unattended-upgrades package installed?
[17:01] <VulcanRidr> TJ-: It is.
[17:04] <VulcanRidr> root@unkarplutt:~# ls -l /run/reboot-required
[17:04] <VulcanRidr> ls: cannot access /run/reboot-required: No such file or directory
[17:04] <VulcanRidr> root@unkarplutt:~# dpkg -l unattended-upgrades
[17:04] <VulcanRidr> Desired=Unknown/Install/Remove/Purge/Hold
[17:04] <VulcanRidr> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
[17:04] <VulcanRidr> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
[17:04] <VulcanRidr> ||/ Name           Version      Architecture Description
[17:04] <VulcanRidr> +++-[17:04] <VulcanRidr> ii  unattended-upg 0.82.1ubuntu all          automatic installation of security
[17:06] <TJ-> VulcanRidr: hmmm, because for u-u that marker file is touched by the script /etc/kernel/postinst.d/unattended-upgrades
[17:08] <VulcanRidr> Hrmmm...So where did that file go?
[17:08] <TJ-> VulcanRidr: is it missing ?
[17:09] <TJ-> do "dpkg -L unattended-upgrades" check if it is in the 14.04 package; I checked on 16.04
[17:15] <VulcanRidr> TJ-: It sure isn't in there.
[17:15] <VulcanRidr> That explains a lot...
[17:17] <VulcanRidr> It is on the 16.04 box I checked, but it is certainly not on the 14.04 box.