[07:46] * smb --> BOD [07:55] BOD? [07:57] cking, Beginning Of Day [08:00] ah [08:17] * apw notes cking is so last year [08:18] why? [08:18] 'cos I don't comprehend an arbitary TLA [08:18] not knowing BOD ... i bet you can't understand your kids either :) [08:19] apw is quite harsh this morning. :) [08:20] smb, its my job [08:27] ignorance is not an excuse I see [08:31] cking, there are no excuses [08:32] shame [08:32] smb, http://people.canonical.com/~apw/CVE-2011-1090-hardy/ [08:32] apw: The __nfs4_proc_set_acl function in fs/nfs/nfs4proc.c in the Linux kernel before 2.6.38 stores NFSv4 ACL data in memory that is allocated by kmalloc but not properly freed, which allows local users to cause a denial of service (panic) via a crafted attempt to set an ACL. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1090) [08:35] !kernel-src [08:35] Factoid 'kernel-src' not found [08:35] !kernel-source [08:36] You can access all the kernels for previous and current development releases at http://kernel.ubuntu.com/git. There are repositories for each supported release under ubuntu/ubuntu-.git - For more details see: https://wiki.ubuntu.com/Kernel/SourceCode [08:36] !faq [08:36] A list of common questions and answers about Ubuntu: http://help.ubuntu.com/community/CommonQuestions - Official documentation: http://help.ubuntu.com [08:38] !kernel-faq [08:38] Factoid 'kernel-faq' not found [08:40] !kernel-faq is A list of common questions about the Ubuntu Kernel: http://wiki.ubuntu.com/Kernel/FAQ [08:43] !kernel-mainline is Information and binaries of the upstream mainline kernels are found here: https://wiki.ubuntu.com/Kernel/MainlineBuilds [08:43] apw: Error: I am only a bot, please don't think I'm intelligent :) [08:43] !kernel-mainline [08:43] Factoid 'kernel-mainline' not found [08:46] * apw tires of ubot2 [08:47] !kernel-mainline is Information and binaries of the upstream mainline kernels are found here: https://wiki.ubuntu.com/Kernel/MainlineBuilds [08:47] smb: Error: I am only a bot, please don't think I'm intelligent :) [08:47] hm, does not like that either... [08:50] no odd indeed [09:09] !kernel-mainline [09:09] Factoid 'kernel-mainline' not found [09:10] !kernel-faq [09:10] Factoid 'kernel-faq' not found [09:11] !kernel-faq [09:11] Factoid 'kernel-faq' not found [09:11] hmmm [09:12] !kernel-faq [09:12] Factoid 'kernel-faq' not found [09:44] Hi, I compiled my kernel from the source code.. after make, make_modules and make install and update_grub, I rebooted.. Now when I choose the new entry from the list, It gives me this error "Kernel panic- not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" .. any suggestions ?? [09:49] Doing the install that way you likely missed to build an initrd. If "the source code" is our git repos, you should better follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel which gives you .deb packages that will do that all when you install [09:52] I downloaded from kernel.org, 2.6.38.8 .. how do I know if I have missed to build initrd? [09:53] You have no initrd.img-... with that version in /boot. Btw, if that is a vanilla 2.6.38.8 build, did you know those are already built? [09:54] !kernel-mainline [09:54] The kernel team supply continuous mainline kernel builds which can be useful for tracking down issues or testing recent changes in the Linux kernel. More information is available at https://wiki.ubuntu.com/Kernel/MainlineBuilds [09:54] !kernel-faq [09:54] A list of common questions about the Ubuntu Kernel can be found in http://wiki.ubuntu.com/Kernel/FAQ [09:54] nice [09:59] !kernel-oops [09:59] Factoid 'kernel-oops' not found [10:00] !kernel-dev [10:00] Factoid 'kernel-dev' not found [10:00] yawn [10:00] cking, she does not like you. :) [10:01] smb: I tried to compile the same version installed on my machine through source which is 2.6.38.8 .. does it cause any problem? [10:04] hemin, Apparently it does. But seriously, it would just save you the compile time and some of the worries when using the mainline builds. As your build now there are a few special drivers/modules missing but usually that does not cause problems. And installation is much simpler when using a .deb [10:07] smb, ok.. My motive to compile through sourcecode was to learn rather than just installing it [10:09] smb, i would try the .deb package too [10:11] hemin, Then I would actually start with the build your own kernel link. Which uses the exact same sources as are used for the releases (and have the ./debian infrastructure). And when being familiar with that look at mainline kernels as a secondary step [10:12] smb, ok.. would go through that document and try out [10:33] smb, I would like to remove the kernel I installed from the source.. how to do that safely as my current working kernel and the installed one has the same version? [10:37] hemin, While they are based on the same version, they should have slightly different names. You probably have a vmlinuz-2.6.38 and a vmlinuz-2.6.38-x-generic or so in /boot and likewise a directory with -gerneric (or whatever flavour you got) in /lib/modules [10:39] But as you installed them without a package the way to remove them is to remove the file / directory in /lib/modules and then run update-grub to clean up your grub menu [10:39] Note those files with -generic in them are the original ones and you should _not_ remove them [10:41] smb, yes.. vmlinuz-2.6.38.8, vmlinuz-2.6.38.8-generic both are there.. ok.. so the generic ones are not to be touched [11:07] apw: when you want, can you open an lp tracker for CVE-2010-4251? thanks [11:07] ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251) [11:08] hmm, haven't noticed that one [11:10] ppisati, should be done: bug #807462 [11:10] Launchpad bug 807462 in linux-ti-omap4 "CVE-2010-4251" [Undecided,Invalid] https://launchpad.net/bugs/807462 [11:19] cool, 10 [11:19] x === chrisccoulson_ is now known as chrisccoulson [12:44] apw, are you happy with 3.0.0-4.5 in kernel-ppa ? [12:45] herton, sconklin It looks like I need to do yet another respin of lucid-ec2. This time it even needs an aditional revert for ec2 (as I had made changes to follow the reverted patch) [12:48] smb: hmm ok, just invalidate the current tracking bug. In fact we should be doing the rebases now, you can just have the branch ready and we do the packages [12:49] herton, ok. I will be pinging you when I have pushed the tree. Want to get it test built before [12:50] ok [12:53] 连http://lists.debian.org/都被墙了？ [12:53] http://lists.debian.org/ [13:12] herton, new lucid-ec2 branch pushed out. proceed at your leisure [13:12] smb: ok [13:24] smb: the repo misses the tag for 2.6.32-317.35, the previous release, not sure this matters much [13:25] herton, I did put it. Maybe you need to try git fetch --tags? [13:25] push I mean [13:27] smb: yes, --tags brought it. I found strange as I had here the 317.36 tag but not the .35... [13:28] * smb thinks it may happen when the tag in question is not part of any named branch anymore... [14:37] sconklin - what's up with lucid SRU? [14:38] sconklin - 33.69 not getting released? [14:38] sconklin, hello :), i saw a lot of ubuntu kernel updates lately, but is there a reason that the natty kernel is still base on 2.6.38.7 instead of 2.6.38.8? [14:40] ricotz, its pending the current round of updates making it through testing and out [14:40] and lucid seems to have found one more regression [14:40] brendand: sorry, we had to resping lucid again because of another regression [14:41] so -33.70 got mode [14:41] made [14:41] herton, yep smb is correct, only things on the linear history are downloaded without --tags [14:41] skaet mentioned another fix going in? [14:41] herton, what the hec was this one [14:41] and this is the one that will be used in 10.04.3? [14:41] brendand: yep, steve talket to her [14:41] *talked [14:41] apw: let me see here the bug number [14:42] apw, i see, it has been quite some time and the last update missed it by one day ;) [14:42] do i need to put BugLink and "commit upstream" even on commits upon which other CVE commits depend? [14:42] apw: bug 805209 [14:42] Launchpad bug 805209 in linux "System locks up after upgrading to linux-image-2.6.32-32-generic-pae" [Undecided,New] https://launchpad.net/bugs/805209 [14:43] brendand: correct, this one should end in .3 point release from what I got [14:43] ppisati, all upstream commits should be recorded if they are pulled in in case we ever care to know where they came from [14:43] ok, good to know [14:43] ppisati, and anything we commit for a specific fix should mention the bug number [14:43] so i think thats yes and yes [14:43] brendand: so just watch the 33.70 tracking bug when you got the task to confirmed [14:43] ok [14:43] herton - certainly [14:50] I'm nervous about the fix for 791019 -- this ends up mixing spinlock_bh() with spinlock(). I don't think this is safe... [14:52] kees, for natty ? [14:53] tgardner: oneiric [14:53] I don't know if mixing _bh with non-_bh is safe [14:53] kees, its not. what did we miss? [14:54] let me look, I haven't seen the commit yet. fetching it now [14:55] kees, looks like all uses of ptracer_relations_lock use _bh lock/unlock functions [14:56] tgardner: ah, so they all got replaced? is that sensible? i.e. it's only to use _bh everywhere? [14:56] kees, yes, its quite sensible. [14:56] okay, cool. reading commit now [14:57] kees, if any of the list manipulation functions can be called from soft IRQ context, then you must use _bh functions for protection. [14:58] tgardner: right, that's cool. I wasn't sure if it was okay to use _bh in non-soft-IRQ context. [14:59] kees, well, in fact you have to in order to prevent a soft IRQ context from getting control. Thats the whole point. [15:05] * kees nods [15:28] besides rolling an image and testing it with qemu, is there any quick way to test a lucid amd64 kernel? [15:28] or if anyone wants to try it... [15:28] i just need a "it boots!" [15:51] ppisati, there are a few of us that are running lucid 64, put the kernel up somewhere and we will boot test it for you [15:52] bjf: i'm almosto done rolling my image [16:44] manjo: https://bugs.launchpad.net/linux/+bug/790754 is going to be reverted [16:44] Ubuntu bug 790754 in linux "[NATTY] RICOH [1180:e823] unable to read MMC cards" [Undecided,Confirmed] [16:45] sconklin, agreed ... [16:45] sconklin, why revert for natty ? [16:45] For Maverick [16:45] ok [17:07] * smb -> EOW [18:03] * tgardner --> lunch [19:06] * cking --> EOD === Quintasan_ is now known as Quintasan === yofel_ is now known as yofel [20:02] 15811424 build/buildd/linux-3.0.0/ [20:02] um... guys? that's a tad bit huge, don't you think? I'll put cash on it failing to build on most of the ppa buidlers === dannf is now known as dannf-lunch === _LibertyZero is now known as LibertyZero [21:18] what target builds linux-header-x.y.x package? [21:19] binary-headers [21:38] Sarvatt: thanks! I should have nvidia going again on my custom build :) === dannf-lunch is now known as dannf