[02:54] <hallyn> apw: sforshee: so "recently" eric did the patches so that if you mount something over part of /proc, an unpriv user (in userns) can't uncover the mounted part.  can't umount the cover, can't mount a new instance
[02:56] <hallyn> i didn't really think it was something people did...  more importantly it causes trouble for nested unprivileged containers.  since lxcfs files are mounted over procfiles, unpriv user can't then create a container
[02:56] <hallyn> how would you feel about a sysctl to turn that off?
[02:56] <hallyn> (it's done only for proc and sysfs near as i can tell)
[02:57] <hallyn> maybe i'll see how eric feels about that upstream
[03:00] <hallyn> hm, though what i'm seeingdoesn't *really* make sense...
[03:06] <hallyn> hm, maybe there should be an added check for sb equivalence
[03:07] <hallyn> probably doesn't make him feel as cozy...
[03:11] <hallyn> heh, can't do that.  no sb yet
[03:22] <hallyn> well let's instrument for one more debug kernel
[04:25] <stgraber> hallyn: one thing that worries me there is that those fixes are in stable, so that effectively broke or will break all of our users... admitedly I'm probably the biggest user of userns nesting, but still, I can't be the only one.
[04:26] <stgraber> adding a sysctl may be fine, but we'd have to SRU a lxc packaging change to all supported releases to turn said sysctl on (and do so conditionally depending on kernel version as some won't have it)
[04:26] <stgraber> anyway, going to bed now
[11:19] <Tehdastehdas_> I'm trying to report a kernel bug using "ubuntu-bug linux" as instructed in https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies . The first instruction after that is "The submitter should provide as much information as possible in the bug description". Where do I write this bug description? The first thing Apport asks me after launching it is "Send the report? | Cancel / Send"
[11:21] <jpds> Tehdastehdas_: That's after you send it
[11:21] <Tehdastehdas_> Oh
[11:23] <Tehdastehdas_> I wonder how many other users stopped there...
[11:23] <teward> you'd be surprised how many people run `ubuntu-bug` for other packages and just don't put information in either
[11:24] <Tehdastehdas_> maybe they have browser trouble
[11:35] <Tehdastehdas_> Success: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1491797
[11:37] <jpds> Tehdastehdas_: Did you configure the system to suspend on overheat?
[11:38] <apw> we have a configuration option for that
[11:38] <apw> from what i can see the kernel is seeing the machine hit a critical temperature milestone and bailing to avoid dammage, that seems appropriate
[11:39] <jpds> Yeah, it doesn't sound like it's being "foolish"
[11:39] <Tehdastehdas_> But why not suspend as default?
[11:40] <jpds> Tehdastehdas_: I can't actually think of a situation where any of my machines have overheated
[11:40] <Tehdastehdas_> Sure, but just google "laptop overheating"
[11:40] <jpds> And if it was a server room where the aircon failed... I'd rather the machines turned completely off really
[11:41] <Tehdastehdas_> How do I configure the system to suspend on overheat?
[11:42] <Tehdastehdas_> Also, how do I change the temperature limit, because sometimes bios crashes the machine first
[11:42] <jpds> Tehdastehdas_: Only reason I can think of where a laptop would overheat is a blocked fan?
[11:43] <jpds> At that point... you should clean the fan
[11:43] <Tehdastehdas_> Nope, the hardware has been disassembled, and everything was fine. Then I drilled extra holes to the bottom.
[11:44] <apw> Tehdastehdas_, the temperature limits come from the bios tables iirc
[11:44] <apw> and normally the bios is in charge of the fans and the kernel just finds out about alerts from the bios
[11:44] <Tehdastehdas_> Using xsensors I can see that the fan runs 3500 rpm right before the crash, while maximum rpm is 5000
[11:45] <apw> yep and the lenovo bios fan control has been criticised often in the older machines particularly for not spinning up quick enough
[11:46] <Tehdastehdas_> Another slow fan Lenovo bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/751689
[11:46] <apw> indeed cking (not here atm) did a very good write up of the issue, how the huristics in the bios fail to react fast enough
[11:47] <Tehdastehdas_> In my case the temperature can stay at 90 C for an hour, and the fan won't go faster than 3500 rpm
[11:48] <Tehdastehdas_> It's quiet though, that's nice
[11:51] <Tehdastehdas_> Soo, how about making the kernel throttle instead of overheat, and suspend at 97 C instead of shut down at 100 C?
[11:53] <Tehdastehdas_> by throttling I meant pausing processes to reduce heat production
[11:58] <jpds> Tehdastehdas_: Have you tried installing cpufrequtils and changing the governor of the CPUs?
[11:59] <jpds> (Not suggesting that that would solve the problem)
[12:00] <apw> Tehdastehdas_, really it should not sit at that temp for a long time, ugg, those bios' are broke
[12:00] <apw> anyhow, i'll ask someone to have a peek later when they are on
[12:02] <Tehdastehdas_> yes, the bios is broken, but the kernel has many opportunities to remedy the situation, and it wastes them
[12:07] <Tehdastehdas_> I don't have the skills to trigger cpufrequtils at a certain temperature
[12:07] <Tehdastehdas_> Besides, that's the kernel's job in my opinion
[12:10] <jpds> Tehdastehdas_: It doesn't trigger, it runs the whole time
[12:10] <Tehdastehdas_> so it runs slowly all the time
[12:11] <apw> Tehdastehdas_, the problem is the bios says to the kernel "do not do this i have it in hand", so the kernel goes about its business and later the bios says "OI YOU ITS TOO HOT STOP NOW" so it does
[12:13] <Tehdastehdas_> so the kernel should detect the faulty bios from the temperature/rpm -mismatch, and take control?
[12:14] <apw> i am not sure i can know in advance trivially, and once we get the "alert stop" i am not sure we can take control and switch to suspend
[12:14] <apw> that said i thought that on these broken lenovos there was a lenovo specific fan control thing you could use
[12:14] <apw> which would take it out of auto, switching from bios to userspace control of the fans
[12:17] <Tehdastehdas_> I tried it a couple of years ago, but couldn't make it work, don't remember why
[12:18] <Tehdastehdas_> Surely it is the kernel's decision to shut down (and not suspend), as it logs the decision
[12:19] <apw> Tehdastehdas_, not necessarily, that just means it got told it had to shutdown, that the bios said we are about to explode may mean we have no right to then ask the bios to suspend
[12:20] <Tehdastehdas_> hibernate then, that's not the bios's business?
[12:21] <apw> except that is a multi-second event we may not be give that long, i would think the contract with the bios is "stop, and make it quick else i will turn off under you"
[12:22] <apw> not getting into this situation is better, and likely user control of fans is appropriate give this is patently a broken bios
[12:22] <apw> but, anyhow, we had someone do a lot of work on this in the day, on an x201 iirc which that bug claims, and he ought to have the background on whats what
[12:23] <Tehdastehdas_> many seconds yes, as is shutting down
[12:25] <apw> Tehdastehdas_, so ... i see in the bug you mentioned there is a suggestion to run thinkfan with a specific config, have you tried that at all?
[12:26] <apw> comment #141
[12:26] <Tehdastehdas_> long time ago, didn't work, don't know why
[12:27] <Tehdastehdas_> still, I think it's the kernel's job, because users aren't that skilled
[12:28] <apw> if userspace can fix it, that can be automated such that it is simple for owners of the affected hw in all likleyhood
[12:28] <apw> the kernel is not really the right place to handle such complex heuristics as they differ for each and every broken bios
[12:28] <ogra_> didnt the thermal handling switch to userspace with themald recently ? 
[12:28] <apw> and it would have a heap of junk that most people have
[12:28] <apw> ogra_, a point indeed
[12:28] <apw> Tehdastehdas_, what series are you running
[12:28] <ogra_> (at least for intel CPUs)
[12:29] <apw> ogra_, it _is_ possible that that might be able to stave off doom in this case
[12:29] <ogra_> yeah
[12:29] <ogra_> or that thermald didnt get installed by update-manager 
[12:29] <Tehdastehdas_> series? is it not in the bug report?
[12:30] <ogra_> (which would be a serious update.manager bug indeed)
[12:31] <Tehdastehdas_> synaptic says thermald is not installed
[12:31] <ogra_> on what release are you ? 
[12:31] <Tehdastehdas_> 14.04
[12:31] <apw> Tehdastehdas_, it might be in the bug report, but it would have been easier to tell me than tell me its in the bug report
[12:31] <ogra_> iirc it is required from vivid on 
[12:31] <ogra_> ah
[12:32] <apw> ok then the latest is available in vivid, as the linx-lts-vivid backport is there
[12:32] <Tehdastehdas_> but I don't recognize the word "series" in this context
[12:32] <apw> so ... i would suggest you try switching to the lts-vivid hwe kernel which will pull in and use thermald as well
[12:32] <ogra_> right, something in the hwe stack needs to pull it in apparently 
[12:32] <apw> sorry my bad, that is what launchpad calls a release
[12:33] <apw> Tehdastehdas_, so like install linux-generic-lts-vivid and and then reboot, and see if things are any better
[12:34] <apw> Tehdastehdas_, and if you do, regardless of whether it works, mention we suggested and your tried it, and what the result was
[12:38] <Tehdastehdas_> got it, rebooting
[12:58] <Tehdastehdas_> apw, installed it and rebooted - still max. 3500 rpm after several minutes at 95 C
[12:59] <Tehdastehdas_> am I supposed to add this information to the bug report?
[12:59] <apw> and cat /proc/version_signature says you have a 3.19 kernel and is thermald running
[12:59] <apw> and yes if you are running the new version and its there, writing that in the bug helps
[13:00] <Tehdastehdas_> it says Ubuntu 3.19.0-26.28~14.04.1-generic 3.19.8-ckt4
[13:00] <apw> ok thats good, so it is the new version
[13:00] <apw> ps -ef | grep thermal
[13:00] <apw> does that say thermald is running
[13:01] <Tehdastehdas_> thermald --no-daemon --dbus-enable
[13:08] <apw> Tehdastehdas_, ok record all that in the bug, and i'll ask someone to have a look when they are in
[13:14] <Tehdastehdas_> commented the bug report accordingly
[13:29] <apw> Tehdastehdas_, thanks
[19:29] <MikeCamel> terrible newb qu: anyone got a good way to add a patched file to a source (dkms) deb file?  file-roller fail...
[19:33] <FrauHase> Hi
[19:33] <MikeCamel> HI
[19:34] <FrauHase> Is there a chance to disable IPv4-support (for a IPv6-only network)?
[19:35] <apw> FrauHase, i'd say i normally just configure without ipv4 addresses
[19:35] <apw> we have a coulpe of people who run ipv6 only networks, and things work modulo the internet not being very accessible v6 only
[19:36] <stgraber> you can totally fix that by having your gateway do DNS64 and NAT64 for you
[19:36] <apw> stgraber, right but you need to be you to have the patience for all that
[19:36] <FrauHase> actually, its for a test environment with no access to internet ... 
[19:36] <apw> but it does work pretty well i think i heard you say
[19:36] <stgraber> though then you'll still find a few random software (mostly perl) who don't even know what INET6 are and that will break (sent a dozen or so patches to various upstreams for that)
[19:37] <stgraber> and some things like google hangouts and my chromecast who are broken for different reasons (the first being some weird server-side bug on their end, the latter being because they don't bother to do IPv6 multicast)
[19:38]  * apw watches stgraber take on the ipv6 world single handed :)
[19:41] <FrauHase> guess I'll do as apw suggests ... just hoped for a more safe way to only have IPv6 talking on the net ...