[04:43] <praveen>  I want to know if there is some mechanism by which I can make the child not to stop when it gets a signal and it is being traced by superior
=== Nicke_ is now known as Nicke
[10:53] <tjaalton> sigh, can't boot jaunty unless I specify root=/dev/sdaX, although the UUID is correct
[11:05] <maxb> tjaalton: maybe something to do with the blkid|volid transition? I had one of my disks start showing up as a different UUID at one point in the jaunty cycle
[11:05] <tjaalton> maxb: how to fix it?
[11:06] <tjaalton> the previous time I booted this was three weeks ago
[11:06] <maxb> well, first see if /dev/disk/by-uuid/ is populated the way you think it should be
[11:07] <tjaalton> looks ok
[11:07] <maxb> hm. In that case the problem might be something entirely different
[11:09] <tjaalton> I can see the five partitions there
[11:11] <tjaalton> and the UUID's match the ones on the fstab
[11:14] <tjaalton> the machine had crashed though, and has ext4 on /
[12:26] <soren> tjaalton: How does it fail?
[12:27] <tjaalton> soren: kernel panic
[12:28] <soren> tjaalton: -v
[12:28] <tjaalton> soren: more details? fails to mount root, and then lists the partitions that are available
[12:29] <tjaalton> and then panics
[12:29] <soren> ...yet the UUID in question is in /dev/disk/by-uuid in the initramfs?
[12:30] <tjaalton> hmm, I'll extract it and check
[12:30] <soren> Er. No, that's not how it works.
[12:30] <tjaalton> oh right
[12:30] <soren> udev runs in the initramfs and creates them on boot.
[12:30] <tjaalton> yes
[12:30] <soren> Can you check in there?
[12:31] <soren> Pass break=bottom on the kernel command line (along with root=/dev/sdaX).
[12:31] <tjaalton> ok, will do
[12:42] <tjaalton> huh, break=bottom doesn't seem to work
[12:45] <tjaalton> it boots directly up
[12:46] <soren> Are you sure you spelled it correctly?
[12:46] <tjaalton> deckard ~ # cat /proc/cmdline
[12:46] <tjaalton> root=/dev/sda8 ro break=bottom
[12:46] <tjaalton> there :)
[12:46] <soren> Yeah, that's quite convincing. :)
[12:47] <soren> Try break=mount instead.
[12:47] <tjaalton> ok..
[12:49] <tjaalton> nah, same thing
[12:57] <tjaalton> oh well, I'll reinstall this soon anyway
[13:01] <soren> tjaalton: Seriously? I doesn't break into the initramfs?
[13:02] <tjaalton> soren: nope
[13:05] <tjaalton> a fresh install does though
[13:05] <tjaalton> so I wouldn't worry too much
[13:06] <tjaalton> the buggy one has been installed in January
=== JayFo is now known as JFo
[14:45] <rtg> apw: can you punch the button for mainline build for 2.6.30-rc3 ?
[14:45] <apw> rtg it is occuring in the background right now ...
[14:46] <rtg> thanks
=== mdz_ is now known as mdz
[16:50] <rtg> ogasawara: I disabled Intel KMS for Karmic until user space catches up. It seems to work well with Jaunty user space if you wanted to mess with it on your Inspiron 1420.
[16:50] <ogasawara> rtg: ok cool
[16:57] <amitk> rtg: does enabling it kill the desktop?
[16:57] <rtg> amitk: absolutely.
[16:57] <amitk> rtg: how does it work with Jaunty then?
[16:58] <rtg> amitk: I'm using it on my Inspiron 1420. so far, so good. It actually fixes an SDHC issue with a 16GB mmc card
[16:59] <rtg> now if I could just figure out why mmc works
[16:59] <amitk> rtg: aah. nevermind. I reparsed your above statement - the Karmic kernel works with Jaunty, not KMS
[16:59] <rtg> correct. KMS is borked until the X drivers catch up
[18:05] <rtg> apw: do your mainline builds enable staging? (they should if they don't already)
[18:05] <apw> rtg hrm ... will check ... yes they should as we have no ubuntu/*
[18:06] <rtg> apw: thanks
[18:46] <Kano> rtg: there is no =n in the .config, only a # CONFIG... is not set
[18:47] <rtg> Kano: I know, it ends up being the same when oldconfig gets run during the prepare phase. I'll fix it one of these days
[18:51] <mdz> apw: [1908259.182020] TCP(wget:1570): Application bug, race in MSG_PEEK.
=== mkrufky is now known as Guest71612
=== mkrufky1 is now known as mkrufky
[23:45] <jbarnes> just curious, will the I/O latency patchset make it into jaunty or a jaunty update?