| === nick is now known as Guest8685 | ||
| === LetoTheII is now known as LetoThe2nd | ||
| === Guest68144 is now known as wordpress | ||
| === wordpress is now known as ikonia | ||
| ppisati | brb | 09:24 |
|---|---|---|
| siretart | apw: sorry for being a PITA :( | 10:41 |
| apw | siretart, ? | 10:43 |
| siretart | apw: your patch for fixing the xattr issue in overlayfs does not seem to be sufficient | 10:43 |
| siretart | bug #1039402 | 10:43 |
| ubot2` | Launchpad bug 1039402 in linux "[quantal] overlayfs over r/o NFS mount fails to overwrite existing files" [Medium,In progress] https://launchpad.net/bugs/1039402 | 10:43 |
| apw | what specifically are you doing and what is failing | 10:44 |
| apw | and how is it failing | 10:44 |
| siretart | apw: have you seen the screenshot? it documents my testcase pretty precisely | 10:44 |
| siretart | https://launchpadlibrarian.net/113349441/screenshot-bug1038075.png | 10:44 |
| siretart | apw: interestingly, a 'rm /etc/resolv.conf && echo foo >/etc/resolv.conf' does succeed | 10:45 |
| * apw goes retest, as thats my test case too | 10:46 | |
| apw | siretart, the rm echo combination would indeed avoid the bug | 10:47 |
| siretart | apw: TBH, I'm not sure about your patch. you check for ovl_copy_up_xattr() returning -EOPNOTSUPP. However, if the underlying fs does not support it, I'd expect the vfs_listxattr call in line 32 to already indicates that (line 34), in which case '0' is returned | 10:57 |
| apw | siretart, heh and looking in there i would expect so too, though i ended up at this fix not by inspection but by debugging it and confirming we were returnign that error code | 10:59 |
| apw | siretart, and indeed my machine here running the -pre1 of the kernel i sent you works | 11:00 |
| apw | hmmm | 11:00 |
| siretart | so maybe the fix is correct but incomplete | 11:01 |
| apw | except your test is identicle to mine, so i cannot see how i am not testing the same way you are | 11:01 |
| * apw goes check that the -pre1 and final kernels behave the same | 11:02 | |
| * siretart goes installing the kernel on bare metal as well | 11:03 | |
| * henrix -> lunch | 11:05 | |
| siretart | apw: funny, I cannot reproduce the problem when booting 'normally', but it does still persist in the nfsroot scenario that involves the 'live-boot' package | 11:08 |
| apw | siretart, so the kernel fixes something then | 11:09 |
| apw | i can only assume it is about how the nfs mount is mounted | 11:09 |
| siretart | hmm.. maybe the -o nolock option? | 11:10 |
| siretart | apw: indeed, it seems that -o nolock does make a difference. can you confirm that? | 11:12 |
| apw | siretart, sigh, will do | 11:13 |
| apw | ok confirmed it works in my testing without -o nolock with the kernels i posted | 11:19 |
| siretart | yes, I can confirm that too | 11:20 |
| siretart | however, in that nfsroot environment there is no nfs locking daemon available | 11:20 |
| apw | siretart, how can i confirm its mounted nolock ? as my testing mounting -o nolock works | 11:24 |
| siretart | apw: grep ',nolock,' /proc/mounts | 11:25 |
| apw | siretart, ok its not there dispite asking for it | 11:26 |
| apw | siretart, can you paste your entire mount line please | 11:26 |
| siretart | mount -o nolock -o ro -t nfs 1.2.42.40:/i4lab.stand/proj/fai/nfsroot.quantal64 /mnt | 11:26 |
| siretart | results in this line in /proc/mounts for me: | 11:27 |
| siretart | 1.2.42.40:/i4lab.stand/proj/fai/nfsroot.quantal64/ /mnt nfs ro,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=131.188.42.40,mountvers=3,mountport=57036,mountproto=udp,local_lock=all,addr=1.2.42.40 0 0 | 11:27 |
| apw | siretart, ok i am simply unable to mount the damn thing no-lock, is there anything special on the export side? | 11:30 |
| apw | siretart, oh and you are mounting as v3 there ... mine defaults to v4 | 11:31 |
| siretart | I'm using these export options: (ro,no_root_squash,sync,no_subtree_check,insecure) | 11:31 |
| siretart | yeah, we have disabled v4 as we have experienced a number of problems with it (*cough*solaris*cough*) | 11:32 |
| apw | siretart, ok how have you disabled v4 | 11:34 |
| apw | i suspect that is why i am not seeing it | 11:34 |
| siretart | apw: I'm checking. but maybe you can force it by using '-o vers=3' as mount options? | 11:36 |
| apw | ahh that does it | 11:37 |
| apw | siretart, ok, so this is yet a third bug, i am starting to hate you :) | 11:38 |
| apw | siretart, i have it reproducing now, its definatly something different as it has a differnet error code to user space | 11:38 |
| apw | siretart, i am also a bit confused by the nosupp thing as that should be caught in copy_xattr and clearly is not | 11:38 |
| apw | siretart, so will go debug it yet more ... bloody nfs | 11:39 |
| siretart | apw: you have my sympathy :-( | 11:39 |
| siretart | I know that we have disabled v4 in the automounter, but that's not relevant here. would need to ask folks here how we did it, but it seems that's not relevant anymore | 11:40 |
| siretart | just FTR, we disable NFSv4 by setting RPCNFSDCOUNT="-N 4 200" in /etc/default/nfs-kernel-server | 11:47 |
| === yofel_ is now known as yofel | ||
| ppisati | infinity: can you promote 3.5.0-209.15? | 12:50 |
| ppisati | rtg: do i need to send an email to ubuntu-installer for every upload? don't they follow -meta? | 12:50 |
| rtg | ppisati, might be a little early in the day for Adam. you need to send an email to the installer list for every ABI bump because it requires manual intervention in the d-i | 12:51 |
| ppisati | rtg: ok | 12:51 |
| stgraber | hello, I'm being nagged about bug 995998 as it's affecting quite a few thin client deployments, can the fix be cherry-picked in 12.04? | 13:02 |
| ubot2` | Launchpad bug 995998 in linux "fix hp t5745 and hp st4757 lvds patch in drm" [Medium,Confirmed] https://launchpad.net/bugs/995998 | 13:02 |
| rtg | stgraber, seems pretty straightforward | 13:03 |
| cking | iso testing thursday is taking longer than I anticipated today :-/ | 13:06 |
| === Guest81255 is now known as jpds | ||
| === ayan_ is now known as ayan | ||
| === cyphermox_ is now known as cyphermox | ||
| * ogasawara back in 20 | 15:02 | |
| infinity | ppisati / rtg: No one normally sends us mail about ABI bumps, I just promote and do the bumps based on what's in proposed. | 16:00 |
| rtg | infinity, actually, we're _supposed_ to send email notifications of ABI bumps. whether they are actually necessary depends on the person uploading the d-i | 16:02 |
| infinity | rtg: Do you actually do so? If so, it's to a list I'm not subscribed to, and I do most of the d-i ABI uploads. :P | 16:04 |
| infinity | (Anyhow, the only reason I didn't do omap4 yesterday was because I was tossing around the idea of doing some d-i bugfixes in the same upload) | 16:04 |
| rtg | infinity, ubuntu-installers and kernel-team@lists.ubuntu.com are the 2 lists that get the ABI bump announcement | 16:06 |
| infinity | Ahh, well, I am subscribed to kernel-team, I just rarely read it. ;) | 16:06 |
| infinity | Anyhow, I don't need the reminders, so it's moot. I agree that it's still good practice to send them. | 16:07 |
| xnox | rtg: infinity: maybe the ABI bump emails were relevant before we were using $dev-proposed. It was an indication to me - do not do partial dist-upgrade until things settle. | 16:26 |
| ppisati | do any of you have a working dvi <-> vga adapter? | 16:29 |
| ppisati | i bought one but it seems it's not working... | 16:29 |
| cking | ppisati, co-incidentally, I just picked one up that works as you asked that question | 16:30 |
| ppisati | doh! | 16:30 |
| ppisati | brand? | 16:30 |
| ppisati | shape? price? | 16:30 |
| cking | no idea, let me send a photo of the pins | 16:30 |
| ppisati | mine is exactly this one: http://www.qvs.com/images/DVI_VGA_ADAP.jpg | 16:32 |
| cking | ppisati, see http://en.wikipedia.org/wiki/Digital_Visual_Interface, mine is the DVI-A | 16:32 |
| ppisati | bought from amazon | 16:32 |
| cking | yep, looks the same to me | 16:32 |
| cking | DVI-A (analogue) for VGA | 16:33 |
| cking | I love DVI, so many standards in one handle socket | 16:33 |
| ppisati | :( | 16:33 |
| cking | s/handle/handy/ | 16:33 |
| * ogasawara lunch | 19:12 | |
| * cking -> EOD | 19:21 | |
| === jibel__ is now known as jibel | ||
| === rsalveti` is now known as rsalveti | ||
| cyphermox | hey; seems like there's a bad side effect to a fix included in 3.2.0-29.45; just thought to bring it up if you run into other reports of it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1035590 | 22:15 |
| ubot2` | Ubuntu bug 1035590 in linux "Kernel update on 10 Aug 2012 affects nm-applet signal strength" [High,Confirmed] | 22:15 |
| herton | cyphermox, yes, the fix that brought this bug should be this: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-precise.git;a=commit;h=d5b65f764c414a8da02c479f7fa57cfaee603fd3 | 23:57 |
| herton | came through 3.2 stable update | 23:57 |
| herton | at least we think it is this one, that was the only change to ipw | 23:57 |
| herton | cyphermox, should we revert it, or will this be handled through nm? I think we can't ask stable upstream to revert this, seems just something that affects our nm+kernel | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
