[06:54] is there anyway i can know through some code that some process is suspended or not === praveen__ is now known as shadow_fax === _nightwish is now known as nightwish === nijaba` is now known as nijaba === JanC_ is now known as JanC [14:08] question: is it possible to use bootchart without an initrd? do you just add a script at S01? [14:09] and, on a different issue, isn't the room topic a bit old? [14:20] anyone? [15:07] apw: is there sufficient information in the vanilla kernel signature that kerneloops can spew an appropriate blob? [15:09] i think we send him enough, but he never responded to say whether he was happy [15:09] big surprise there :) [15:28] i'm getting 'Invalid or unsupported executable format' from grub on all jaunty's generic kernels since (including) 2.6.28-7 [15:31] ivoks: you must have HW issues. Surely lots of folks would have been howling by now. [15:31] could be... but -6 works :/ [15:31] even after reinstall of all kernel [15:31] s [15:32] have fsck'd ? [15:32] s/have/have you/ [15:32] could try that... [15:32] it's ext4 [15:33] ivoks: is it an ext4 upgrade, or was it install time formatted ? [15:33] upgrade [15:34] hmm, there were a bunch of ext4 changes that went into -7.18 [15:34] right, i've notices that [15:34] noticed [15:36] ivoks: any change you could build a kernel with all of those patches reverted? I expected them via stable updates by now, but perhaps Ted has been finding issues with them. [15:36] i could try... [15:37] ivoks: they are all labeled 'SAUCE: (revert before 2.6.28.y update) ext4:' [15:37] thanks [15:53] only 21 commits :) [16:22] is it possible to build i386 kernel on amd64? [16:24] ivoks: you have to chroot the build. [16:24] oh, right! [16:51] <_ruben> hrm .. seems i just got bitten by http://kerneltrap.org/mailarchive/linux-kernel/2008/10/16/3678594 .. on 2.6.27-11-server [16:52] <_ruben> lets see if manually applying the patch helps [16:53] <_ruben> bah .. it does fix it, yet there's more to it to get scst kmod to build against that kernel [17:10] does anyone know how to analyze a crash dump core? I've gotten past where I can copy a crash from /proc/vmcore, but am kind of stalled at the gdb point. [17:15] smb_tp: we were expecting 2.6.24-23.49 to fix the rtc related kernel oops on sparc64, right? [17:16] Ng, Was that rtc? Sorry got too many other patches through my head lately. But I think we expected it to fix the problem you had. [17:18] hmm, I just netbooted the machine and installed the newer kernel package from proposed, but it's still doing it. I think I must have done something wrong, the initial version details printed by the kernel claim it's still .48 [17:19] It definitely would have to be .49. [17:20] I guess I'll be netbooting it again and poking [17:26] rtg: so, reverting all ext4 commits since -6 did the trick [17:27] ivoks: can you file a bug with the specifics, and your results that I can pass on to Ted ? [17:27] yes, but later... i have to rush now :/ [17:28] take care [17:47] smb_tp: yeah that was my mistake, I mounted the wrong partition. It boots now :) [17:47] Cool [17:49] Keybuk: uploaded 2.6.28-8.24 with the cpu governor changes [17:54] rtg: thanks [17:55] Keybuk: maybe you can teach me how to analyze a vmcore ? I can't seem to get the right info for gdb. [17:57] you have the linux-kernel-debug package? [17:57] Keybuk: not yet, just kexec-tools [17:57] ah, you need the -debug thingy [17:58] and apt-get install crash [17:58] which is a bit like gdb [17:58] that's what I've used in the past, anyway [17:58] Keybuk: thats not a Jaunty package, is it? [17:59] crash? should be [17:59] it's even in main [17:59] I meant linux-kernel-debug [17:59] oh, no, that's in ddebs.ubuntu.com [17:59] http://magazine.redhat.com/2007/08/15/a-quick-overview-of-linux-kernel-crash-dump-analysis/ [17:59] ^ that's a pretty good guide from a RH pov [17:59] all of this is a bit byzantine. [18:00] it's the _kernel_ ;) [18:00] some chickens have to be sacrificed [18:00] ok, I'll grind through that. [18:05] cool [18:05] hwclock changes get us to the end of rcS in 9s [21:10] is kernel team also responsible for packaging the kernel? [21:15] maco: yes [21:15] pgraner: bug 272885 is worth looking then [21:15] Malone bug 272885 in linux-meta "linux-image package must depend on package grub" [Undecided,New] https://launchpad.net/bugs/272885 [21:15] the postinst scripts in the kernel try to update grub, but if you're not using grub, it's a problem [21:16] it recommends, but recommends don't *have* to be fulfilled [21:17] rtg: since you the local pkg guru, what do you think? [21:22] maco: remove/comment-out postinst_hook and postrm_hook in /etc/kernel-img.conf [21:25] sorry, that's overly generic advice [21:25] I guess as far as that bug is concerned, bits of the last-good-boot infrastructure should not be in the "grub" package [22:34] i'd be a bit uncomfortable making grub a hard dependency, but i suppose there must be a time and place to move beyond lilo