| alkisg | apw, good morning, a new kernel was made available for xenial but it still had CONFIG_IP_PNP=y, when will the change land, in the next update? Is a new kernel without it available anywhere for me to test with? | 06:34 |
|---|---|---|
| apw | alkisg, yes, a kernel takes days to make it through testing, that was the previous one | 08:26 |
| alkisg | apw, can I participate in testing? | 08:26 |
| apw | we are in hold because of the beta-freeze kernel wise, so the next one will be more like eow | 08:26 |
| alkisg | Thank you apw :) | 08:26 |
| apw | i could make a test kernel wheni wake up | 08:26 |
| alkisg | No no I don't want to waste more of your time with that | 08:27 |
| alkisg | I'll just wait for when it's available and report then | 08:27 |
| ricotz | alkisg, hi, what is the current state of ltsp in xenial? | 08:29 |
| alkisg | Hi ricotz, it's in a working state, but I've pushed some more upstream fixes and I'll do a microrelease in debian with e.g. 10 days and syncpackage it to xenial | 08:32 |
| alkisg | *within | 08:32 |
| ricotz | alkisg, great! :) I assume the problems due kernel layout changes are resolved for clients? | 08:33 |
| alkisg | ricotz, with "layout changes" you mean the CONFIG_IP_PNP=y change? I didn't get my hands on any newer ubuntu kernels without that, so I wasn't able to test | 08:34 |
| ricotz | do you have plans for trusty backports to support lts-kernels >= 3.19? | 08:35 |
| ricotz | alkisg, ah, I meant things like overlayfs changes | 08:35 |
| alkisg | I don't have enough ubuntu commit rights to do a backport, and it's rather painful to seperate all the bug fixes from the rest of the upstream commits, | 08:35 |
| alkisg | so I'm just pushing newer LTSP versions for 12.04, 14.04 etc to the Greek schools PPA | 08:36 |
| ricotz | alkisg, I see, I will keep an eye on that PPA! | 08:36 |
| alkisg | It's very well tested, thousands of schools are using it | 08:37 |
| ricotz | alkisg, thanks! | 08:38 |
| apw | isn't ltsp the thing that makes up edubuntu, well i guess we should call the ex-edubuntu | 08:40 |
| apw | alkisg, ^ | 08:41 |
| alkisg | LTSP was a big part of edubuntu, but the soul of edubuntu was to be a community of people that cared about using ubuntu in education, reporting issues with educational packages or mainting them etc | 08:41 |
| alkisg | LTSP is still being used quite a lot, e.g. map of half of the Greek schools using Ubuntu+LTSP: http://www.ltsp.org/stories/widget-map/?location=Greece | 08:41 |
| alkisg | The other big part of edubuntu was that it was using the gnome-flashback session, I've just sent a mail to the gnome-flashback mailing list to ask if anyone's interested in co-maintaining it or releasing a gnome-flashback-based flavor of ubuntu | 08:44 |
| alkisg | (gnome-flashback performs much better in old hardware or ltsp thin clients - while ltsp fat clients work fine with unity as well) | 08:44 |
| apw | alkisg, http://people.canonical.com/~apw/lp1259861-xenial/ | 09:03 |
| alkisg | :) Thanks a lot apw! | 09:04 |
| alkisg | apw, that kernel doesn't have the 10 sec timeout issue, all is well, client booted in 12 secs :) | 10:10 |
| apw | alkisg, ta, please add that info to the bug, the fix is committed already | 10:37 |
| alkisg | OK | 10:42 |
| alkisg | Done | 10:46 |
| === alkisg is now known as alkisg_away | ||
| pesari | I guess this is asked frequently but since I couldn't find an answer: Will Xenial have kpatch live patching? | 13:07 |
| cyphermox | ogasawara: who can I talk to about validating modules for Secure Boot in the kernel? | 15:02 |
| ogasawara | cyphermox: I think apw would be your man | 15:02 |
| cyphermox | ok, thanks! | 15:03 |
| apw | cyphermox, hi | 15:03 |
| cyphermox | hey! | 15:03 |
| cyphermox | so I'm thinking we're at the point where we have the necessary tooling in userland to support not loading unsigned modules in the kernel, unless things are explicitly "disabling" secureboot, either because it's disabled outright in the BIOS, or because shim has its validation disabled | 15:05 |
| cyphermox | actually, wait a second, I think we're still missing something *sigh* | 15:07 |
| * apw listens | 15:07 | |
| cyphermox | >.< | 15:11 |
| cyphermox | so, how does the kernel currently check signing of the modules? | 15:11 |
| rtg | cyphermox, there is no enforcement, it just complains. there is a config that we need to enable to do enforcement. | 15:12 |
| cyphermox | right, but do you know where the verification gets done? | 15:13 |
| rtg | cyphermox, in the kernel at insmod time | 15:14 |
| cyphermox | I want to verify that it would do the right thing if validation is disabled in shim | 15:14 |
| rtg | cyphermox, I don't think it will without a patch. | 15:14 |
| cyphermox | right | 15:15 |
| cyphermox | where's that code? | 15:15 |
| rtg | kernel/module.c and kernel/module-signing.c I think | 15:15 |
| apw | i think we need to ask shim and i don't think we have a way to do that right now | 15:33 |
| apw | i beleive we have the shim callbacks because they are in the boot-sevices space right ? | 15:33 |
| apw | at least until we junk those | 15:33 |
| rtg | apw, isn't that what we talked about with slangasek awhile back ? A MOKMAN variable that the kernel queries to determine if we're really in secure boot mode ? | 15:34 |
| apw | rtg, indeed, its possible it has hit mainline when we weren't looking of course | 15:35 |
| apw | i can't say i've been keeping track | 15:35 |
| rtg | nor have I | 15:35 |
| rtg | cyphermox might have some idea | 15:36 |
| apw | cyphermox, are you hoping to do this for 16.04 | 15:36 |
| apw | ? | 15:36 |
| rtg | apw, I think the goal is to turn on module signing enforcement for 16.04 | 15:37 |
| rtg | they are cutting it kinda close | 15:38 |
| apw | rtg, fine? we are i beta freeze, fine is some weeks back | 15:39 |
| apw | we have like 4 weeks, like 3 uploads | 15:39 |
| rtg | I was somewhat tongue in cheek | 15:40 |
| cyphermox | apw: I was, yes | 15:41 |
| cyphermox | it would be MokSBState I think | 15:42 |
| cyphermox | I'll look in a but | 15:43 |
| cyphermox | *bit | 15:43 |
| rtg | cyphermox, is that already in the shim ? | 15:43 |
| cyphermox | rtg: yeah, that's already in shim | 15:43 |
| rtg | cyphermox, ok, so _all_ you need is a config patch and a patch to read that variable ? | 15:44 |
| rtg | which controls implementation of signed module enforcement | 15:44 |
| cyphermox | I guess? | 15:45 |
| cyphermox | I would have to look at the code, and I will in a minute | 15:45 |
| rtg | cyphermox, (and a bunch of testing) | 15:45 |
| cristian_c | jsalisbury: hello | 15:48 |
| * apw butts out and leaves rtg to it | 15:54 | |
| === alkisg_away is now known as alkisg | ||
| slangasek | cyphermox: is MokSBState the boot services variable or the one mokmanager uses to control it from userspace? | 16:29 |
| cyphermox | it's the boot services variable | 16:30 |
| slangasek | ok | 16:30 |
| slangasek | so yes, that's the one the kernel should honor | 16:30 |
| cyphermox | mokutil sets MokSB, which MokManager reads and sets MokSBState , etc. | 16:30 |
| slangasek | assuming the kernel is able to access it | 16:30 |
| cyphermox | right | 16:30 |
| gpiccoli | hello, sorry to bother you! I have a question regarding memory management in kernel. More specifically, I wanna know how the value min_free_kbytes is set by default | 17:37 |
| gpiccoli | Seems to me it's related to the total amount of RAM, like a percentage | 17:37 |
| gpiccoli | Is it platform specific? | 17:37 |
| gpiccoli | Thanks in advance for attention | 17:37 |
| gpiccoli | I might have found the function that is generating this value: set_recommended_min_free_kbytes | 17:45 |
| gpiccoli | the name says it all hehehe | 17:45 |
| apw | gpiccoli, i beleive it is a percentage but on a sliding scale with larger ram and an upper bound througn into the mix | 17:51 |
| gpiccoli | yes apw, you're right | 18:06 |
| gpiccoli | in fact, another function provides the default value: int __meminit init_per_zone_wmark_min | 18:07 |
| gpiccoli | the algorithm is pretty well explained there | 18:07 |
| cyphermox | rtg: ogasawara: you know that the module verification stuff needs to happen on every release right? so multiple SRUs | 18:26 |
| cyphermox | slangasek: ^ | 18:26 |
| rtg | cyphermox, do you men for releases prior to xenial ? | 18:27 |
| rtg | mean* | 18:27 |
| cyphermox | yes | 18:27 |
| apw | cyphermox, on every release ? why so ? | 18:27 |
| cyphermox | I mean for *all* releases | 18:27 |
| slangasek | apw: because this is a flag day for our SecureBoot policy and we can't be signing new kernels for old releases with the new signing key | 18:27 |
| cyphermox | because we'll eventually change the signing key and the will affect all releases and we need only the new policy (signed everything) to apply | 18:28 |
| slangasek | basically, until we are able to update the module verification policy on all supported releases, there is no point in us rotating signing keys for this | 18:28 |
| apw | do we have the infrastructure for this back in P ? | 18:28 |
| slangasek | which means anyone can always downgrade security of the signature checking by booting an old bootloader, or an old kernel, or | 18:28 |
| apw | slangasek, i assume the rule is you have to turn off secure boot to use dkms in the first stab | 18:30 |
| slangasek | correct | 18:30 |
| slangasek | "Turn off" via Mok | 18:30 |
| apw | slangasek, and presumably we have to confirm like kexec is disabled at least when SB is enabled | 18:34 |
| slangasek | apw: I seem to recall we discussed that was a requirement, yes | 18:35 |
| cyphermox | slangasek: I pointed apw at some patches | 18:41 |
| === alkisg is now known as alkisg_away | ||
| genkgo | jsalisbury: see you were posting in the vss backup thread | 19:02 |
| genkgo | thought to join here, maybe you have more questions | 19:02 |
| genkgo | also just replied with answers to question you had | 19:03 |
| jsalisbury | genkgo, I'll review your reply now. I can easily reproduce the bug and it's been going on for way too long, so it has to be figured out. | 19:04 |
| genkgo | jsalisbury: hehe, tell me about it | 19:04 |
| jsalisbury | genkgo, one way to work around the bug is to shut down the VM and then back it up, but that isn't easily done in the real world. | 19:04 |
| genkgo | jsalisbury: yeah, i read something about offline backups, but cannot do, unfortunately | 19:05 |
| genkgo | jsalisbury: what i don't get is the microsoft attitude | 19:06 |
| genkgo | i mean, i get that linux is not their top priority | 19:06 |
| jsalisbury | genkgo, yeah, I have no control over that, sorry. I'll dig in the best I can, but some bits I don't have. | 19:06 |
| jsalisbury | genkgo, That's why I asked about all the different versions of the different pieces | 19:07 |
| genkgo | jsalisbury: if there is anything i can do, please let me know | 19:07 |
| jsalisbury | genkgo, I sure will. I'm going to focus on this specific bug for a bit and try to figure it out. | 19:08 |
| genkgo | jsalisbury: but regarding the different versions, trash1-z did mention something Redhat was hit too | 19:08 |
| genkgo | https://social.technet.microsoft.com/Forums/office/en-US/cfe15e32-bfbc-47e0-8d2b-382a1293b9aa/vss-issues-with-centos-66-x64?forum=linuxintegrationservices | 19:08 |
| genkgo | but maybe that is different | 19:09 |
| genkgo | because there is nothing on read-only in there | 19:09 |
| genkgo | that is more related to sudden restarts | 19:09 |
| jsalisbury | genkgo, What is puzzling to me is CentOS based on the 3.10 kernel does not hit the bug, but 12.04, based on the 3.2 kernel hits it. | 19:10 |
| genkgo | jsalisbury: yeah, but it could also be our i/o | 19:10 |
| genkgo | however, the original poster on the microsoft forums, also noticed that cent os was not crashing | 19:11 |
| jsalisbury | genkgo, right. It does take heavy I/O while a backup is in progress to hit it. | 19:11 |
| jsalisbury | genkgo, I think I'm going to get the CentOS release you have and try to reproduce the bug. If I cannot, I know where to dig. | 19:12 |
| genkgo | jsalisbury: right, but the starter of this thread https://social.technet.microsoft.com/Forums/windowsserver/en-US/8807f61c-565e-45bc-abc4-af09abf59de2/ubuntu-14042-lts-generation-2-scsi-errors-on-vss-based-backups and he is also saying "We also have some CentOS based guests running without issues from what we've seen." | 19:12 |
| genkgo | jsalisbury: alright, hopefully we can get some results | 19:13 |
| genkgo | jsalisbury: regarding our difference in i/o, our ubuntu machines are webservers and our cent os machine is exim + dovecot | 19:14 |
| jsalisbury | genkgo, I imagine web servers are mostly read only. | 19:15 |
| jsalisbury | genkgo, The script I wrote to reproduce the bug is a mix of I/O, but very heavy. | 19:16 |
| * jsalisbury is hoping I don't destroy my disk :-) | 19:17 | |
| genkgo | jsalisbury: yes, that is what i am thinking, but there are some cronjobs and workers running in there, so there are jobs to do. but honouslty, that is way lower than your script | 19:17 |
| genkgo | hehe | 19:17 |
| jsalisbury | genkgo, Yeah, the script puts the disk at 100% of it's capability. I pray I don't smell smoke. I'm going to go head down on this one to wrap it up. | 19:19 |
| genkgo | alright, good luck! | 19:19 |
| jsalisbury | genkgo, Is it CentOS 7 you are running or another version? | 19:30 |
| genkgo | jsalisbury: CentOS 7 | 19:30 |
| jsalisbury | genkgo, great, thanks | 19:30 |
| cristian_c | jsalisbury: hello, again | 19:33 |
| jsalisbury | cristian_c, hey, I submitted a patch upstream, but have not gotten a response, I'll do a resend if I don't hear anything in a day | 19:34 |
| cristian_c | oh, thanks | 19:34 |
| cristian_c | :) | 19:35 |
| cristian_c | jsalisbury: a question: usually, what is the average time upstream guys reply to a submission? | 19:35 |
| jsalisbury | cristian_c, np. I'll let you know as soon as I get feedback. I have no reason to think the patch wouldn't be accepted. It's just slow sometimes. I'll SRU it to Ubuntu as soon as it's accepted into mainline. | 19:36 |
| cristian_c | (days/week/months) | 19:36 |
| cristian_c | jsalisbury: ok | 19:36 |
| jsalisbury | cristian_c, usually days, but if I don't hear back in a week I resend the request | 19:36 |
| cristian_c | ok, thanks | 19:36 |
| jsalisbury | anytime | 19:36 |
| === alkisg_away is now known as alkisg | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!