[01:34] Is there a wiki on making a new flavour correctly ? I just copied the .generic file over and renamed it [01:35] Enabling a kernel option creates the problem with the module failing to load [01:35] I'm obviously missing something here but I don't know what it is [13:37] Hello! Who is involved with the Touch kernels? I *think* it's missing ACL support and wanted to check in with someone about the config we use there [13:40] mterry, which kernels specificially ? [13:41] apw, I guess I happen to be testing on the arale device. So whatever kernel we ship there. But I haven't done a survey of all our supported devices to test kernel configs. Are the configs we use so device-specific? [13:43] mterry, yes, the kernels are mostly very different, and so there is a lot of manual work in that [13:43] apw, OK. Where could I go and look at the config we use to build one of these kernels with? [13:44] mterry, i'll find out and let you know [15:41] why doesn't 9pnet_virtio module autoload upon trying to mount 9p virtio filesystem....? [15:41] xnox, dunno maete [15:42] maybe it cannot be detected [15:46] it can be.... [15:48] that combination of things is a bit wierd to put it mildly, a virtio filesystem [15:50] * apw goes for supplies [15:53] apw, oh, it's racy on boot [15:54] somehow systemd tries to mount it before it's ready.... as post-boot i can restart .mount unit and it just works. [17:40] https://youtu.be/0yJn-5hpU94 [18:18] shouldn't regressions have a higher importance? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1603719 [18:18] Launchpad bug 1603719 in linux (Ubuntu) "[regression] NFS client: access problems after updating to kernel 4.4.0-31-generic" [Low,Confirmed] [19:31] hi [19:33] gQuigs, regressions are indeed of importance to us [19:34] gQuigs, that wasn't marked (correctly) as a regression, i've marked it up [19:34] jsalisbury, ^ that one needs to be on our list [19:34] apw: thanks [19:35] * bhuey reasks question [19:35] I created a flavor and I'm ahving problems loading the nvidia propreitary driver [19:35] * gQuigs is bisecting now, but still on first kernel build (slow machine, via VPN) [19:36] Builds and installs ok but I don't know what how to get the module to load without complaining [19:36] Do I needd to do something in addition to just creating a new flavor file ? [19:36] and configuring the .config of those kernels ? [19:37] I did this to enable a kernel parameter for testing that isn't on in a normal Ubuntu kernel [19:37] but it seems to be causing ABI issues [19:44] bhuey, that sounds like a description of a debian kernel flavour [19:45] bhuey, but if it is building you are not throwing abi issues, that would prevent the build [19:45] bhuey, you would be better telling us what error you see when you try and insert the module [19:46] apw: yeah this is kind of baffling as I odn't much about kernel packaging [19:46] We're building it locally here and need the Nvidia drivers for CUDA development [19:47] Basically, we compile 4.4.8 for trusty [19:47] lowlatency kernel as well [19:47] the generic one works fine, same for lowlatency but I added a kernel option to enable lock stat and the nvidia module fails to load at runtime [19:48] compiles and installs with no complains [19:48] Have zero idea what's going on to push this forward [19:48] apw: thanks for any help btw [19:49] * bhuey waits [19:51] bhuey, is there anything in dmesg at the point where you probe it in? [19:54] apw ack [19:57] gQuigs, are you going to be doing a bisect? [19:58] jsalisbury: in progress, but if anyone has a faster machine with this issue they might finish first [19:58] still on the first kernel build [19:59] gQuigs, I have build servers that can build a kernel in 20 minutes or so. If you send me the current bisect log, I can build the kernels for you and post a link to them in the bug? [20:01] jsalisbury: sure thing - http://pastebin.ubuntu.com/20352223/ [20:02] it's just the first build so I assumed that rebuilding 4.4.0-28 and 4.4.0-31 wasn't needed [20:02] gQuigs, I'll build that kernel and post it in the bug. If you test it and post the results, I can then update the bisect and build the next one. [20:03] jsalisbury: feel free to just ping me here, I'll be around [20:03] thanks! [20:03] gQuigs, [20:03] gQuigs, ack [20:09] gQuigs, Is the issue fixed in the upstream 4.4.15 kernel? [20:10] gQuigs, if it is, it might be better for us to reverse bisect to find the commit that fixes things [20:10] jsalisbury: yea 4.4.15 works fine, but keep in mind I haven't found an upstream kernel to have the issue to begin with [20:10] err [20:11] gQuigs, ahh, ok. Then it is probably due to a SAUCE commit. [20:12] gQuigs, have you tested the -proposed kernel, i _thought_ that had 4.4.15 applied [20:12] gQuigs, The xenail -proposed kernel alread has the 4.4.15 updates. It might be worth a shot testing it while the bisect kernel builts. [20:12] heh, collision. [20:12] will cancel my build and try that [20:12] gQuigs, great. and my build is going [20:21] 4.4.0-32-generic #51 in proposed has the issue as well [20:22] gQuigs, Ok, a bisect is the best route then. [20:23] I'm guessing it's related to the series under - cgroupfs mounts can hang [20:23] as the NFS failure says - [80914.821533] <-- nfs_xdev_mount() = -1 [20:23] [80914.821535] nfs_do_submount: done [20:23] [80914.821536] <-- nfs_do_submount() = ffffffffffffffff [20:23] [80914.821577] <-- nfs_d_automount(): error -1 [20:24] gQuigs, First kernel is done building. You can get it here: [20:24] http://kernel.ubuntu.com/~jsalisbury/lp1603719/ [20:27] gQuigs, apw There are only 6 SAUCE patches between 28.47 and 31.50: [20:28] 9ef55b6 UBUNTU: SAUCE: drm: check for supported chipset before booting fbdev off the hw [20:28] 7b97729 UBUNTU: SAUCE: (noup) Update zfs to 0.6.5.6-0ubuntu10 [20:28] 302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches [20:28] 765ab2f Revert "UBUNTU: SAUCE: cgroup: Use a new super block when mounting in a cgroup namespace" [20:28] 3988fb7 Revert "UBUNTU: SAUCE: kernfs: Do not match superblock in another user namespace when mounting" [20:28] f256722 Revert "UBUNTU: SAUCE: (namespace) mqueue: Super blocks must be owned by the user ns which owns the ipc ns"y [20:28] guess I should have pastbin'd that [20:29] http://paste.ubuntu.com/20356124/ [20:32] gQuigs, apw three are reverts, so I'm going to assume they probably didn't cause the bug. Could be: [20:32] 302cabb UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches [20:32] jsalisbury: that kernel has the issue; git bisect bad [20:32] jsalisbury, that is paired with the three reverts [20:32] apw, hmm [20:33] sforshee, ^ [20:33] apw, maybe I should revert 302cabb and build a test kernel with those other three reverts reverted [20:35] jsalisbury, i'd say so [20:36] apw, sforshee crap, f256722 doesn't revert cleanly. [20:38] jsalisbury, which order are you reverting them, that the last one i assume [20:39] apw, yeah. The last one reverted first. [20:40] jsalisbury, must be something on top needing revert first [20:40] apw, I'll see what other commits happened around it [20:40] prolly the other two namespace ones [20:40] apw, yeah, trying to find it now [20:41] apw, trying those two namespace ones [20:42] apw, there are 5 other namespace ones [20:43] apw: http://paste.ubuntu.com/20358102/ [20:43] actually 6 [20:44] apw, maybe I'll just revert the whole lot [20:44] jsalisbury, apw: "(namespace) vfs: Pass data, ns, and ns->userns to mount_ns" touches nfs, but I'm not seeing how it would cause that problem [20:44] I'd think if there was a problem it would happen at mount time [20:45] sforshee: it is "mount" time, just submount time [20:45] for example I can access /cfs/home, but not not /cfs/share [20:46] gQuigs: but does that actually trigger a separate filesystem mount operation? [20:46] see the NFS error I posted above (nfs_xdev_mount), not sure what that translates to elsewhere [20:47] but according to NFS, yes... [20:51] sforshee, gQuigs I'll build a quick test kernel with a5abdcb for a test [20:53] with a5abdcb reverted [20:53] ah, that makes more sense :) [20:53] gQuigs, heh, I typed it then looked at another monitor :-) [20:54] gQuigs, should be ready in about 10 minutes [20:54] awesome, thanks! [21:00] it does do some mount stuff, but I'm still not seeing how that's going to end up through the call path which now has a capability check on the net ns [21:02] I wonder if it has more to do with moving where sb->s_fs_info gets set [21:09] apw: not that I can tell. The Xorg logs shows that it's unable to load the device. I'll have to reboot back into that kernel if I want to find it in the logs [21:09] apw: should I do that ? [21:14] gQuigs, test kernel is ready. Same location: [21:14] http://kernel.ubuntu.com/~jsalisbury/lp1603719/ [21:14] oh, I think it's sget [21:17] yeah, it almost certainly is. The internal mount doesn't use MS_KERNMOUNT, and now sget has a capability check if that isn't used [21:20] sforshee: jsalisbury the reverted kernel still fails [21:21] gQuigs: that's what I'd expect if my suspicions are correct [21:21] I'm going to try to reproduce locally, shouldn't be difficult, then I can test my theory [21:22] gQuigs, sforshee ack [21:46] going away for a bit, will test anything else when I get back later tonight [21:46] thanks! === JanC is now known as Guest9881 === JanC_ is now known as JanC