[01:54] Any idea why I'm getting these errors? http://dpaste.com/140771/ === Hellow_ is now known as Hellow [05:18] really quiet in here... [05:19] anybody have an idea? [05:21] kinda lacking in detail, there [05:21] e.g., what's the base linux source? [05:23] crimsun: Ubuntu-2.6.32-9.13 [05:24] which config options did you change? [05:24] a pristine copy of linux_2.6.32-9.13 gets past that point ok [05:24] I tried using the same .config I was using from karmic [05:25] is it available somewhere? [05:26] http://paste.ubuntu.com/351086/ [05:32] crimsun: I was hoping it was a simple little thing but it seems I have something pretty screwed up.. [05:44] heh [05:44] pretty straightforward, actually: [05:44] ~/tmp/linux-2.6.32 $ grep -ni initrd .config [05:44] 106:# CONFIG_BLK_DEV_INITRD is not set [05:45] ot/config-2.6.32-9-generic < [05:45] 127:CONFIG_BLK_DEV_INITRD=y [05:46] i.e., init/initramfs.c [05:46] see commit 29f1e2 of ubuntu-lucid.git [05:49] crimsun: how do you see a certain commit? [05:49] do you have a local copy of ubuntu-lucid.git ? [05:49] ya [05:50] I found it on gitweb, but I'd like to learn how to do it with git too [05:51] git log -p 29f1e2 [05:56] crimsun: is there any part of kernel work that's simple and easy? [05:57] MTecknology: sure, there are quite a few classes of low-hanging fruit [05:58] crimsun: if I want to just dive in; where would you suggest doing it? [05:59] I guess I should go through the .config and where it says something isn't set and set it [06:00] MTecknology: depending on experience and comfort with C, there're a few ways (at least) [06:01] MTecknology: the recommended bug lists that Leann releases is one [06:01] I know very very little C; mostly only what I learned from bash scripting [06:02] MTecknology: you could try easing into the janitors project [06:02] #kernelnewbies, OFTC [06:03] where's teh list lean puts out? [06:03] http://qa.ubuntu.com/reports/ogasawara/kernel-buglist.html [06:06] crimsun: thanks, I'll muck around that once I have this compile works [06:12] crimsun: so the fix should have been to just do CONFIG_BLK_DEV_INITRD=y; right? [06:13] MTecknology: depends whether you want the simple way [06:13] I'd prefer not have any initrd [06:14] arguably there's little point to async population if you aren't using an initrd, so you could just fix the patch [06:14] he, me fix something? [06:15] I don't know the best way to do it, because I didn't write it, and I don't know the intricate implications of conditionalising that particular code [06:19] crimsun: thanks for that info; taught me more than I wanted to learn today :P [06:21] crimsun: I tried to built it after setting that and it changed back to is not set [06:35] crimsun: that's a big list, non of them look very simple [10:05] crimsun: I almost have it... I'm getting this error during but and it hangs at maintainance shell, I do Ctrl+D and it reboots " [10:05] mountall: could not connect to Plymouth" [10:06] I think it's something to work on for tomorrow... 04:06 here [10:07] hi all [10:07] unggnu: hi [10:07] What is the status of Nouveau and the Kernel in Lucid? [10:07] hi MTecknology [10:09] unggnu: what's with the nick? [10:10] MTecknology: ? [10:10] why did you pick it? [10:10] I kinda like it... the "un-gnu" part [10:11] MTecknology: I don't know, a palindrome and some other things :D [10:13] unggnu: You should apply for Ubuntu membership.. Just looking at the work you've been doing [10:14] unggnu: You have any idea what would be needed in the lucid kernel that the lack of would cause this message? "mountall: could not connect to Plymouth" [10:14] MTecknology: I am pretty sure that the Plymouth part isn't ready yet, at least it wasn't the last time I have checked [10:16] unggnu: I'm trying to compile my own slimmed down kernel. I'm using my .config from karmic and trying to make it compile with the lucid source. I got it to compile with the help of crimsun but now when I boot I get that error. [10:16] MTecknology: https://wiki.ubuntu.com/FoundationsTeam/LucidBootExperience [10:16] MTecknology: I got this error even with the default Lucid kernel [10:16] At least some weeks ago [10:17] hurray [10:17] the current generic kernel gave no errors [10:19] unggnu: so summing it up; wait a couple weeks before I try to mess with it again? [10:23] MTecknology: I still got the message with the generic kernel [10:23] just switch to terminal f8 [10:24] brb [10:31] unggnu: I couldn't switch to tty8; I couldn't mount anything either; / was mounted but that was it [10:32] unggnu: this might just be an issue I need to wait out [10:32] it's 04:30 though - I should get some sleep [10:32] unggnu: thanks === jk is now known as Guest81548 [10:33] MTecknology: good night :) [13:14] hi all, compiling the nvidia kernel module 190.53 for 2.6.33-rc2 fails with the error message http://pastebin.com/d3b8ac89b ... any idea, what is going wrong? [13:14] i am running: dkms build -m nvidia -v 190.53 -k 2.6.33-rc2 --kernelsourcedir /usr/src/linux-headers-2.6.33-rc2/ === fabbione_vac is now known as fabbione === saispo_ is now known as saispo === akgraner` is now known as akgraner === bjf-afk is now known as bjf [15:42] Keybuk, wrt to bug #499491, is building TUN/TAP into the kernel really the right solution? Seems like its a class of problems, e.g., what about other boot essential drivers? [15:42] Malone bug 499491 in openvpn "tun module no longer automatically available (was: Euca 1.6.2 fails to boot an instance)" [High,Invalid] https://launchpad.net/bugs/499491 [15:45] yeah it's a long established class of problems [15:45] basically since the introduction of devfs! [15:45] things like ppp, tun, etc. [15:45] pretty much all "network class" devices [15:45] so, shall I just work around this one? [15:46] if the code for them is in a module, the device node doesn't exist in /dev [15:46] which means you can't use them without loading the module [15:46] but these things are designed to be used by normal users [15:46] who can't load the moduel [15:46] there is no real downside to building it in other then size increase [15:46] right [15:46] and we were force-loading tun anyway before [15:46] ok [15:47] which meant it was in the initramfs [15:47] which is an even greater size penalty [15:47] and wasn't possible to blacklist [15:48] ironically, most network class things don't have this problem, because they use sockets not device nodes [15:48] and since the socket is opened from userspace [15:48] but the "internal open" happens in kernelspace [15:48] the kernel *can* call modprobe ;) [15:48] yeah, TUN is special. [15:48] (there's a chapter in my book about this :p) [15:49] are you kidding about the book? [15:50] no [15:51] has been my holiday project to make a start on it [15:51] ah, guess thats why I had not heard about it. [15:51] the kernel team will be at Millbank next week. will you drop by one day? [15:51] I'm in Sydney most of next week [15:51] the bits of it that I'm not, I'm in the air [15:52] but I may drop by on the way to Heathrow if I have some time [15:52] Sydney? I thought linux-conf.au was in NZ this time? [15:52] oh, but its the following week [15:52] book is going to be called the Linux Plumbers Handbook, it basically covers the kernel userspace interfaces, and all the bits that plug into them up to the X server [15:52] right, Sydney is holida [15:52] cool [15:52] I'm not flying half way around the world and not chilling out in Sydney first ;) [15:53] slacker ! you just had one ! [15:53] (happy new year etc :) ) [15:54] ogra: I had very little holiday last year :p [15:54] heh, me too ... as little that david forced me to take december off [15:55] and, well [15:55] LCA [15:55] Sydney holiday is mandatory [15:55] i thik this was the first 3 weeks in a row i ever took since working here [15:55] it's one of those airports I refuse to just transit through [15:55] because it's a beautiful city [15:55] and LCA is in NZ [15:55] so I obviously need to take some holiday there too and see the island [15:55] seems like a wise policy to me :) [15:55] yeah, indeed, i wasnt serious :) === ogasawara_ is now known as ogasawara [16:56] smb: howdy! :) [16:56] ogasawara: hi! [16:57] any suggestion on how to proceed with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/396286 [16:57] Malone bug 396286 in linux "[Geode LX] [OLPC] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] [16:58] Q-FUNK, Hi, not a better one than either get the kernel build with the suggestions from hpa or succeed on making them reproduce it [16:59] smb: it fails to build, here. it repeatedly dies with a "truncated file" error. [16:59] Q-FUNK, are you using ccache? [16:59] ccache ?? [17:00] probably not. never heard about it [17:00] Q-FUNK, If you don't know, then never mind. :) [17:01] heck, even simply trying to build the kernel without hpa's patch fails as above. [17:01] something in either gcc or the kconfig defaults makes it fail to build on this geode. [17:01] Q-FUNK, Is there even the slightest chance that your machine could have a hardware problem? [17:02] IOW do we have anybody else seeing the same problems as you do on another machine? [17:02] rolling back to jaunty and building those kernels works. [17:02] or running any stock kernel package from the ubuntu vanilla collection until 2.6.30 works [17:03] only vanilla kernel packages after 2.6.30 flatly don't run [17:04] until 2.6.30, whether self-built, jaunty generic or ubuntu vanilla package, it all works fine [17:04] it's only since during karmic development phase, after the generic kernel was switched from 2.6.30 to 2.6.31 that generic kernsl fail to run or build. [17:07] I'm thus wondering whether the kernel might have acquired some new code that makes it fail to boot on older hardware, the same way that changes that came in 2.6.23 make the kernel stop booting on older geode GX1 hardware. [17:08] well, there's a few people subscribed to the bug, so I'm guessing that others are affected too. [17:09] or were some defaults changes in -generic that only make it work on 686 or newer? [17:10] am I supposed to use the -486 kernel on older hardware? [17:10] erm, sorry, 386 [17:10] Q-FUNK, The problem was that the bisect went for code that is quite unrelated and also the "working" kernels I build for you were just adding delays. So either its not the real cause and its another patch or there is a hw specific problem that just surfaces in certain timing conditions [17:10] could be [17:11] hpa points to some distros having changed GCC defaults as a possible cause. does that affect ubuntu? [17:12] Q-FUNK, I think the main reason for 386 was something else which I don't remember atm. We did not change the gcc options for the kernel build afaik [17:13] hpa refers to gcc built-in defaults changes [17:14] well, could hpa's patch be applied to the ubuntu kernel anyhow, just to be safe? [17:21] smb: I'm curious as to whether a test package of 2.6.32 generic without your kprint additions and with hpa's patch instead would wokr. however, it flat out fails to build here. [17:22] Q-FUNK, I will try to build you a package tomorrow. [17:23] smb: thanks! === yofel_ is now known as yofel === bryce__ is now known as bryyce === Nafallo_ is now known as Nafallo [19:48] apw: could you update bug 429257 for pitti? [19:48] Malone bug 429257 in gvfs "MMC cards no longer auto mount" [Undecided,Incomplete] https://launchpad.net/bugs/429257 [19:49] bdmurray, apw is not back until tomorrow [19:50] rtg: okay, maybe he'll see it then ;-) [20:14] Anyone know about Mantis drivers for Ubuntu 10.04? [20:14] They exist in linux-next now [20:16] a lot of people waiting for this driver, also its shouldn't mess anything [20:17] is possible to backport this driver? [20:59] anybody got thoughts on 503109 ? other than that it's a eglibc issue [21:22] If you guys put the "view" of Linux into one line, what would it be? [21:22] fully free and open wouldn't work because some proprietary code exists afaik.. === RAOF_ is now known as RAOF