[03:04] <thebloggu> i installed ubuntu 8.04.1 in my computer and then upgraded to 8.10 now on boot it gives an busybox initramfs error
[03:04] <thebloggu> what to do now ?
[03:06] <crimsun> thebloggu: it's difficult to predict what error message you're receiving. will you pastebin it? (also, this discussion likely needs to happen in #ubuntu instead of in here.)
[03:08] <thebloggu> crimsun, thank you for answering, i tried #ubuntu but nobody answers
[03:08] <thebloggu> btw, i was able to boot by typing exit in initramfs
[03:09] <crimsun> thebloggu: i'm also in #ubuntu. please direct your responses there.
[10:31] <bullgard4> What is the reason that http://lxr.no/ does only list for kernel 2.6.24 a maximum version number of .7 although I am using 2.6.24-22generic?
[10:34] <abogani> bullgard4:  Because 22-generic is the Ubuntu version of the kernel (that itself a stable release version as 2.6.24.7).
[10:40] <bullgard4> abogani: Thank you for explaining.
[10:48] <abogani> bullgard4: Don't mention it.
[11:57] <Kano> hi, any ideas about the nfs kernel server problem yet?
[14:26] <apw> sconklin, so ...
[14:26] <apw> is there not a default list kernel apport reporting list?
[14:26] <apw> would we not not want to report a superset for our purposes?
[14:27] <sconklin> so I'm writing a script that gathers what we want and creates the apport report on the suspend/resume testing. There are required data for a kernel report, and I'm including all those.
[14:27] <sconklin> So exactly, we will use a superset.
[14:28] <apw> is not the only thing we need to add the logfile, so would we not add a new 'type' of report
[14:28] <sconklin> Kernel apport reports are now trggered by an oops, so I just wrote a python script to generate the report.
[14:28] <apw> like is defined in /usr/share/apport/kernel_ooops
[14:29] <sconklin> right, we are not adding a new type of report, as we want to use all the existing support
[14:29] <sconklin> What I've written is not terribly complicated - there's not much to creating a report.
[14:30] <apw> its a shame that these report definitions are not classes, so they could be overridden and extended
[14:30] <apw> i think that we should leave the user warning, i think its appropriate they get the indication we are sucking info up
[14:31] <sconklin> I agree, it's evil to collect information without asking.
[14:32] <pgraner_lt> rtg: did we ever decide when we were going to put the upstream origin in /proc/version_signature for Luis?
[14:33] <rtg> huh? I thought all we were doing was adding the minor number in /proc/version
[14:37] <apw> the write up i saw said (upstream version) at the end of /proc/version_signature
[14:38] <apw> where in /proc/version would we put it
[14:39] <rtg> I think apw and amit were involved in the string stuff, though I remember that they agreed there was enough info in it for kerneloops.org
[14:39] <apw> that was about exposing our build number so we knew which kernel it really was
[14:40] <apw> and including a -Ubuntu tag so they knew it was our fault
[14:40] <rtg> right, it basically supersedes what was in /proc/version_signature
[14:40] <apw> i think what pgraner_lt is referring to is the exposure of the 2.6.28.9 side of things
[14:40] <rtg> oh, duh.
[14:40] <apw> indicating which of the stable releases you have sucked up
[14:41] <rtg> I'll put it on my list
[14:41] <pgraner_lt> apw: correct, Luis was complaining that he had no idea which source we were based on and asked for some way to check it.
[14:42] <apw> its probabally not appropraite to expose it in our version number literally because we don't necessarily suck up all the patches
[14:42] <rtg> apw: I've only dumped one so far.
[14:42] <rtg> one patch, that is.
[14:42] <apw> luckily the data is in the main Makefile so it should be simplish to find it
[14:44] <apw> yeah i didn't mean we wen't trying to track it 100%, more that it can't and now isn't guarenteed to be actually so
[14:44] <rtg> apw: soo you think it would be misleading?
[14:45] <apw> i was implying it would be missleading for it to be in any of our main version numbers
[14:45] <apw> i think its entirly appropriate in /etc/version_signature as a 'based on' kind of thing
[14:48] <apw> anyone know which VT we switch to during suspend?
[14:50] <rtg> apw: I'm pretty sure its 1
[14:58] <apw> rtg did you jauntyise your machine yet?
[14:59] <rtg> use space? no way, but I've been running .28 kernels on several machines.
[14:59] <rtg> s/use/user/
[14:59] <Kano> rtg: and does nfs work?
[14:59] <Kano> even showmount -e fails here..
[14:59] <rtg> dunno, I don't have any nfs servers.
[15:00] <Kano> it is really hard to create one
[15:00] <Kano> install nfs-kernel-server and add a dir to /etc/exports
[15:01] <apw> pretty sure that it won't work, that there were bugs outstanding upstream on it anyhow
[15:01] <Kano> and who wants to fix em
[15:02] <apw> i am sure the nfs upstream devs are on the case
[15:02] <Kano> i dont think so, because i mailed one of em and no error was even known
[15:03] <rtg> apw: didn't kees suspect a user space problem?
[15:04] <apw> ahh was it kees, perhaps i forget, cirtainly there was an upstream bug bandied about
[16:48] <apw> the limits on versions of a package in a PPA is going to seriously dammage my head
[16:48] <apw> rtg it would be helpful for debugging say against intrepid, to be able to offer an 2.6.27 and a 2.6.27.N mainline drop of the kernel for differential testing (say)
[16:49] <apw> but there is no easy way to push those into the same PPA due to the 'one version' issue
[16:49] <apw> any thoughts as to the right way to handle this
[16:49] <rtg> apw: I thought we could have multiple PPAs per user now?
[16:50] <rtg> apw: failing that, track down cprov
[16:50] <apw> hmmmm... fair point
[16:52] <rtg> apw: hey - I was just reading about the cpufreq defaults performance v.s. ondemand.  our current default is performance, but doesn't ondeman make more sense? Or does it matter if the kernel can stay in HALT long enough to make a difference?
[16:53] <apw> our default in the kernel is performance, but we switch to ondemand after boot
[16:53] <apw> something Keybuk was telling us about, that its faster to boot in performance mode
[16:53] <rtg> apw: ah. so my reasoning _is_ sound. how rare :()
[16:54] <rtg> s/:()/:)/
[16:54] <apw> yep, you are right indeed
[16:54] <apw> i was fooled by the default too
[16:54] <rtg> apw: now that you mention it, I kind of remember that conversation.
[16:54] <apw> i think it was in the session where we picked the config opotions
[16:55] <apw> and when we were looking at pushing all that =y
[16:55] <apw> /etc/init.d/powernowd seems to switch us over to ondemand
[16:56] <apw> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
[16:56] <apw> ondemand
[16:56] <rtg> ok, I'm convinced
[16:57] <apw> :) sorry
[17:07] <Keybuk> and if that doesn't, gnome-power-manager will
[17:08] <rtg> not if your're running a server
[17:08] <Nafallo> rtg: what? you don't run g-p-m on your servers?! ;-)
[17:09] <rtg> I like that clean command line interface.
[17:09] <Nafallo> :-)
[17:09]  * Nafallo wonders a bit why you have powernowd on your server though :-)
[17:11] <rtg> Nafallo: huh, it seems to be a desktop package. its not on my server
[17:11] <Nafallo> oh. thought the discussion was about ondemand scaling on servers
[17:11]  * Nafallo goes hiding again :-)
[18:51] <lool> Keybuk: So we could unseed powernowd now?
[18:52] <Keybuk> lool: err, no idea
[18:52] <Keybuk> I think I mentioned it, and got told we need it on servers
[18:57] <lool> Keybuk: We could move it to the server seed, or simply assume that new installs don't need it?  It would be nice to skip one init script during boot, even if it's a small one :)
[19:22] <CarlFK> jaunty box, for a few days plugging in a usb drive (both hard and thumb) only show "usb 5-2: configuration #1 chosen from 1 choice" and on lsusb.  no /dev gets created.  I can't find anything about his on lp.  known issue, or should I report?
[20:02] <CarlFK> #310697 how do I mark that as "jaunty"  so it shows up on https://bugs.edge.launchpad.net/ubuntu/jaunty/+bugs
[23:49] <lool> rtg: Around?
[23:50] <rtg> lool: for a few minutes more. whats up?
[23:50] <lool> rtg: Poulsbo DRM is basically a fork of the regular DRM, and isn't namespaced; it uses the same symbol names and all
[23:50] <lool> rtg: So if you try to load the regular drm and psb-drm, it blows up
[23:50] <lool> rtg: Are you saying it would work if one was built into the kernel and the other was a module?
[23:50] <rtg> no, I think we'll have a separate flavour, and hence, seperate config options.
[23:51] <lool> rtg: check hardy-lum (ubuntu/media/drm-poulsbo; CONFIG_DRM_PSB only set on lpia)
[23:51] <lool> rtg: Ok
[23:51] <lool> rtg: What flavour will we use for psb on i386?
[23:52] <rtg> I don't know yet, perhaps lpia?
[23:52] <lool> You mean lpia flavour but i386 arch
[23:52] <lool> Would work I guess
[23:52] <rtg> correct
[23:53] <rtg> was that all? its about beer time here.
[23:53] <lool> rtg: Mind if I copy/paste this exchange into the list to close the discussion?  I'll Cc: amitk who I understand is still looking at lpia stuff
[23:53] <lool> rtg: It was all
[23:53] <rtg> lool: no problem.
[23:53] <lool> Thanks
[23:54] <rtg> I'm outta here