[01:46] <zul> heylo
[03:36] <childe> Hi, do I need a debug kernel to use addr2line?
[04:04] <childe> Where can I get a debug kernel to use with addr2line?
[02:48] <zul> heylo
[03:07] <mjg59> BenC: Any chance you could pick up the patches that dwmw2 has been posting to the bcm43xx mailing list?
[04:39] <Keybuk> BenC, mjg59, Mithrandir, etc.: just had a thought;  ProbeForRootFilesystem won't work with lvm/md/evms/etc.
[04:39] <mjg59> Keybuk: Mm?
[04:40] <Keybuk> no /dev/disk/by-uuid for those
[04:41] <fabbione> great thinking :)
[04:41] <fabbione> same as i had when we discussed by-uuid at UBZ :P
[04:41] <mjg59> Keybuk: Don't lvm and md and uuids on the partitions?
[04:42] <Keybuk> mjg59: we'd end up mounting the actual partition, not the volume group
[04:43] <mjg59> Keybuk: ?
[04:43] <mjg59> I mean, don't they have uuids to signify which disks are parts of which sets?
[04:43] <Keybuk> no idea
[04:44] <mjg59> Which is how the old autostart stuff worked
[04:44] <Keybuk> none of them are new-world-order-compliant (they make their own device nodes)
[04:44] <mjg59> Sorry, I'm (again) not seeing what awkwardness this leads to
[04:44] <Keybuk> well, they only exist as /dev/dm/blahblahblah
[04:45] <Keybuk> no /dev/disk/by-uuid/* for it
[04:45] <mjg59> Oh! You mean the kernel is just being shit?
[04:45] <Keybuk> so it's a whole class of filesystem we can't do mount-by-uuid for
[04:45] <Keybuk> right
[04:45] <mjg59> Rather than there being any fundamental problem. Right, ok.
[04:45] <Keybuk> yeah, it doesn't block uuid for anything else
[04:45] <mjg59> But the aim of having uuids for fs mounting is only because there's the potential for the device nodes to change, which isn't true for lvm and so on
[04:46] <Keybuk> I have lvm and friends
[04:46] <Keybuk> hate
[04:46] <Keybuk> not have
[04:46] <Keybuk> H A T E
[04:46] <Keybuk> I wish to rupture their collective colons with my engorged genetalia
[04:46] <fabbione> Keybuk: get them right.. we are going to have a lot of -server installs on raid/lvm :)
[04:47] <Keybuk> fabbione: I've so far avoided touching them at all
[04:47] <Keybuk> which in theory means they have a better chance of working than anything I do touch <g>
[04:47] <fabbione> Keybuk: i know.. i mean.. don't break more than it is now ;)
[04:47] <Keybuk> I think it broke because of the mods made to initramfs this morning post the ide-generic discussion
[04:47] <Keybuk> I made the "wait" critical path for everything
[04:48] <Keybuk> rather than just definitely-scsi-subsystem stuff
[04:48] <Keybuk> so suddenly we waited for /dev/device-mapper or /dev/dm/ or whatever to turn up ... before we ran lvm, evms, etc.
[04:48] <Keybuk> I've moved the wait to local-top so it comes after those now
[04:49] <fabbione> Keybuk: ok.. it's installing right now the ubuntu21
[04:49] <fabbione> from people..
[04:51] <fabbione> Keybuk: rebooting right now
[04:53] <Keybuk> AWOOOOOOOOOOOOOOOOGHA!
[04:57] <fabbione> Keybuk: it's still waiting
[04:57] <fabbione> Begin: Mounting root file system... ...
[04:57] <fabbione> Begin: Running /scripts/local-top ...
[04:57] <fabbione> Begin: Waiting for root file system... ...
[04:57] <Keybuk> hmm
[04:58] <Keybuk> that's odd
[05:05] <Keybuk> it fiiixed it for hunger
[05:05] <Keybuk> console me up, I guess
[05:06] <fabbione> Keybuk: sure.. just a minute
[05:06] <fabbione> i want to get my snack first
[05:06] <Keybuk> I think I'll probably just put that while loop into initramfs itself
[05:07] <Keybuk> because it is the sux0r
[07:07] <Mithrandir> BenC: do you have a useful way to track down why a kernel fails to boot without acpi=off?
[10:58] <Ju> Hi all !
[11:00] <Ju> I'm on dapper and uname -v gives me : #1 SMP PREEMPT  I didn't ask for a smp enabled kernel, linux-image-686 only here (is it the good place for this question ?)
[11:01] <mjg59> Ju: That's fine
[11:01] <mjg59> On a single CPU system, the SMP instructions will be rewritten
[11:02] <Ju> there won't be any loss of performance, even small ? (for my personnal info)
[11:02] <mjg59> Nothing that can be measured, no
[11:03] <Ju> so package x and x-smp will merge ?
[11:04] <mjg59> Yes
[11:05] <Ju> ok great, thanks for the info