=== JanC_ is now known as JanC
[08:45] <apw> slangasek, ok and this morning i have slammed it in, and have no VT3 content
[08:45] <apw> slangasek, so definatly not consistent
[14:10] <LocutusOfBorg> so, folks any news about the new VBOX kernel implementation?
[14:10] <LocutusOfBorg> sforshee, ^^
[14:10] <LocutusOfBorg> I'm going to upload virtualbox 5.2 soon(TM)
[14:10] <LocutusOfBorg> that should have something similar to the kernel driver
[14:19] <apw> LocutusOfBorg, nothing from me on that, though i will say i think i have managed to make your "lower the kernel module version" suggestion work to unbreak the DKMS tests and allow them to be separated
[14:21] <sforshee> LocutusOfBorg: I've applied the fix and turned the option back on in our 4.14 kernel, I haven't heard any compelling reason that we need to turn it back on in 4.13
[14:22] <sforshee> still haven't done any work on sorting out having multiple vboxvideo module though
[14:22] <LocutusOfBorg> I don't want it for 4.13 :) 4.14 is fine
[14:22] <LocutusOfBorg> I'm talking about 18.04
[14:23] <sforshee> yeah we'll have it enabled there, as long as it is working ;-)
[14:24] <sforshee> LocutusOfBorg: will 4.2 support 4.14?
[14:24] <sforshee> *5.2
[14:29] <LocutusOfBorg> sforshee, https://www.virtualbox.org/pipermail/vbox-dev/2017-October/014836.html
[14:29] <LocutusOfBorg> probably some fix is successive 
[14:30] <sforshee> cool, thx
[14:33] <LocutusOfBorg>     Update: The Guest Additions image with the 5.2.0 release fails to work with recent Linux guest kernels. Please try this image which we believe fixes the problem. For experimental Linux 4.14 support, please try this image. Both should work on all older guest systems too: please file a report on the bugtracker if they do not.
[14:34] <LocutusOfBorg> seems not
[14:51] <LocutusOfBorg> sforshee, https://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/commit/?id=731d628393426d91ac8e901b0ef76dc6571f2930
[14:52] <sforshee> LocutusOfBorg: awesome, thanks!
[14:53] <LocutusOfBorg> e6742e1021a5cec55fab50a0b115c65217488eda <-- do you have it?
[14:53] <LocutusOfBorg> also 25ff38ca79a9336ea34cc0d0b0b0b39ad7836d28
[14:54] <LocutusOfBorg> they seems to come from the kernel, so I suppose your kernel module if you have an up-to-date master branch, will be working better than the vbox one :)
[14:54] <sforshee> LocutusOfBorg: both were in 4.14-rc1, our unstable tree is currently at -rc5 so yes we have them
[14:56] <LocutusOfBorg> wonderful
[15:57] <slangasek> apw: how do you think we should approach pinning this down?  Should I start with a kernel bisect, or is there useful dmesg output I should pull in?
[16:03] <apw> slangasek, gawd i am not sure, a grose bisect with 4.11 4.12 maybe helpful to start with, sigh
[16:05] <slangasek> alright
[16:05] <slangasek> I figured I'd start with "find me the first 4.13 kernel from the artful devel series and see what happens"
[16:06] <apw> slangasek, yeah, not really sure what the trigger here is, i can see i stil do not have vts having undocked
[16:06] <apw> slangasek, not sure if it was the s/r which broke it
[16:07] <slangasek> right, undocking never got me my vts back
[16:07] <slangasek> bdmurray: ^^ since you have the same bug
[16:08] <apw> slangasek, now is it docking which breaks it, or s/r which breaks it, or
[16:08] <apw> as i had it docked with vts, i suspct it is not the dock
[16:09] <slangasek> s/r ?
[16:09] <apw> suspend/resume, that is the other thing that occured for sure since i docked and undocked with vts
[16:09] <slangasek> for me, the problem happens when the kernel driver has two displays when it first inits
[16:10] <slangasek> so a s/r cycle might be the same
[16:10] <apw> i didn't s/r with two displays though
[16:10] <slangasek> ok
[16:10] <slangasek> conclusion: shit is broken
[16:10] <apw> i had vts, docked, had vts, undocked, had vts, resumed, docked, checked and did not have vts
[16:11] <apw> so, i don't know if i had them between resume and docked, sadly
[16:11] <bdmurray> it happens for me on first boot too
[16:37] <slangasek> jsalisbury: wrt LP: #1724911, you ask for a mainline 4.14 kernel test, but I would not be quick to rule out this being a sauce-related bug; can I get a mainline kernel build somewhere that corresponds to 4.13.0-16-generic for testing?
[16:37] <ubot5> Launchpad bug 1724911 in linux (Ubuntu) "text VTs are unavailable on desktop after upgrade to Ubuntu 17.10" [High,Confirmed] https://launchpad.net/bugs/1724911
[16:41] <apw> slangasek, that is based on 4.13.4 ... (see /proc/version_signature)
[16:41] <slangasek> ok
[16:42] <apw> slangasek, so in theory the mainline equivalent is http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.13.4/
[16:42] <apw> which did at least build
[16:43] <jsalisbury> slangasek, thanks for trying mainline, it would be just a good data point.
[18:02] <TJ-> Heads-up for the nvidia driver packages failing to build. In v4.14 AMD has introduced Secure Memory Encryption (SME) and, in the mainline builds at least, it is enabled by default. CONFIG_ARCH_HAS_MEM_ENCRYPT and CONFIG_AMD_MEM_ENCRYPT. The GPL-only symbol sme_me_mask causes the nvidia drivers to fail to build. I reported this upstream. Thomas Gleixner replied to the thread saying this symbol will not
[18:02] <TJ-> have it's GPL tag removed. The only option is to set CONFIG_AMD_MEM_ENCRYPT=n but obviously that means the AMD devices (where this SME is introduced) cannot use it. or Ubuntu kernel builds that have to be hardware-agnostic this isn't a solution. So, we could be heading for a problem for the DKMS builds of nvidia (and other) out-of-tree drivers.
[18:56] <apw> TJ-, happens every now and again, and something gets fixed
[19:15] <slangasek> jsalisbury, apw, bdmurray: ok good news, LP: #1724911 is fixed upstream in 4.14rc5.  Which kernel should I test next?
[19:15] <ubot5> Launchpad bug 1724911 in linux (Ubuntu) "text VTs are unavailable on desktop after upgrade to Ubuntu 17.10" [High,Confirmed] https://launchpad.net/bugs/1724911
[19:18] <apw> slangasek: awesome
[19:18] <apw> slangasek: I assume rc4 was bad, so a jsalisbury bisect between sounds good
[19:20] <slangasek> also, I get apparmor denials on dhclient with 4.14rc5.
[19:20] <slangasek> apw: I didn't test with rc4, is that the next one I should do?
[19:20] <slangasek> should I report those apparmor denials somewhere?
[19:21] <slangasek> (should something have rebuilt apparmor caches for the new kernel version?)
[19:22] <slangasek> quite a lot of denials actually
[19:22] <slangasek> but only dhclient matters to me ;)
[19:22] <apw> slangasek: well there is likely different apparmor in mainline
[19:23] <slangasek> apw: 4.13 mainline didn't give me these denials, I was able to get online
[19:23] <slangasek> 4.14, I had to debug
[19:23] <mamarley> slangasek: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1721278
[19:23] <ubot5> Ubuntu bug 1721278 in apparmor (Ubuntu Artful) "apparmor="DENIED" operation="create" profile="/usr/sbin/cups-browsed" w/ 4.14-rc2 and later" [Undecided,Confirmed]
[19:24] <slangasek> yep, that looks like the one
[19:25] <apw> slangasek: something between 4.13 and 4.14rc5
[19:26] <apw> to narrow the window
[19:26] <slangasek> wk
[19:26] <slangasek> k
[19:26] <apw> though rc4 is more likely to work than rc3 etc
[19:26] <apw> work in general
[19:27] <slangasek> yeah but bisect log 2 etc etc
[19:27] <slangasek> I'll go straight to rc1 :)
[20:03] <slangasek> jsalisbury: can you help me out with bisect builds for LP: #1724911?  I think I've done all the testing that can be done against http://kernel.ubuntu.com/~kernel-ppa/mainline/
[20:03] <ubot5> Launchpad bug 1724911 in linux (Ubuntu) "text VTs are unavailable on desktop after upgrade to Ubuntu 17.10" [High,Confirmed] https://launchpad.net/bugs/1724911
[21:48] <jsalisbury> slangasek, sure thing.  I'll review what kernels you've tested so far, and post the next one to test in the bug.
[21:54] <jsalisbury> slangasek, I updated the bug.  
[21:54] <jsalisbury> We can't bisect between 4.13.8 and 4.14-rc1 because they are not linear versions. The bug could have been introduced by a 4.13 stable update.
[21:55] <jsalisbury> slangasek, It would be great if you can confirm 4.13 final also has the bug.  I'll asume it does and start a bisect between 3.13 final and 4.14-rc1.
[21:55] <jsalisbury> I'll post a link to that test kernel in the bug when it's done building.
[22:09] <slangasek> jsalisbury: ok, thanks