bjf | Prf_Jakob, how about as a pull requestion pointing at your public git repo? | 01:45 |
---|---|---|
Prf_Jakob | bjf: kay, where is the ubuntu kernel located, due to holidays I'm only the messanger in this case. | 01:59 |
=== gerald is now known as Guest75034 | ||
=== edamato is now known as edu-afk | ||
bjf | Prf_Jakob, git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git | 04:42 |
Prf_Jakob | thanks | 05:03 |
=== AceLan_ is now known as AceLan | ||
ppisati | moin | 07:46 |
smb | Morning | 08:16 |
ppisati | rtg was faster than me, doh! | 09:16 |
apw | ppisati, ? | 09:30 |
ppisati | apw: i filled up an lp bug and for a staging-driver inclusion, but i didn't send the pull req yet | 09:54 |
ppisati | apw: woke up this morning just to find out that he dit it :) | 09:54 |
ppisati | proactive merging :) | 09:54 |
apw | heh | 10:12 |
apw | ppisati, that is actually more like psychic mergine | 11:42 |
marvin24 | can this small addition to a device tree be added to trusty-unstable kernel (3.14)? | 11:59 |
marvin24 | https://gitorious.org/ac100/marvin24s-kernel/commit/380d2091525792a7df5b7b948d07174bd602cb97 | 11:59 |
marvin24 | this is the last missing piece to get my ac100 booting out of the box | 11:59 |
apw | ppisati, ^^ | 12:58 |
ppisati | apw: looking right now | 13:31 |
ppisati | given that it touches only the paz00 dts (aka ac100), i'm ok with it | 13:44 |
ppisati | just a question, did you try to upstream it? | 13:44 |
ppisati | marvin24: ^ | 13:44 |
apw | smb, hey have you used lxc subuid stuff? what does a default entry look like for moi | 13:53 |
smb | apw, No, I am ignoring lxc as hard as I can | 13:54 |
apw | smb, heh ok | 13:55 |
smb | sforshee, Maybe you had more time to play with that? | 13:55 |
smb | apw, I think I remember some mapping statements but not well enough | 13:56 |
sforshee | apw: did you read stgraber's blog post? It's a really nice guide to setting that up. | 13:57 |
smb | https://www.stgraber.org/2014/01/17/lxc-1-0-unprivileged-containers/ | 13:57 |
smb | apw, ^ Just got there too | 13:57 |
smb | :) | 13:57 |
apw | sforshee, thanks | 13:58 |
marvin24 | ppisati: it's upstreamed already, but for 3.15 only | 13:58 |
marvin24 | in fact, I was a few hours too late :-( | 13:58 |
marvin24 | thanks! | 13:58 |
marvin24 | FYI: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/tegra20-paz00.dts?id=5816898b9592b877209e91c493db946ab275d825 | 13:59 |
apw | lxc_container: Could not set clone_children to 1 for cpuset hierarchy in parent cgroup. | 14:08 |
apw | sforshee, seen that ? | 14:08 |
apw | stgraber, hey ... user containers, can you have disjoint uid mappings such as below: | 14:09 |
apw | apw:200000:65537 | 14:09 |
apw | apw:1000:1 | 14:09 |
apw | lxc.id_map = u 0 1000 1 | 14:10 |
apw | lxc.id_map = u 1 200000 65535 | 14:10 |
apw | stylee ? | 14:10 |
apw | hallyn, about ? i am having trouble using your reproduce by instructions, my containers won't start | 14:11 |
infinity | marvin24: Will that DT work with 3.13 too, or only 3.14+? | 14:14 |
marvin24 | infinity: it won't work because it requires updates to the pwm and drm subsystem | 14:14 |
apw | then ... | 14:14 |
marvin24 | a bit unfortune for trusty, but well ... | 14:14 |
infinity | marvin24: I was afraid you'd say something like that. | 14:14 |
apw | not much point in pulling in the dt parts then | 14:15 |
infinity | apw: He was asking for it to be pulled into unstable, not master. | 14:15 |
infinity | That said, by the time trusty releases, unstable will have rolled over to 3.15rc, I suppose, and will include the commit from linux-next. | 14:16 |
infinity | Probably. | 14:16 |
infinity | marvin24: More curiously, are the other commits it depends on reasonably small and backportable to 3.13, or would that blow up the world (or cause our kernel team to vomit)? | 14:17 |
marvin24 | infinity: I had 3.14 in mind, which may be the standard kernel at this time | 14:17 |
infinity | marvin24: Cause if we can make your platform go with trusty's generic kernel with very little effort, I doubt we'd say no. | 14:18 |
* ppisati usually vomits for no apparent reason | 14:18 | |
marvin24 | infinity: I'm not sure which one we need, but I can find out | 14:18 |
marvin24 | this may also be helpful for other SoCs | 14:18 |
marvin24 | which have problems to get the backlight up | 14:18 |
infinity | There are pills for that. | 14:19 |
apw | infinity, i would guess 17 | 14:20 |
marvin24 | seems that it is only useful for tegra now as the drm/kms drivers also needs some change | 14:27 |
marvin24 | not worth the effort | 14:27 |
infinity | zequence: Are you going to get around to regression-testing the lowlatency SRU kernels? | 14:35 |
infinity | BenC: Can you smoketest the saucy linux-ppc kernels in -proposed on some of your kit? I'm not home this week, so can't test on any of mine. | 14:36 |
stgraber | apw: yes, you can | 14:42 |
apw | stgraber, don't seem to be able to write it such that it will actually work, it just barf at the newuidthing step | 14:43 |
stgraber | apw: I take it your current uid is 1000 right? | 14:45 |
stgraber | apw: if so, you don't have to put it in /etc/subuid as you own it already anyway | 14:45 |
apw | stgraber, yeah that is me | 14:47 |
apw | stgraber, and i had the right incantion in the other bit ? | 14:47 |
stgraber | apw: I think the rest is fine, I'm just not sure the multi-line subuid is valid, so I'd just go with "apw:200000:65537" as the second one isn't required anyway | 14:53 |
stgraber | apw: I'm assuming you've put similar ranges as "g " entries and a matching line in /etc/subgid? | 14:53 |
apw | stgraber, yeah, ok so now i have one line in subuid/gid giving me the 200000 range and the below in default.conf: | 14:55 |
apw | lxc.id_map = u 0 1000 1 | 14:55 |
apw | lxc.id_map = u 1 200000 65535 | 14:55 |
apw | lxc.id_map = g 0 1000 1 | 14:55 |
apw | lxc.id_map = g 1 200000 65535 | 14:55 |
apw | and a create does this: | 14:56 |
apw | newuidmap: write to uid_map failed: Invalid argument | 14:56 |
hallyn | apw: why do you have the 'u 0 1000 1" lines? | 14:59 |
apw | or is it: | 14:59 |
apw | lxc.id_map = u 0 1000 1 1 200000 65535 | 14:59 |
apw | lxc.id_map = g 0 1000 1 1 200000 65535 | 14:59 |
apw | hallyn, i am trying to map container 0 to my main id for convienience | 14:59 |
apw | not that that works either, hurumph | 15:00 |
hallyn | no that won't work | 15:00 |
hallyn | well the first set of 4 looks ok | 15:00 |
apw | neither work | 15:00 |
zequence | infinity: yep. I'll do it today sometime | 15:00 |
infinity | zequence: Awesome, thanks. | 15:00 |
hallyn | apw: but you say "for convenience"; lxc-create sets up the rootfs so it shouldn't really be needed... so is lxc-create failing, or lxc-start? | 15:01 |
apw | lxc-create is fialing with my setup using 0 == 1000, i was trying to do that to avoid having to have acls all over the place for 20000 | 15:02 |
apw | lxc-create was failing trying to get to .local/share/lxc or similar, without a heap of acls | 15:04 |
hallyn | apw: it looks like a bug. It's trying to run newuidmap on the same task twice which isn't doable | 15:05 |
apw | hallyn, that is kinda why i thought i might have to put them on the one line, as the command line for newuidfoo would look like that, no dice that way either | 15:06 |
apw | anyhow, with a heap of acls, things "work" | 15:07 |
hallyn | apw: no, lxc_usernsexec is supposed to just run newuidmap once. | 15:08 |
apw | hallyn, it does seem most logical to me to use my own id as root, so i can float round in my containes | 15:09 |
apw | containers | 15:09 |
hallyn | apw: nnnot. really... | 15:09 |
hallyn | you're not actually root in your container unless you start a new container anyway | 15:10 |
apw | indeed, but a lot of the filessytem is my root id, which is handy | 15:10 |
hallyn | if you trust your container :) | 15:12 |
hallyn | mind you, this is a huge bug, and i'm quite certain a regression. your use case should be supported | 15:12 |
apw | in this case i prolly do indeed | 15:12 |
hallyn | MAN dh_shlibs is slow | 15:13 |
hallyn | apw: having received no response i was going to write/test/send a patch using vfssetxattr_noperms for trusted.overlafys today | 15:13 |
hallyn | stgraber: bad news, commit 0e6e3a41089c86447fef18e54c2796b312a57a94 broke it | 15:14 |
hallyn | hm, that's not the commit id :) | 15:14 |
hallyn | oh it is, it hels if i'm in a git tree to view it | 15:15 |
stgraber | hallyn: oh, hmm, so what did I break exactly? :) | 15:17 |
stgraber | apw: so you're using ppa:ubuntu-lxc/daily ? (the commit hallyn mentioned hasn't made it to the archive yet) | 15:17 |
apw | nope, not me, i use whats in the archive | 15:18 |
stgraber | hallyn: because I use multiple uid/gid ranges with my containers here and that clearly works... | 15:18 |
stgraber | hallyn: right, so apw is using lxc 1.0.0 final which didn't have that commit (that commit is aimed at 1.0.1) | 15:18 |
apw | that explains that then, get 'er uploaded :) | 15:18 |
hallyn | apw: hm, then i'm confused | 15:20 |
hallyn | ill go have breakfast. bll | 15:21 |
apw | hallyn, i think it all makes sense now, i am doing somthing 101 will be able to do | 15:21 |
apw | so i'll stop doing that, cause it hurts, and add a heap of acls | 15:21 |
rtg | jodh, jsalisbury: whats the story on CONFIG_IPMI_HANDLER ? Is it going back to being a module ? | 15:32 |
mjg59 | I'd recommend against doing that | 15:35 |
mjg59 | Anything that uses IPMI operation regions may be randomly broken | 15:35 |
jsalisbury | rtg, configuring CONFIG_IPMI_HANDLER as a module fixes the bug, but it is also fixed as a module in 3.14 mainline, so we were also performing a revese bisect | 15:35 |
hallyn | apw: just to be sure, dpkg -l | grep lxc? | 15:35 |
hallyn | apw: what you do should be supported. | 15:35 |
jsalisbury | s/fixed as a module/built in/ in 3.14 | 15:36 |
rtg | mjg59, looks like they are still working on it. I'll leave it built-in for now. | 15:37 |
hallyn | Oh I think I see the *actual* bug :) | 15:41 |
apw | ii lxc 1.0.0-0ubuntu4 amd64 Linux Containers userspace tools | 15:42 |
hallyn | apw: i have a fix. will send a in a bit to the list, | 15:45 |
hallyn | if you want to build your own, patch is http://paste.ubuntu.com/7033605/ | 15:45 |
jsalisbury | ** | 15:54 |
jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 15:54 |
jsalisbury | ** | 15:54 |
jsalisbury | ## | 16:58 |
jsalisbury | ## Kernel team meeting in 3 minutes - #ubuntu-meeting ## | 16:58 |
BenC | infinity: Will do | 17:00 |
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues March 18th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
apw | rtg, you have prolly already noticed, but i pushed that config revert some time ago | 17:59 |
rtg | apw, yup | 18:00 |
rtg | apw, I'm messing with vmwgfx. If I can figure it out, then I'll upload later today. never can have too many kernels. | 18:01 |
apw | rtg, did you get a broken out version? | 18:04 |
rtg | I was working on it, but there is some confusing non-linearity | 18:04 |
apw | nasty indeed | 18:19 |
apw | rtg, i guss you can use the "squash" backport for comparison when done | 18:20 |
* apw seems to have a working patch for the overlayfs permissions on whiteout when using usernamespaces, one which doesn't make me hurl :) | 18:20 | |
apw | hallyn, just building you some test kernels with my patch applied, will post a link shortly if you could test | 18:21 |
hallyn | apw: oh. i'm working with that righ tnow too | 18:21 |
rtg | apw, it should be a simple matter of applying all of the patches to drivers/gpu/drm/vmwgfx since v3.13, but its kind of driving me nuts. | 18:21 |
hallyn | just using _noperm doesn't seem tow ork right | 18:21 |
hallyn | well (a) it needs to be gpl exported; and (b) i may have just done it wrong, but it left me a visible symlink to the overlayfs-whiteout file | 18:22 |
hallyn | so i'm trying a build where i set the userns in the override creds | 18:22 |
apw | hallyn, right that is what i ahve done, | 18:23 |
hallyn | ah | 18:24 |
apw | hallyn, do do it the other way you have to use them for reading as well (non-perm versions) | 18:24 |
hallyn | then we can see if we ended up with the same the exact same patch :) | 18:24 |
hallyn | and if not, why | 18:24 |
apw | and its jsut a mess, i have one of those working too, but the cred ns hack seems to work here | 18:24 |
apw | hallyn, http://people.canonical.com/~apw/overlayfs-perms2-trusty/0001-UBUNTU-ubuntu-overlayfs20-switch-to-the-init-user-na.patch | 18:25 |
hallyn | apw: looks good, thanks - I'll wait for yours to build then and test it. | 18:26 |
apw | hallyn, cool, should be soon ... | 18:28 |
apw | hallyn, annoyingly that is what i wanted to do first off, and the mention of the _noperm way side tracked me, i should have listened to self | 18:31 |
hallyn | apw: yeah... now there's a reasonable chance ppl will want your patch to turn into some more general new override_creds() extension. but we'll see. | 18:32 |
apw | hallyn, yeah, i recon there should be a "creds_ns(foo)" at least | 18:34 |
apw | more likely a "override_creds_system()" or similar | 18:34 |
apw | hallyn, kernels at: http://people.canonical.com/~apw/overlayfs-perms2-trusty/ | 18:34 |
apw | let me know how you fare, they seem to work for me | 18:34 |
hallyn | thx, will do | 18:35 |
hallyn | apw: looks good | 18:42 |
hallyn | no wait | 18:42 |
apw | hallyn, ? | 18:43 |
hallyn | heh, sudo misuse. looks good :) | 18:43 |
* apw slips out for an hour, will check in when i get back :) | 18:43 | |
hallyn | apw: oh fwiw, patch is doing great. | 20:31 |
miseria | "los regalos, gustenos o no, hay que agradecer ante todo, el tiempo que esa persona dedico para pensar en ti" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival* | 20:54 |
dpippenger | can anyone point me to the repo that contains the source files used to build the kernel located here? http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.10.31-saucy/ | 22:34 |
apw | hallyn, sweet, i'll push that on tommorrow, and shove it up as well | 22:47 |
apw | dpippenger, you need to fetch the commit in the file "COMMIT" from linus' mainline repo, and hten apply the patches in the same directory | 22:48 |
dpippenger | those patches seem incomplete, for example they reference firmware files that aren't part of the upstream kernel like bnx2x/bnx2x-e1-7.8.17.0.fw | 22:50 |
apw | dpippenger, they are made from that base, and the patches are git format-patch'd from there, so they should be complete; have you tried actually doing that? | 23:04 |
dpippenger | yes, I've gotten it to build up until the install phase, but kernel-wedge copy-firmware bombs because newer bnx* firmware is referenced in the packaging patches that generate the control data. | 23:06 |
apw | yep, we never make d-i from those images, nor use the full packaging flow either, they are just test builds | 23:07 |
dpippenger | I see | 23:07 |
dpippenger | ok, I was just concerned I was missing something since it didn't build clean | 23:07 |
apw | you likely can get it to work without those, disable_d_i=true or similar disables that | 23:07 |
dpippenger | ok, thank you | 23:07 |
apw | nope they are dirty hacks to get something for every tag, they are not intended to pass an uploaders review | 23:07 |
dpippenger | cheers all, have a nice day | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!