[12:02] <Keybuk> interesting
[12:02] <Keybuk> do you have a /proc/ide ?
[12:02] <Nafallo> yes, with "drivers ide0 hda ide1 hdc" in it
[12:02] <Keybuk> *blink*
[12:03] <Nafallo> agreed :-P
[12:04] <Keybuk> so you have /proc/ide/hda but not /sys/block/hda ?
[12:04] <Keybuk> how about /sys/block/hdc ?
[12:04] <Nafallo> /sys/block has only ram[0-15] 
[12:05] <Keybuk> right
[12:05] <Keybuk> cd /sys/devices/*/*/ide0
[12:05] <Keybuk> pwd
[12:05] <Keybuk> what does that say?
[12:07] <Nafallo> cd: 10: can't cd to /sys/devices/*/*/ide0
[12:07] <Keybuk> sweet
[12:07] <Keybuk> uh
[12:07] <Keybuk> find /sys -name ide0
[12:07] <Keybuk> I guess you don't have find though
[12:08] <Nafallo> indeed :-)
[12:08] <Keybuk> look for /sys/devices/*/ide0 */*/ide0 */*/*/ide0 etc.
[12:08] <Nafallo> (don't have it)
[12:08] <Nafallo> /sys/devices/ide0
[12:09] <Keybuk> top-level like that?!
[12:09] <Nafallo> yepp :-)
[12:09] <Keybuk> cd into that
[12:09] <Keybuk> and do an ls for me
[12:09] <Nafallo> uevent power 0.0
[12:10] <Keybuk> ok ls -l 0.0/bus
[12:11] <Nafallo> lrwxrwxrwx  1 0  0  0 0.0/bus -> ../../../bus/ide
[12:11] <Keybuk> ls 0.0
[12:11] <Nafallo> uevent power bus
[12:11] <Keybuk> ok, try echo "" > /sys/devices/ide0/uevent
[12:12] <Kamion> (why do you always echo "" rather than plain echo anyway? :-))
[12:12] <Keybuk> (or udevplug /sys/devices/ide0/uevent)
[12:12] <Keybuk> Kamion: dunno
[12:12] <Keybuk> udevplug /sys/devices/ide0 I mean
[12:12] <Keybuk> but anyway
[12:12] <Keybuk> WRITE TO THAT FILE

[12:13] <Nafallo> I think /dev/ttya[0-2]  came out of that.
[12:13] <Keybuk> ksdgjs9gu8281
[12:13] <Nafallo> or rather, they are the last ones ;-)
[12:13] <Keybuk> heh
[12:14] <Keybuk> you still don't have /sys/block/hda ?
[12:14] <Nafallo> nope
[12:14] <Nafallo> :-P
[12:14] <Keybuk> try udevplug /sys/bus/ide/0.0
[12:14] <Nafallo> no change
[12:15] <Keybuk> meh
[12:15] <Keybuk> well, you haven't got an IDE controller
[12:15] <Keybuk> apparently
[12:15] <Nafallo> I can prove I have it by modprobe ide-disk ;-)
[12:15] <Nafallo> and so can ogra on his beauty ;-)
[12:16] <Keybuk> what kind of machine do you and ogra have in common?
[12:16] <Nafallo> ogra: amd64, no?
[12:16] <Nafallo> amd64 laptop here
[12:16] <Keybuk> SATA ?
[12:16] <Nafallo> http://www.magicalforest.se/darkelf
[12:16] <Nafallo> nope, PATA-100
[12:16] <Keybuk> ok
[12:17] <Keybuk> try udevplug -Bpci
[12:17] <Keybuk> see if that makes /sys/block/hda
[12:17] <Nafallo> nope
[12:17] <Keybuk> udevplug
[12:17] <Keybuk> (without any arguments) ?
[12:18] <Nafallo> udevd-event[17175] : run_program: exec of program `/sbin/grepmap` failed
[12:18] <Nafallo> hence why I said that was missing :-P
[12:19] <Keybuk> yeah, that's just an annoying bitch I'm going to get rid of at some point
[12:19] <Nafallo> :-)
[12:19] <Keybuk> any /sys/block/hda though?
[12:19] <Nafallo> nope :-P
[12:19] <Keybuk> ok
[12:19] <Keybuk> well that means you have nothing on your system that claims to be an IDE controller
[12:19] <Keybuk> iz kernel bug
[12:20] <Keybuk> is ide-generic loaded?
[12:20] <Nafallo> where can I check? :-)
[12:20] <Nafallo> lsmod not found :-P
[12:20] <Keybuk> grep generic /proc/modules
[12:21] <Nafallo> ide-generic and ide-core is loaded, yes :-)
[12:22] <Nafallo> fwiw: ACPI registers the ide-bus in init-premount.
[12:22] <Nafallo> ide-disk then finds hda
[12:23] <Keybuk> ACPI?
[12:23] <Nafallo> yes
[12:23] <Keybuk> why is that "registering" the disk?
[12:23] <Keybuk> that just loads fan and thermal
[12:23] <Nafallo> ...]  ACPI: bus type ide registered
[12:24] <Keybuk> you have nothing that says you need to load ide-disk
[12:25] <Keybuk> ie. the kernel hasn't found any ide devices
[12:25] <Keybuk> but it claims to have, as there's things in /proc/ide
[12:25] <Keybuk> which driver is it?
[12:26] <Keybuk> (it'll be one of the things hanging on to ide-core)
[12:26] <Nafallo> via82cxxx is memory provides
[12:26] <Keybuk> is that loaded?
[12:27] <Nafallo> nope
[12:27] <Keybuk> ah, interesting
[12:27] <Keybuk> modprobe -r ide-generic
[12:27] <Keybuk> then modprobe via82cxxx
[12:27] <Keybuk> then modprobe ide-generic again
[12:28] <Nafallo> yes? :-)
[12:28] <Keybuk> did that do anything?
[12:29] <Nafallo> said averything IDE was brought up (the usual kernelmessages)
[12:29] <Keybuk> did you get a /dev/hda ?
[12:29] <Nafallo> but no /dev/hda* or anything :-P
[12:29] <Keybuk> /sys/block/hda ?
[12:29] <Nafallo> nope
[12:29] <Keybuk> hmm
[12:29] <Keybuk> it could be buggered up by loading ide-generic first
[12:30] <Keybuk> that does evil things to the kernel
[12:30] <Keybuk> but you got a lot of the IDE things by loading the via82cxxx module?
[12:31] <Nafallo> not lots, that ACPI registered the bus..
[12:31] <Nafallo> if I load ide-generic I get lots
[12:31] <Keybuk> right
[12:31] <Keybuk> ok
[12:31] <Keybuk> grep 1106 /sys/bus/pci/devices/*/vendor
[12:32] <Nafallo> 12 lines :-)
[12:32] <Keybuk> right
[12:33] <Keybuk> look at the /device files for each of them
[12:33] <Keybuk> they'll each have 4-digit numbers/letters
[12:33] <Keybuk> could you type them each here
[12:34] <Nafallo> shouldn't I be able to find out which one it is by grepping? :-)
[12:35] <Keybuk> no, clearly you have one that isn't registered
[12:35] <Keybuk> so I want the ids so I can google for them <g>
[12:35] <Nafallo> hehe
[12:37] <Nafallo> 3177
[12:37] <Nafallo> 0571
[12:38] <Nafallo> 3059
[12:38] <Nafallo> 3068
[12:38] <Nafallo> any hit yet? :-)
[12:38] <Keybuk> carry on
[12:39] <Nafallo> 3065
[12:39] <Nafallo> 3044
[12:40] <Nafallo> b188
[12:40] <Nafallo> 3188
[12:40] <Nafallo> 3038
[12:42] <Nafallo> same on all 00:10.*, so USB I guess
[12:42] <Keybuk> ok
[12:42] <Keybuk> could you note down the sysfs path to the one that's 0571
[12:42] <Keybuk> then once done, reboot and put break=top onto the kernel command-line
[12:42] <Keybuk> so you're given a shell in the initramfs, rather than it failing
[12:43] <Nafallo> /sys/bus/pci/devices/0000:00:11.1/device
[12:43] <Keybuk> k
[12:43] <Keybuk> so reboot, with break=top, so we're in a fresh shell with no modules loaded
[12:44] <Nafallo> ey! you are reading my notes-to-self :-P
[12:44] <Keybuk> hmm?
[12:44] <Nafallo> oki, I'm there.
[12:44] <Keybuk> right
[12:44] <Nafallo> you told me to take a note ;-)
[12:45] <Keybuk> if you're on a laptop ... modprobe fan and modprobe thermal now <g>
[12:45] <Nafallo> hehe, done
[12:45] <Keybuk> run UDEV_LOG=info /sbin/udevd --daemon
[12:46] <Nafallo> done
[12:46] <Keybuk> ok, now can you verify a few things for me, if not true, can you say what you see
[12:46] <Keybuk> /sys/bus/ide/devices is either empty or non-existant
[12:46] <Keybuk> grep via82cxxx /proc/modules shows nothing
[12:47] <Keybuk> /sys/bus/pci/devices/0000:00:11.1/vendor is 1106
[12:47] <Keybuk> /sys/bus/pci/devices/0000:00:11.1/device is 0571
[12:48] <Nafallo> all true
[12:48] <Keybuk> /sys/bus/pci/devices/0000:00:11.1/class is 0x010000
[12:48] <Nafallo> not true
[12:48] <Keybuk> what is it?
[12:48] <Nafallo> 01018a
[12:48] <Keybuk> with or without an 0x on the front?
[12:49] <Nafallo> 0x01018a :-)
[12:49] <Keybuk> right, that's quite important :p
[12:49] <Nafallo> hehe, oki :-). all of them has that if not said otherwise ,-)
[12:49] <Keybuk> /sys/bus/pci/devices/0000:00:11.1/modalias should begin pci:v00001106d00000571sd... yes?
[12:49] <Keybuk> yeah, that's ok, just checking on that one in particular
[12:50] <Keybuk> also does it end bc01sc01i8a ?
[12:50] <Nafallo> not sd, sv
[12:51] <Keybuk> right, sorry, typo
[12:51] <Nafallo> sd00002032bc01sc01i8a
[12:51] <Keybuk> cool
[12:51] <Keybuk> now, /sys/block/hda should not exist
[12:51] <Keybuk> also /sys/devices/ide0 should not exist
[12:51] <Keybuk> and /proc/ide should not exist
[12:51] <Keybuk> are all those true?
[12:52] <Nafallo> yes indeed
[12:52] <Keybuk> right
[12:52] <Keybuk> udevplug -Bpci -Iclass=0x010[01] *
[12:52] <Keybuk> that should do a bunch of stuff on your screen, any of it interesting?
[12:53] <Nafallo> it didn't :-P
[12:53] <Keybuk> did nothing?
[12:53] <Nafallo> did nothing...
[12:53] <Keybuk> not even a grepmap bitch?
[12:54] <Nafallo> not even the bitch :-)
[12:54] <Keybuk> grep via82cxxx /proc/modules still shows nothing ?
[12:54] <Nafallo> cat /proc/modules: unix thermal processor fan
[12:55] <Keybuk> right
[12:55] <Keybuk> udevd is running?  (ps ax)
[12:55] <Nafallo> yepp
[12:55] <Keybuk> udevplug /bus/pci/devices/0000:00:11.1
[12:55] <Keybuk> does that do anything?
[12:56] <Nafallo> you forgot /sys, right?
[12:56] <Keybuk> doesn't matter, is optional
[12:57] <Nafallo> did nothing
[12:57] <Keybuk> how about just
[12:57] <Keybuk> echo > /sys/bus/pci/devices/0000:00:11.1/uevent
[12:58] <Nafallo> udevd-event output :-)
[12:58] <Keybuk> any of it interesting?
[12:58] <infinity> Keybuk ; Dude.  You updated linux-meta while powerpc was still fucked?
[12:59] <Keybuk> infinity: yes, mdz said to :)
[12:59] <Nafallo> lol
[12:59] <Nafallo> /sbin/modprobe -Q pci:v....
[12:59] <Keybuk> Nafallo: see, now that is interesting
[12:59] <Keybuk> do you now have any of /sys/block/hda, /sys/devices/ide0, /proc/ide/hda/media, /dev/hda ?
[01:00] <Nafallo> /sbin/modprobe (stderr) and the usage note :-P
[01:00] <Keybuk> huh why usage note?
[01:00] <Nafallo> is the line after that one...
[01:00] <Nafallo> so status 1 on modprobe...
[01:00] <Keybuk> uh
[01:00] <Keybuk> /sbin/modprobe -Q fan
[01:00] <Keybuk> ^ what does that do?
[01:01] <infinity> Keybuk : Ahh, yeah, just read backscroll.
[01:01] <Nafallo> usage message..
[01:01] <Nafallo> -q maybe?
[01:01] <Keybuk> no, definitely -Q
[01:01] <Keybuk> so, could you do something for me
[01:01] <Keybuk> modprobe ide-disk
[01:01] <Keybuk> mount /dev/hda1 (or whatever your root/var is) /root
[01:02] <Nafallo> ls /dev still shows console and null only
[01:03] <Keybuk> *giggle*
[01:03] <Keybuk> OH I SEE THE PROBLEM
[01:03] <Keybuk> module-init-tools FTBFS
[01:03] <Nafallo> eeh? :-P
[01:04] <Keybuk> bloody patch systems
[01:05] <Nafallo> ...and out
[01:06] <Keybuk> ok
[01:06] <Keybuk> soooo, here's how to boot your machine
[01:06] <Keybuk> boot with break=premount
[01:07] <Keybuk> . conf/initramfs.conf
[01:07] <Keybuk> . scripts/functions
[01:07] <Keybuk> scripts/init-premount/acpid
[01:07] <Keybuk> udevd --daemon
[01:07] <Keybuk> udevplug /class/mem /class/misc /class/tty /class/vc /block
[01:08] <Keybuk> modprobe via82cxxx
[01:08] <Keybuk> modprobe ide-disk
[01:08] <Keybuk> modprobe ide-generic
[01:08] <Keybuk> (this should get you /dev/hda*)
[01:08] <Keybuk> udevplug -W
[01:08] <Keybuk> mountroot
[01:08] <Keybuk> run_scripts scripts/init-bottom
[01:09] <Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
[01:09] <Keybuk> --
[01:09] <Nafallo> mountroot not found :-P
[01:10] <Keybuk> did you do the ". scripts/functions" bit?
[01:10] <infinity> Keybuk : Shall I fix module-init-tools while you're helping Nafallo get unfucked?
[01:10] <Keybuk> oh
[01:10] <Keybuk> sorry
[01:11] <Keybuk> . scripts/$BOOT
[01:11] <Keybuk> mountroot
[01:11] <Keybuk> infinity: already uploaded
[01:11] <infinity> Ahh, cool.
[01:13] <Nafallo> :-)
[01:13] <Nafallo> thanx :-)
[01:13] <Keybuk> booted?
[01:13] <Nafallo> yepp
[01:13] <Nafallo> and had more fun than ever on the way :-)
[01:13] <Keybuk> right
[01:13] <Keybuk> NOW BEFORE YOU GO
[01:13] <Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1-0ubuntu3_i386.deb
[01:13] <Keybuk> actually
[01:13] <Keybuk> that's the wrong arch for you isn't it <g>
[01:13] <Keybuk> uh
[01:13] <Nafallo> hehe, it is :-)
[01:14] <Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1-0ubuntu3.diff.gz
[01:14] <Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1-0ubuntu3.dsc
[01:14] <Keybuk> http://people.ubuntu.com/~scott/module-init-tools_3.2.1.orig.tar.gz
[01:14] <Keybuk> grab those three down, dpkg-source -x, dpkg-buildpackage -rfakeroot -b -uc -us, install module-init-tools
[01:15] <Keybuk> then check that "/sbin/modprobe -Q fan" does NOT give you a usage error :p
[01:15] <Nafallo> hmm, where is my network? ;-)
[01:15] <Keybuk> ifup
[01:15] <Keybuk> that's a known problem
[01:15] <Keybuk> it's in the release notes
[01:17] <Nafallo> I thought network-manager would take care of that ;-)
[01:17] <Keybuk> maybe
[01:18] <Keybuk> either way, it's on my list todo, just a few items down
[01:18] <Nafallo> just shout if you need testing :-)
[01:18] <Keybuk> let's first get you booting without error :p
[01:19] <Keybuk> got that built yet?
[01:20] <Nafallo> just wgeted and gave it to pbuilder :-)
[01:28] <Nafallo> oki, rebooting :-)
[01:30] <Nafallo> hmm, same error...
[01:30] <Nafallo> I don't have to run update-initramfs manually or something?
[01:31] <Keybuk> I actually just meant that you should run /sbin/modprobe before rebooting <g>
[01:31] <Keybuk> but yes, you would need to run update-initramfs
[01:35] <Nafallo> I thought packages would do that these days ;-)
[01:35] <Nafallo> anyway, booted via the long command method again ;-)
[01:36] <Nafallo> no usage error :-)
[01:37] <Nafallo> sudo update-initramfs -u and then reboot again :-)
[01:39] <Nafallo> wow! "Mounting root file system     ok"
[01:39] <Nafallo> :-)
[01:39] <Nafallo> thanx Keybuk! I'll post fresh bootcharts shortly :-)
[01:40] <Nafallo> even network works now ;-)
[01:41] <Nafallo> yay! my battery works :-)
[01:44] <Nafallo> http://www.magicalforest.se/~nafallo/bootchart/dapper-20051201-3.png
[07:36] <fabbione> guys can we have a FEW WORDS?
[07:37] <fabbione> infinity: this upgrade is the disaster
[07:37] <fabbione> RAID and network are gone
[07:38] <fabbione> infinity: nvidia is broken on amd64
[07:38] <fabbione> + we load some fb modules that conflicts heavily with nvidia
[07:38] <fabbione> removing the fb modules makes no good
[07:38] <fabbione> nvidia either crashes or it manages to start X but it kills console
[07:42] <fabbione> i think bootchart it's taking ages to release to console
[07:43] <fabbione> but that's not a big deal
[07:44] <fabbione> grepmap seems to be broken too
[08:09] <infinity> fabbione : Hrm.  nvidia works for me on amd64 (both legacy and current), but I tested it before the new udev and stuff when in.
[08:10] <fabbione> yes, the problem seems to be either usplash or initramfs that are loading too many fb modules
[08:10] <infinity> fabbione : I'll have to test again after I upgrade evrything, but more concrete stuff than "it doesn't work" would be helpful, I think.
[08:10] <infinity> (And I'm using usplash with vga16fb on that machine, ie: a default setup)
[08:10] <fabbione> for what i can see other than the fb modules problems, nvidia kills switching to console
[08:11] <fabbione> and it kills the machine if loading it directly without the fb modules
[08:11] <fabbione> it's kind of a mess that will need more debugging
[08:11] <infinity> Fun.  What kind of card do you have?
[08:11] <infinity> I've only been able to test on my 6800GT.
[08:11] <fabbione> 0000:00:0e.0 VGA compatible controller: nVidia Corporation NV17GL [Quadro4 200/400 NVS]  (rev a3)
[08:11] <fabbione> 0000:01:00.0 VGA compatible controller: nVidia Corporation NV25 [GeForce4 Ti 4600]  (rev a3)
[08:11] <fabbione> it has 2 cards
[08:12] <infinity> So, if you boot with "nosplash", everything's okay?...
[08:13] <infinity> Or it dies in different ways?
[08:13] <infinity> (And have you tried with -legacy?... While your cards don't technically need it, they are older, so are more likely to run afoul of bugs in the new drivers, which are being aimed at 6/7 series stuff)
[08:14] <fabbione> if i boot with nosplash the machine freezes
[08:15] <fabbione> no, i didn't try -legacy yet
[08:15] <infinity> Er,, not sure if it's "nosplash", or just removing "splash" from the command line.  Probably the latter, actually.
[08:16] <fabbione> yeah i did try the recovery mode
[08:16] <fabbione> and usplash was not loaded
[08:16] <fabbione> it might as well be a problem with the sequence in which modules are loaded
[08:16] <fabbione> because unloading fb stuff and loading nvidia works
[08:16] <fabbione> so it's kind of weird
[08:17] <infinity> Very fun.  I'll test again later tonight after a full upgrade.
[08:17] <fabbione> ok
[08:18] <infinity> I fear it may be specific to your setup, though.  So if I can't reproduce it at all, I'll whine at you to help.
[08:20] <fabbione> yeah of course
[08:20] <fabbione> i would like at least to get RAID/network back first
[08:20] <fabbione> because they are truely annoying to start manually at each boot
[08:20] <infinity> You did upgrade everything, right?
[08:21] <fabbione> yeps
[08:21] <infinity> Well, damn. :)
[08:21] <infinity> Blame keybuk.
[08:22] <fabbione> heheh
[08:22] <fabbione> infinity: do you plan a php5 upload soon?
[08:23] <fabbione> there is the libsnmp5 -> 9 transition
[08:23] <fabbione> it's the only pkg in main left
[08:23] <fabbione> i just did hplip
[08:31] <infinity> Yeah, it's happening soon for other reasons.
[08:32] <fabbione> ok
[09:36] <infinity> ARGH.
[09:36] <infinity> fabbione : <poke>
[09:42] <fabbione> ?
[09:44] <infinity> fabbione : Are you getting some nvidia-specific framebuffer module loaded?
[09:44] <infinity> fabbione : After upgrading everything and rebooting, I've noticed that something is now loading radeonfb magically for me, which is very clearly a bug.
[09:44] <infinity> If that's happening for you (but with the nv equivalent), that's the real problem.  And I'm pretty sure it's the new udev's fault.
[09:46] <fabbione> yes it is happening for me to
[09:47] <fabbione> it loads radeon and nvidia fb
[09:47] <infinity> Both?
[09:47] <infinity> You have an ATI in there too?
[09:47] <infinity> Or is it doing something even more wrong than wrong?
[09:47] <fabbione> nope
[09:47] <fabbione> no ati on this box
[09:47] <fabbione> sorry i meant riva
[09:48] <infinity> Oh, phew.
[09:48] <infinity> Kay.
[09:48] <infinity> Still very wrong, but at least that one makes sense. :)
[09:48] <fabbione> [  235.360791]  NVRM: The NVIDIA probe routine was not called for 2 device(s).
[09:48] <fabbione> [  235.360796]  NVRM: This can occur when a driver such as rivafb or rivatv was
[09:48] <fabbione> [  235.360798]  NVRM: loaded and obtained ownership of the NVIDIA device(s).
[09:48] <fabbione> [  235.360802]  NVRM: Try unloading the rivafb (and/or the rivatv) kernel module
[09:48] <fabbione> [  235.360804]  NVRM: (or reconfigure your kernel without rivafb support), then
[09:48] <fabbione> [  235.360805]  NVRM: try loading the NVIDIA kernel module again.
[09:48] <fabbione> [  235.362873]  NVRM: No NVIDIA graphics adapter probed!
[09:48] <fabbione> this one repeated several times
[09:48] <infinity> Yeahp.
[09:48] <fabbione> it clearly goes away as soon as i rmmod riva
[09:49] <infinity> I'm getting the same here with conflicts between radeonfb and fglrx.  Which, of course, shouldn't be happening, because radeonfb and rivafb shouldn't be autoloaded.
[09:49] <infinity> I'll be sure to yell at keybuk when he returns.
[09:49] <fabbione> ehehehe
[09:50] <infinity> For now, you could blacklist rivafb, but having framebuffers hot/coldplugged at all is just sick and wrong, given that most of them are biuggy as hell.
[09:51] <fabbione> i argee
[09:51] <fabbione> agree
[09:51] <fabbione> and i can wait for Keybuck to fix
[09:51] <fabbione> i am not going to reboot this machine anytime soon anyway
[09:54] <Mithrandir> Kamion: I'm going to waste a little time today trying to get our custom widget stuff upstream as well as our kbd-chooser changes.  Ok?
[11:12] <fabbione> hmmm
[11:13] <fabbione> Kamion: the pvremove -ffy solution doesn't solve all the problem :/
[11:13] <fabbione> i need to do a clean lvm removal
[11:15] <fabbione> actually
[11:15] <fabbione> no
[11:15] <fabbione> i can be WAYYYY more evil :)
[11:20] <Kamion> Mithrandir: cool, thanks
[11:21] <Kamion> fabbione: ok ...
[11:23] <Kamion> fabbione: I'm going to do a partman-auto-lvm upload to Debian in a moment; you'll need to merge that or your world will stop working
[11:24] <Kamion> fabbione: oh, uh, you've been doing lots of stuff too, hmm
[11:25] <Kamion> I guess it's not safe to upload at the moment
[11:25] <Kamion> fabbione: if you want udev stuff to keep working with the new installer world order, merge r32609 from d-i svn; if you don't care, feel free to wait :)
[11:26] <fabbione> Kamion: all the changes are the same we have in ubuntu
[11:26] <fabbione> and all tested
[11:26] <fabbione> if you want to upload pal you need to upload partman-auto too
[11:27] <fabbione> Kamion: if you are talking about the udev bits, it's no problem... i can merge them easily
[11:27] <fabbione> it's just 2 lines
[11:28] <fabbione> my head is exploding
[11:33] <pitti> Hi Keybuk
[11:33] <Keybuk> happy mailman day
[11:33] <pitti> Keybuk: I have some juicy udev bugs to talk about, when you have a minute?
[11:34] <Keybuk> sure, give me a few minutes to get my eyes open
[11:34] <pitti> and some coffee? :)
[11:37] <Keybuk> yes that too
[11:38] <Kamion> fabbione: right, it's just to call update-dev
[11:38] <Kamion> the old udevstart/udevsynthesize calls in p-a-l and elsewhere (apart from update-dev itself) will go away soon
[11:55] <Kamion> is anyone doing new linux-meta for the new ABI?
[11:55] <makx> udevsynthesize is nice for < 2.6.15
[11:56] <Kamion> makx: yes that's why they'll stay in update-dev
[11:56] <Kamion> please, I know what I'm doing :-)
[11:56] <Kamion> well, sometimes
[11:56] <makx> np was just a remark, not looked in an updeate-dev yet-
[11:57] <fabbione> Kamion: no, because we need new LRM for the new ABI
[11:58] <fabbione> oh it's in..
[11:59] <Kamion> binaries aren't in yt
[11:59] <Kamion> ah, new
[12:00] <Kamion> ok, I'll process the new binaries
[12:02] <Kamion> oh, god, no I won't, newing l-r-m gives me a vicious headache, I'll wait for elmo
[12:05] <Kamion> whoa, rebooting just after installing new udev is indeed ultra-messy
[12:05] <Keybuk> d-i reboot, or ordinary reboot?
[12:05] <Kamion> ordinary reboot
[12:05] <Kamion> the bazillion udevsend errors scrolling down the console
[12:05] <fabbione> Keybuk: check today's log for this chan
[12:06] <fabbione> i also have several issues
[12:06] <Kamion> hmm, no /dev/sda1 here ...
[12:06] <Keybuk> udevsend errors?
[12:06] <Keybuk> there's no such thing as udevsend
[12:06] <Keybuk> (it's not used)
[12:06] <fabbione> raid/network and other stuff are clearly no go
[12:06] <Kamion> my machine begs to differ
[12:07] <Kamion> I probably have udevsend in /proc/sys/kernel/hotplug
[12:07] <Kamion> s/have/had/
[12:07] <Kamion> hunger mentioned the same thing on #ubuntu-devel
[12:07] <Keybuk> that should get cleared in initramfs
[12:08] <Keybuk> unless something else is putting it back, of course
[12:08] <Kamion> it's *before* reboot
[12:09] <Kamion> as in, just upgraded from breezy-ish udev to current, then went to reboot
[12:09] <makx> did that update your initramfs?
[12:10] <Kamion> makx: yes, and it's totally irrelevant because the errors were BEFORE REBOOT so the new initramfs hadn't been started yet
[12:10] <Keybuk> oh
[12:10] <Keybuk> yeah
[12:10] <Keybuk> that'd go boom
[12:10] <Kamion> ok, anyone fancy walking me through figuring out why I'm not getting /dev/sda1 in the new initramfs? SATA
[12:11] <Keybuk> could be that no modules are being loaded
[12:11] <Kamion> udevplug puts it in
[12:11] <Keybuk> the easiest way to do it is to boot with break=mount
[12:11] <Keybuk> see if you have /dev/sda1
[12:11] <Keybuk> if not, try udevplug -Bpci
[12:11] <Keybuk> then see if you have /dev/sda1
[12:12] <makx> btw nice "break=foo" patch Keybuk. :)
[12:13] <Kamion> Keybuk: I don't even get a shell - I get "Spawning shell within the initramfs" and then a blinking cursor
[12:13] <Keybuk> huh?  weird
[12:15] <Keybuk> maybe you have to wait for usplash to die or something
[12:16] <Kamion> oh, the shell is in tty8
[12:16] <Kamion> that's helpful, not
[12:17] <Kamion> no /dev/sda1 to start with, but udevplug -Bpci creates it
[12:18] <Keybuk> ok, excellent
[12:18] <Keybuk> is there a /sys/block/sda1/device symlink?
[12:18] <Keybuk> it might be /sys/block/sda/sda1/device
[12:18] <Keybuk> or /sys/block/sda/device
[12:19] <Kamion> /sys/block/sda/device is there
[12:19] <Keybuk> ok
[12:19] <Keybuk> readlink/ls -l that and it should point to a pci device
[12:19] <Keybuk> cd into that (you can just cd /sys/block/sda/device) and pwd to make sure it's the right device
[12:19] <Keybuk> then cat vendor device class
[12:20] <Keybuk> and give me those three numbers :)
[12:20] <Kamion> /sys/devices/pci0000:00/0000:00:0f.0/host0/target0:0:0/0:0:0:0
[12:20] <Kamion> vendor says ATA, device and class are missing
[12:21] <Keybuk> oh, interesting
[12:21] <Keybuk> try in ../../..
[12:21] <Kamion> 0x1106
[12:21] <Kamion> 0x3149
[12:21] <Kamion> 0x010400
[12:22] <Keybuk> aha!
[12:22] <Keybuk> PCI_CLASS_STORAGE_RAID :)
[12:22] <Kamion> le huh?
[12:22] <Kamion> nobody told me it was RAID :)
[12:22] <Keybuk> not PCI_CLASS_STORAGE_SCSI
[12:22] <Keybuk> rightio
[12:23] <Keybuk> can you file a bug saying something like "load all storage controllers in initramfs, not just IDE/SCSI ones"
[12:23] <Kamion> ok
[12:23] <Keybuk> you can boot that machine now with:
[12:23] <Keybuk> . conf/initramfs.conf
[12:23] <Keybuk> . scripts/functions
[12:23] <Keybuk> . scripts/$BOOT
[12:23] <Keybuk> mountroot
[12:23] <Keybuk> run_scripts scripts/init-bottom
[12:24] <Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
[12:26] <Kamion> #20339
[12:26] <Kamion> boots fine now, thanks
[12:38] <pitti> l
[12:54] <fabbione> Kamion: new p-a-l uploaded
[12:54] <fabbione> with the udev crack changed
[12:56] <Kamion> ta
[01:01] <infinity> Keybuk : Hey, has anyone yelled at you about framebuffers, yet?
[01:02] <infinity> Keybuk : I can only assume this is the new udev at fault, but it appears to be hot/cold-plugging framebuffers, based on installed hardware, so all ATI users get radeonfb loaded, nv users get rivafb, etc.  THis is pretty horribly broken.
[01:02] <infinity> Keybuk : Since most of these framebuffers are buggy, break suspend/resume, and break their X driver counterparts.
[01:04] <Keybuk> it's in the release notes :)
[01:04] <Keybuk> (which I've yet to send, but still)
[01:04] <Keybuk> yes, I know framebuffer devices are loaded
[01:04] <Keybuk> I also have a bug assigned to me saying we should load framebuffer devices
[01:04] <Keybuk> I'm also aware that we might not want to
[01:05] <Keybuk> basically they need blacklisting
[01:05] <fabbione> Keybuk: you are perfectly convinced you don't want to load them
[01:05] <Keybuk> and I'm not sure the elegant way to do that
[01:05] <fabbione> it breaks MY workstation
[01:05] <fabbione> badly
[01:05] <fabbione> Keybuk: or i will have to make you an offer you can't refuse
[01:06] <infinity> Keybuk : Was the bug filed by anyone with clue, or just someone who wants whizbang features?
[01:07] <infinity> Keybuk : Bottom line is that most framebuffers break just about everything else we do.
[01:07] <Keybuk> *nods*
[01:07] <Keybuk> soo... how do we blacklist them?
[01:07] <makx> fabbione: hch needs a test for sbus sysfs debian -> #341522
[01:07] <Keybuk> do we maintain a byhand list of framebuffer drivers?
[01:07] <infinity> Keybuk : why were they not being loaded before, but are now?  That might be a good place to start.
[01:07] <Keybuk> there was a skip in the old hotplug shell code
[01:08] <infinity> And can we not replicate that behaviour on the new world order?
[01:09] <Keybuk> I'd like to do it with a blacklist file now
[01:09] <fabbione> makx: i don't run debian on my sparc.
[01:09] <fabbione> can't test
[01:09] <infinity> But we blacklist based on module name, not subsystem.  Much more of a pain in the ass to maintain.
[01:09] <makx> fabbione: he'll send you a kernel patch
[01:09] <infinity> Or can we blacklist in more clever ways?
[01:10] <infinity> Kamion : I realise you don't want to touch lrm NEW cause LRM is icky and makes your head hurt, but can you NEW the ia64 kernel binaries, so LRM can build there? :)
[01:10] <fabbione> makx: still.. can't test.. my sparc is buildd.. not a test machine
[01:11] <Keybuk> rumout has it that we can do something like:
[01:11] <fabbione> makx: plus he perfectly knows how to find me :)
[01:11] <makx> fabbione: ok hehe trave11er will do
[01:11] <Keybuk> install pci:v*d*sv*sd*bc03*sc*i* /bin/true
[01:11] <Kamion> infinity: (it's specifically icky because lisa can't handle l-r-m directly due to the d-i bits.)
[01:11] <Keybuk> that's pretty ugly though
[01:12] <Keybuk> we could also do that with SUBSYSTEM=="pci", SYSFS{class}=="0x03*", GOTO="modprobe_end"
[01:12] <infinity> Keybuk : I'd prefer to avoid line nois ein config files.
[01:12] <infinity> Keybuk : Though, something that ugly is unlikely to be touched by users, which may be a win..
[01:12] <Kamion> infinity: doing now
[01:12] <Keybuk> another option is to generate /etc/modprobe.d/display_class automatically in kernel postinst
[01:12] <fabbione> UH UH
[01:12] <fabbione> go udev!
[01:13] <fabbione> no actually.. that would be initramfs too
[01:14] <infinity> Keybuk : Is there any reason to not just patch things to skip that particular class, other than the off chance that some user, somewhere, might really want to coldplug his framebuffers without using /etc/modules?
[01:14] <Keybuk> infinity: patch what? :)
[01:15] <infinity> Whatever enumerates incoming *plug events and decides to call modprobe?
[01:15] <infinity> I'm not the one who packaged this, I don't pretend to know the code. :)
[01:15] <Keybuk> well, the kernel generates uevents
[01:15] <Keybuk> we could patch the kernel to not generate events for display devices
[01:15] <infinity> Right, then?
[01:15] <infinity> What catches the events?... udev?
[01:16] <Keybuk> but it's slightly less intrusive to just not build the framebuffer devices in the first place
[01:16] <infinity> And then udev calls modprobe if it thinks it should?
[01:16] <Keybuk> yes, udev catches the events, looks them up in sysfs and processes it
[01:16] <Keybuk> we could add a udev rule to skip modprobe for display devices
[01:16] <infinity> Right, so udev should be the one skipping the events, if it knows the device class.
[01:16] <Keybuk> udev calls modprobe
[01:16] <Keybuk> with a device alias
[01:16] <Keybuk> modprobe can blacklist devices from matching a particular alias
[01:17] <Keybuk> (like we do for things like eepro100 and stuff)
[01:17] <Kamion> infinity: Accepted 1 package set, 146 MB.
[01:17] <infinity> Yeah, but that percludes someone calling modprobe manually.
[01:17] <Keybuk> no, it doesn't
[01:17] <infinity> We just don't want udev automagically doing it, we don't want to stop users from doing it.
[01:17] <Keybuk> modprobe only applies it's blacklists to alias expansion
[01:17] <Keybuk> modprobe eepro100  still works
[01:17] <Kamion> (unless you use -b, right?)
[01:17] <Keybuk> modprobe pci:blahblahforaneepro100 is what gets blacklisted
[01:17] <Keybuk> right
[01:18] <Keybuk> modprobe -b eepro100 is "load eepro100 only if it's not blacklisted"
[01:18] <Keybuk> ...
[01:18] <Kamion> incidentally, please document -b in the man page, kthxbye :)
[01:18] <infinity> Well, I leave it in your hand to implement where/how you think works best.
[01:18] <Keybuk> I'd rather we did this at the modprobe level, because it's the least surprising way
[01:18] <Keybuk> and it's consistent with other things where we've decided not to load modules
[01:18] <infinity> I just want it to work, and I don't want anything that requires maintaining manual lists.
[01:18] <Keybuk> right
[01:19] <infinity> (Or something so user-obvious "Oh, look this blacklists framebuffers, I don't want that!" that users will delete it, not know how to get it back, and file tons of bugs cause X broke)
[01:19] <Keybuk> do you have anything against a list updated in a postinst?
[01:19] <infinity> Yes, I'm evil.
[01:19] <Keybuk> infinity: if users shoot themselves in the foot, they will shoot themselves
[01:19] <Keybuk> either way this will be in a conffile
[01:19] <infinity> I don't think hotplugging framebuffers is ever "right", so I'd really just not allow it.
[01:20] <infinity> Kamion : Thanks, BTW.
[01:20] <Kamion> np
[01:22] <Keybuk> of course, it's impossible to accurately identify framebuffer drivers *shrug*
[01:23] <infinity> Then how did hotplug manage?
[01:23] <infinity> Rough guessing that was mostly true?
[01:24] <Keybuk> hotplug did it by device
[01:24] <infinity> All video devices?
[01:25] <infinity> That would work for us, since the only other things that vaguely relate to video devices are slave drivers to X drivers, which load (or are supposed to) when X loads.
[01:25] <Keybuk> right, that was always the drawback
[01:25] <Keybuk> there were various hotplug bugs where it didn't load some other driver
[01:25] <Keybuk> like capture cards, etc.
[01:25] <Keybuk> all-in-one cards didn't work at all without manual driver loading
[01:25] <Kamion> Keybuk: udev-udeb being hard to type> I feel your pain
[01:26] <Kamion> I can only type "udev" accurately one time in three
[01:27] <Keybuk> the udeb was missing lots of files because they were in debian/udeb-udev and debian/udev-udev and friends
[01:29] <Kamion> heh
[01:35] <ogra> hi
[01:36] <Keybuk> ok
[01:36] <Keybuk> so let's first get your system to a useful point to play
[01:36] <Keybuk> your problem is that "your root filesystem is on a network device, and no network driver is loaded", is that correct?
[01:36] <ogra> i tried to replace the line that was there, as well as just ading your line
[01:36] <ogra> yup
[01:36] <Keybuk> ok, good
[01:36] <Keybuk> put that script back how it was, just the -Bpci -Iclass=0x01* line
[01:36] <Keybuk> update-initramfs
[01:36] <ogra> it loads the same set of modules in both cases
[01:37] <Keybuk> then reboot, and add break=mount to the kernel command-line (remove splash for sanity)
[01:37] <jbailey> Keybuk: Is this no-nic-at-startup troubleshooting, or a specific LTSP case?
[01:38] <Kamion> ok, well, the installer boots with 2.6.15-6, sort of
[01:38] <jbailey> I have to ifup at startup, but I think you said that's expected.
[01:38] <Keybuk> jbailey: we forgot about initramfs probing network modulesentirely when we wrote udev-roadmap
[01:38] <Kamion> something's wrong with framebuffer bringup though
[01:38] <ogra> jbailey, it is ltsp... but might also affect others
[01:38] <Keybuk> Kamion: "wrong with" ?  ...  you mean that framebuffer drivers are brought up?
[01:38] <Keybuk> ogra: are we at a "Spawning shell in the initramfs" prompt yet?
[01:39] <Kamion> Keybuk: er no, the installer relies on a framebuffer ...
[01:39] <jbailey> Keybuk: Mmm, yeah.  Althouhg it seems solvable in that the nfs initramfs class can have the nic probing and the klibc dhcp client call can be a udev rule at that point.
[01:39] <Keybuk> Kamion: oh, now that makes things more interesting wrt blacklists
[01:39] <jbailey> Keybuk: So I don't think it's unsolvable.
[01:39] <ogra> Keybuk, wait, takes a second ...
[01:39] <Kamion> Keybuk: nope, the installer already modprobes them itself
[01:39] <Keybuk> oh ok
[01:39] <Kamion> Keybuk: just leave it to do its job and it will be fine :)
[01:39] <Kamion> (well, ish)
[01:39] <jbailey> Keybuk: Then we just do the same event wait for the root filesystem to appear.
[01:40] <infinity> Kamion : Are you sure you're not getting fb conflicts?
[01:40] <ogra> Keybuk, ok, there
[01:40] <Keybuk> ogra: good
[01:40] <Keybuk> now what network driver are you looking for?
[01:40] <ogra> note that i have to regenrate the tftpboot stuff afterwards
[01:40] <Kamion> infinity: pretty sure, yes. symptoms are funny squares in localechooser rather than UTF-8 characters; I'm investigating
[01:40] <infinity> Kamion : I get vga16fb/vesafb (whichever one usplash decides I wanted) loaded, then udev goes and loads a second later.
[01:40] <ogra> 8139too
[01:40] <Kamion> infinity: no usplash in the installer
[01:40] <Keybuk> ok, grep 8139 /proc/modules and check it's not in there
[01:40] <ogra> but in fact all pci drivers
[01:41] <infinity> Kamion : Right, but similar idea, since the installer loads an FB, then you fire off udev... Right?
[01:41] <infinity> Kamion : (Or perhaps vice versa, but either way, you may end up with two loaded)
[01:41] <Kamion> infinity: well there's only one entry in /proc/fb afterwards, so I don't think it's that
[01:41] <ogra> nope, not there
[01:41] <Keybuk> ogra: good
[01:41] <Keybuk> ogra: udevplug -Bpci -Iclass=0x02*
[01:41] <infinity> Kamion : Right, then I'll shut up.
[01:42] <Keybuk> ogra: then look to see whether the module was loaded
[01:42] <Kamion> udev *might* not be helping here, but I can't say for sure yet
[01:42] <ogra> yup, loads
[01:42] <Keybuk> "yup, loads" ?  loads of what?
[01:42] <ogra> the netcard module... 8139too
[01:42] <Keybuk> right
[01:42] <ogra> s/loads/it loads/
[01:43] <ogra> :)
[01:43] <Keybuk> . conf/initramfs.conf
[01:43] <Keybuk> . scripts/modules
[01:43] <Keybuk> . scripts/$BOOT
[01:43] <Keybuk> mountroot
[01:43] <Keybuk> run_scripts scripts/init-bottom
[01:43] <Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
[01:43] <Keybuk> --
[01:43] <ogra> oh
[01:43] <ogra> cant open scripts/modules
[01:44] <Keybuk> uh
[01:44] <Keybuk> sorry
[01:44] <Keybuk> scripts/functions
[01:44] <ogra> ah
[01:44] <Keybuk> also, just for my sanity, could you cat /sys/class/net/eth0/device/class
[01:45] <ogra> yup, booting
[01:46] <ogra> oh, err ... in busybox ?
[01:46] <Keybuk> nah, when the system is up is fine
[01:47] <ogra> 0x020000
[01:47] <Keybuk> okies
[01:47] <Keybuk> thank you for your bug report.
[01:47] <ogra> so the udevplug needs to run in a later script, right ?
[01:48] <Keybuk> just needs udevplug running over network controllers somewhere
[01:48] <Keybuk> it was missed out
[01:48] <ogra> ah, fine
[01:48] <Keybuk> because neither jbailey or I remembered it when we wrote udev-roadmap
[01:48] <ogra> heh
[01:48] <ogra> ok
[01:48] <ogra> thanks for the prompt help :)
[01:49] <Kamion> Keybuk: the installer-startup script is basically horribly broken - working on it now
[01:49] <Keybuk> Kamion: ok.  I cargo-culted it from the main startup script, but wasn't sure how much of the "deal with initramfs" crap would be needed
[01:50] <pitti> Keybuk: can you please tell me when you have some minutes to discuss about my morning's udev failure?
[01:50] <Kamion> can we just use cp -af or something rather than the find | cpio thing?
[01:50] <Kamion> we don't have cpio in busybox-udeb at the moment
[01:50] <Keybuk> Kamion: heh, I tend to use cpio because I trust it ... I always assume that things like busybox don't have cp -a
[01:50] <Keybuk> but yes, if the result is the same, we can
[01:51] <Kamion> seems to be
[01:51] <Keybuk> pitti: yup, give me three minutes, and you're up next
[01:56] <Keybuk> pitti: right, tell me about your problems
[01:57] <pitti> Keybuk: ok, so this morning I wanted to update an udev rule for testing
[01:57] <pitti> so, naive as I am, I tried sudo /etc/init.d/udev restart
[01:57] <pitti> which didn't seem to reload the conffiles
[01:57] <pitti> force-reload didn't either
[01:57] <pitti> then I did the more brutal way of calling stop, then start
[01:58] <pitti> after which I found my /dev empty, my conffiles in /etc/udev purged, and /etc/udev filled with devices
[01:58] <pitti> and /etc/udev did not seem to be a mount point (that was still /tmp)
[01:59] <Keybuk> ok
[01:59] <pitti> I suspect that "mount -n -o bind /dev /etc/udev
[01:59] <pitti> " in the init script (and the following commands) caused that
[01:59] <Keybuk> a) udevd keeps an inotify watch on /etc/udev/rules, so you don't need to reload it
[01:59] <pitti> I removed /etc/udev/* and purged/reinstalled the packages to get my conffiles back
[01:59] <Keybuk> 2) reload/force-reload should send it a HUP
[01:59] <Keybuk> 3) ooooooops :p
[01:59] <pitti> well, all I can say it that I changed /etc/udev/hal.rules, and it was not reloaded
[01:59] <Keybuk> yes
[01:59] <Keybuk> well
[02:00] <Keybuk> see also
[02:00] <Keybuk> DON'T PUT SYMLINKS IN /etc/udev/rules.d
[02:00] <Keybuk> I've been telling people this for a week now
[02:00] <Keybuk> including yourself about a dozen times
[02:00] <pitti> bbbut... that's the official Debian way
[02:00] <Keybuk> yes, that might be what Debian do
[02:00] <Keybuk> but it's wrong
[02:00] <Keybuk> we don't share any common code with the Debian udev packaging
[02:00] <Keybuk> put the file itself in /etc/udev/rules.d please
[02:00] <Keybuk> seriously
[02:00] <pitti> these symlinks come from various other packages: hal, alsa-utils, etc.
[02:00] <Keybuk> udevd cannot spot them changing
[02:00] <Keybuk> and won't reload them
[02:00] <Keybuk> yes
[02:00] <Keybuk> we will fix them all
[02:00] <pitti> ok
[02:00] <Keybuk> alsa-utils is on my list
[02:01] <pitti> TBH, I didn't notice/remember the no symlinks policy
[02:01] <pitti> I'll fix hal
[02:01] <Keybuk> yeah
[02:01] <pitti> Keybuk: do you know the cause of the lost conffiles? or do you need more info?
[02:01] <Keybuk> the symlinks stuff in the first place is Marco being very odd
[02:01] <pitti> bind-mount /dev to /etc/udev seems odd to me
[02:01] <Keybuk> we will just put the files themselves in /etc/udev/rules.d
[02:02] <jbailey> Keybuk: Post that to u-d-a perhaps so that it's recorded?
[02:02] <Keybuk> jbailey: yeah, I should do
[02:02] <Keybuk> it applies to Kamion's pcmciautils packages too
[02:03] <Keybuk> ok
[02:03] <Keybuk> so #1 is understood (you didn't put the file in the right directory)
[02:03] <pitti> yep
[02:03] <Keybuk> #2 is also understood (it uses lstat, and the symlink itself didn't change)
[02:03] <pitti> that means force-reload/restart is not necessary
[02:04] <Keybuk> right, reload/force-reload just sends a HUP ... it should have zero effect
[02:04] <Keybuk> I just put them in because I was being complete
[02:04] <Keybuk> restart does a refresh of /lib/udev/devices and udevplug
[02:04] <Keybuk> useful for a "I changed something/installed new modules/etc." hit
[02:05] <Keybuk> stop does actually stop udevd and umount /dev
[02:05] <pitti> that even seemed to have worked
[02:05] <pitti> since then mountpoint -q /dev failed
[02:05] <Keybuk> right
[02:05] <pitti> and I got my old /dev mounted to /etc/udev
[02:05] <Keybuk> it's the start on a running system without a /dev that failed
[02:06] <Keybuk> right?
[02:06] <pitti> yes
[02:06] <Keybuk> thanks for testing that code-path :)  I hadn't yet
[02:06] <Keybuk> (there's a /dev in the ordinary start, as initramfs makes it)
[02:06] <pitti> I was a little surprised that /etc/udev was no tmpfs mount
[02:06] <pitti> it seemed to be real files
[02:06] <pitti> or the kernel hides bind / -o move mounts really well
[02:07] <Keybuk> it uses it as a temporary place to put the static /de
[02:07] <Keybuk> the theory goes:
[02:07] <Keybuk> 1) move static /dev to /etc/udev
[02:07] <Keybuk> 2) mount tmpfs on /dev
[02:07] <Keybuk> 3) make /dev/.static/dev
[02:07] <Keybuk> 4) move /etc/udev mount back to /dev/.static/dev
[02:07] <pitti> yes, I see the code
[02:07] <pitti> I don't see any obvious flaws
[02:07] <pitti> oh, wait
[02:08] <pitti> I had to kill the start init script
[02:08] <pitti> because it ran indefinitely
[02:08] <Keybuk> aha!
[02:08] <Keybuk> there's a missing -p
[02:08] <Keybuk> mkdir -m 0700 /dev/.static/dev will fail
[02:08] <pitti> aah
[02:09] <pitti> so that means it probably hanged at the last mount -o move command
[02:09] <Keybuk> and the second move fails for some reason
[02:09] <pitti> but shouldn't it just fail?
[02:09] <Keybuk> no, it meant it failed at the mkdir -- it's a -e script
[02:09] <pitti> hmmm
[02:09] <pitti> it hanged, it didn't fail
[02:10] <Keybuk> ok, could you try it again with sh -x and see where it hangs?
[02:10] <pitti> Keybuk: maybe, just to be sure, you can temporarily mount it to /etc/udev/newdev/ or so?
[02:10] <pitti> sure, I'll try
[02:10] <pitti> stopped
[02:10] <pitti> whoops
[02:11] <Keybuk> that'd involve a mkdir on a read-only filesystem <g>
[02:11] <pitti> $ ls /dev
[02:11] <pitti> alsa-utils.rules  hal.rules  initctl  pcmcia.rules  rules.d  udev.conf
[02:11] <pitti> *ahem*
[02:11] <Keybuk> lol
[02:11] <Keybuk> you may wish to reboot to get to a sane system
[02:12] <Keybuk> follow-the-lady with your filesystem
[02:12] <pitti> Keybuk: /dev was perfectly sane before /etc/init.d/udev stop
[02:12] <pitti> (I already rebooted after the previous mess and restaurationof my conffiles)
[02:14] <pitti> so WTH did stopping udev scribble /etc/udev* over my /dev directory? (it's not mounted any more, btw)
[02:14] <Keybuk> dunno
[02:16] <Keybuk> fixing that -p, and changing -o move to --move fixes it for me
[02:16] <Keybuk> I can stop/start happily
[02:16] <pitti> ok, I did that, will try after reboot
[02:17] <pitti> last thing: pcspkr is not loaded automatically any more
[02:17] <Keybuk> oh, now that's kinda interesting
[02:17] <pitti> will that get fixed kernel-wise, or should we put it into /etc/modules?
[02:17] <pitti> I did not get any IRC beeps any more :)
[02:17] <Keybuk> modinfo pcspkr
[02:18] <pitti> vermagic:       2.6.15-5-amd64-generic gcc-4.0
[02:18] <pitti> , if you need that
[02:18] <Keybuk> any alias lines?
[02:19] <pitti> no
[02:19] <Keybuk> grep pcspkr /lib/modules/$(uname -r)/*
[02:19] <pitti> /lib/modules/2.6.15-5-amd64-generic/modules.dep:/lib/modules/2.6.15-5-amd64-generic/kernel/drivers/input/misc/pcspkr.ko:
[02:19] <Keybuk> ok
[02:19] <Keybuk> check that you have a "alias pnp:dPNP0800 pcspkr" line in /etc/modprobe.d/isapnp
[02:20] <pitti> I have
[02:20] <Keybuk> grep PNP0800 /sys/bus/pnp/devices/*/id
[02:20] <pitti>  /sys/bus/pnp/devices/00:05/id:PNP0800
[02:20] <pitti> (I loaded it manually, btw)
[02:20] <Keybuk> /lib/udev/pnp_modules /bus/pnp/devices/00:05
[02:21] <pitti> it will probably look different without the module loaded
[02:21] <pitti> pnp:dPNP0800*
[02:21] <Keybuk> *giggle*
[02:21] <Kamion> RAH
[02:21] <Keybuk> what's that "*" doing there?
[02:21] <Keybuk> thankyou for your bug report :)
[02:22] <pitti> my pleasure :)
[02:22] <Keybuk> any more?
[02:22] <Kamion> #20342 is everything we need, plus a few rootskel changes
[02:22] <Kamion> (for the installer)
[02:22] <pitti> Keybuk: just a question
[02:22] <pitti> Keybuk: hunger got thousands of /usr/lib/hal/hal.hotplug not found errors during boot
[02:22] <pitti> Keybuk: because /usr was not mounted, so the udev rule failed
[02:22] <pitti> Keybuk: is it legitime to add a test -x check to the rule?
[02:22] <Keybuk> pitti: yeah, we need to fix the hal stuff ... I think hal listens on a socket that can be passed uevents, is that right?
[02:23] <pitti> I think so, yes
[02:23] <Keybuk> yeah, so we'll change that to do RUN+="socket:/org/freedesktop/hal/uevent" or whatever it calls the socket
[02:23] <pitti> unix  2      [ ]          DGRAM                    13585    6047/hald           @/var/run/hal/hotplug_socket2
[02:23] <Keybuk> test -x won't help you ... udev isn't a shell, so doesn't have a test buildin :p
[02:23] <pitti> that one maybe?
[02:24] <Keybuk> pitti: no, that's a filesystem socket, you want the unix namespace socket
[02:24] <pitti> Keybuk: oh, but with PROGRAM= / RESULT== it will ceratinly work?
[02:24] <Keybuk> it'll look like @/org/... I think
[02:24] <Keybuk> pitti: how do you mean?
[02:24] <Keybuk> Kamion: installer may have been bitten by same bug as pitti
[02:25] <pitti> Keybuk: the PROGRAM/RESULT check if /usr/lib/hal/hal.hotplug is available, and RUN is only called with RESULT==0
[02:25] <Keybuk> what would you put in PROGRAM?
[02:25] <pitti> bah, why is test in /usr/bin?
[02:25] <pitti> ok, let's forget that
[02:25] <Keybuk> pitti: :D
[02:25] <Keybuk> test is also not in the initramfs at all
[02:26] <pitti> well, we could abuse /bin/bash .. :)
[02:26] <pitti> hrm
[02:26] <Keybuk> /bin/bash is not in the initramfs at all
[02:26] <Keybuk> anyway
[02:26] <pitti> this is more complicated than I thought...
[02:26] <Keybuk> the socket is the right way
[02:26] <pitti> ok, I'll read about this
[02:26] <Kamion> Keybuk: hmm?
[02:27] <pitti> ok, let's restore my static /dev first
[02:27] <Keybuk> Kamion: you don't want /dev/.static/dev in the installer?
[02:27] <Kamion> pitti: in any case you'd need to fail if hal.hotplug isn't there, so that the event can be replayed later
[02:27] <Kamion> Keybuk: nope
[02:27] <Keybuk> Kamion: does nothing call MAKEDEV (package postinst?)
[02:27] <Kamion> Keybuk: nope
[02:27] <Keybuk> ok
[02:27] <Keybuk> easy then
[02:27] <Kamion> Keybuk: package postinst => chroot /target
[02:28] <Kamion> ~ # type MAKEDEV
[02:28] <Kamion> MAKEDEV: not found
[02:28] <Keybuk> pitti: the real bug is probably that udevd does an OMG THE SKY IS FALLING! when it can't find a binary
[02:28] <Keybuk> it should be a muted warning rather than an error
[02:28] <pitti> yes, you'll get thousands of error messages
[02:28] <Keybuk> cf. grepmap in the initramfs
[02:29] <Keybuk> Kamion: will /dev ever be a mountpoint when the udev startup script is run?  ie. can I just assume it's not, and make it?
[02:30] <pitti> Keybuk: hm, is "sudo netstat -avpx|grep hal" really the right command to watch out for the unix socket?
[02:30] <pitti> Keybuk: there is just one listening socket
[02:30] <pitti> unix  2      [ ACC ]      STREAM     HRT         13584    6047/hald           @/tmp/hald-local/dbus-7awadoPF2s
[02:31] <pitti> HRT == LISTENING
[02:31] <Keybuk> hmm, it might be a floating patch
[02:31] <pitti> and that DGRAM one
[02:31] <Kamion> Keybuk: please leave that out, I've made init-udev-devices do it
[02:31] <Kamion> assume that it's already a correct mountpoint
[02:31] <Kamion> we need to create some minimal stuff in /dev in order to bring busybox init up *anyway*, so this is correct
[02:32] <Keybuk> right
[02:32] <Kamion> Keybuk: the exact directions I gave in the bug work :-)
[02:32] <Keybuk> so what should I do?  just copy over /lib/udev/devices and start udev/udeplug ?
[02:32] <Kamion> replace lines 15-24 with 'cp -af /lib/udev/devices/* /dev/'
[02:32] <Kamion> yep
[02:32] <Kamion> that's all the startup script needs to do
[02:33] <Kamion> I've fixed the few lines of d-i that needed to be tweaked; uploads are either in or on their way
[02:35] <Keybuk> oh, I remember why I used cpio
[02:35] <Keybuk> cp bitches when special files already exist
[02:35] <Keybuk> not a problem in the installer
[02:35] <Kamion> cp -af doesn't
[02:35] <Kamion> I ran into that, because /dev/console was already there
[02:36] <Kamion> but if it doesn't work, force it :)
[02:36] <Keybuk> cp -af does too here
[02:36] <Kamion> must be a busybox thing
[02:36] <Kamion> 'cos it really didn't :)
[02:38] <pitti> Keybuk: confirmed, with the two init script fixes (-p and --move) it works fine
[02:48] <Keybuk> whoah
[02:48] <Keybuk> isn't it great when you read code and find undocumented features that will rock
[02:48] <Keybuk> udev appears to have ifrename built in
[02:49] <Keybuk> AND correctly switches the name over for future events
[02:49] <infinity> \o/
[02:49] <infinity> MAKE IT WORK NOW.
[02:49] <Keybuk> SUBSYSTEM=="net", SYSFS{address}=="....", NAME="eth1"
[02:49] <Keybuk> SUBSYSTEM=="net", RUN+="ifup %k"
[02:49] <Keybuk> the %k in the second call will be eth1, not eth<whatever it was before>
[02:51] <Kamion> Keybuk: #20340> heh, oops, I thought I had upgraded already
[02:52] <Mithrandir> Kamion: how insane am I if I want to run the installer in valgrind and fix the bugz?
[02:57] <pitti> Keybuk: ok, hal binds to the NETLINK_KOBJECT_UEVENT netlink socket
[02:57] <Keybuk> what socket is that?
[02:57] <pitti> Keybuk: but I don't have the slightest idea how they work
[02:57] <Keybuk> that sounds rather like hal is listening to uevents itself
[02:57] <Keybuk> if you give me a few minutes to get this release out of the door, I'll look with you
[02:57] <pitti> oh, sure
[02:58] <pitti> sorry to bother you with it
[02:58] <Keybuk> lol, bother away
[03:01] <pitti> lol, bug tracking in /topic
[03:01] <Keybuk> yup
[03:01] <Keybuk> easier than my head/whiteboard
[03:03] <pitti> Keybuk: ok, I still know the old-fashioned way of hal: hotplug calls /usr/lib/hal/hal.hotplug, which grabs the environment, and forms a mesage out of it and sends it to a unix socket
[03:04] <pitti> Keybuk: so what you want to do is to send the udev messages directly to that socket, right?
[03:04] <Kamion> fixing the pcmciautils issue now
[03:10] <Keybuk> pitti: right, there's in theory no reason udev itself can't send that socket
[03:10] <Keybuk> except possibly for the hal magic thing
[03:10] <Keybuk> the udev release notes talk about this though:
[03:10] <Keybuk>   RUN+="socket:/org/freedesktop/hal/udev_event"
[03:11] <Keybuk> that *might* be still in a patch that's not applied upstream
[03:11] <Keybuk> or in CVS HEAD or something
[03:11] <pitti> Keybuk: I just wonder why it listens to the KOBJECT socket itself
[03:12] <pitti> I think it didn't work without the rule, but I'll try again
[03:13] <pitti> ok, no, it doesn't work
[03:15] <pitti> Keybuk: ok, that socket: thing doesn't work, that would just be too easy :)
[03:17] <Keybuk> http://lists.freedesktop.org/archives/hal/2005-November/003943.html
[03:17] <pitti> Keybuk: ok, what hal.hotplug does, is: it opens the AF_LOCAL SOCK_DGRAM socket /var/run/hal/hotplug_socket2
[03:17] <Keybuk> ^ you'll be wanting that patch
[03:18] <pitti> ah, great
[03:18] <Kamion> (diff: pcmciautils fixed)
[03:18] <pitti> Keybuk: ok, I'll pull it from the upstream cvs
[03:19] <pitti> Keybuk: I'll also fix the rules.d thing; is 85-hal ok, priority-wise?
[03:19] <Keybuk> what does the rule contain?  just that?
[03:19] <pitti> Keybuk: that, and the automatic unmounting
[03:19] <pitti> of ripped out devices
[03:19] <pitti> (which should be in the kernel, but oh well..)
[03:19] <Keybuk> 85-hal.rules
[03:20] <pitti> ok, great
[03:22] <Keybuk> 005-11-15  Kay Sievers  <kay.sievers@vrfy.org>
[03:22] <Keybuk> 	* hald/linux2/osspec.c: (hald_udev_data), (hald_helper_data),
[03:22] <Keybuk> 	(osspec_init): Listen to socket: /org/freedesktop/hal/udev_event
[03:22] <Keybuk> 	Udev will pass all data over this socket to HAL, if the following
[03:22] <Keybuk> 	rule is given:
[03:22] <Keybuk> 	  RUN+="socket:/org/freedesktop/hal/udev_event"
[03:22] <Keybuk> 	The HAL hotplug helper /usr/sbin/hal.hotplug is no longer needed
[03:22] <Keybuk> 	and should be replaced by the direct udev connection which will
[03:22] <Keybuk> 	no longer fork a process for every event.
[03:22] <Keybuk> 	This is the preparation to reuse the persistent data udev collects
[03:22] <Keybuk> 	from the hardware, instead of querying it a second time with HAL.
[03:22] <Keybuk> 	If we reach this, drive_id/* and the hotplug helper will be removed
[03:22] <Keybuk> 	from HAL.
[03:22] <Keybuk> (from hal CVS changelog)
[03:26] <Kamion> any objection to me turning on command editing, history, and tab completion in the initramfs busybox shell?
[03:26] <Kamion> it would make life so much less painful
[03:26] <jbailey> Kamion: What the size cost?
[03:26] <Kamion> I can find out
[03:44] <Keybuk> Kamion: does newer pcmciautils add -Qb to its "modprobe pcmcia" call?
[03:44] <Keybuk> (in the udev rules)
[03:47] <Kamion> no; should it?
[03:47] <Keybuk> yeah
[03:47] <Keybuk> otherwise "users can't blacklist pcmcia"
[03:47] <Keybuk> and you want the -Q to suppress automated bitching
[03:48] <pitti> Keybuk: oh, right, that was another thing I wanted to ask you - is /etc/hotplug/blacklist.d still supported?
[03:48] <Kamion> Keybuk: how about pcmcia_core?
[03:48] <Kamion> that's currently -q
[03:51] <Keybuk> Kamion: change to -Qb ... I included all the behaviour of -q in -Q
[03:52] <Keybuk> pitti: nothing in Ubuntu should place a file in there, therefore it's currently disabled, however before beta we will enable it for anything the users might have in there
[03:52] <Kamion> alright, I'll -Q the bridge module loads as well
[03:52] <Kamion> fixed in my tree
[03:52] <pitti> Kamion: two or three packages drop stuff in it; most important is alsa
[03:52] <Keybuk> pitti: libsane should provide an /etc/modprobe.d/libsane-blacklist which has "blacklist hpusbscsi" and "blacklist scanner" in it
[03:53] <Keybuk> alsa is on my todo list
[03:53] <Kamion> pitti: s/Kamion/Keybuk/ :)
[03:53] <pitti> ah, great
[03:53] <Kamion> I can change my nick to Keybun if it would make things easier
[03:53] <pitti> Kamion: oops, sorry :)
[03:53] <Keybuk> Kamibuk
[03:54] <Kamion> -rwxr-xr-x  1 cjwatson cjwatson 910672 2005-12-01 14:29 old/busybox
[03:54] <Kamion> -rwxr-xr-x  1 cjwatson cjwatson 918352 2005-12-01 14:33 new/busybox
[03:54] <pitti> we get completion for 8 kB?
[03:54] <Kamion> jbailey: ^-- size cost (unstripped) of turning on editing/history/tab-completion
[03:55] <pitti> sweet
[03:55] <jbailey> Kamion: No brainer. =)
[03:55] <Kamion> oh, no, I think that is stripped
[03:55] <Kamion> ok, I'll enable it
[03:56] <Keybuk> infinity: linux-doc-2.6.15 conflict/overwrites linux-doc-2.6.12
[03:59] <pitti> sweeet - conffiles were transitioned, hal responds to the socket events
[04:00] <pitti> thanks Keybuk
[04:00] <pitti> Keybuk: I'll fix the rules.d symlink story for libgphoto2, too
[04:05] <Keybuk> right, while the buildds are building new udev and m-u-t, I'm gonna grab lunch
[04:51] <makx> inifinity: do you have latest ubuntu initramfs-tools in bzr archive?
[04:52] <makx> jbailey's latest pushed is 0.31.
[04:53] <jbailey> makx: I think he's asleep atm.
[04:54] <makx> aah ok, will reask tomorrow, thanks jbailey. :)
[05:02] <pitti> Keybuk: libgphoto2 conffiles fixed
[05:03] <pitti> (diff: hal rules are reloaded now)
[05:12] <Keybuk> (diff: pending -> fixed)
[05:13] <HiddenWolf> All of it?
[05:14] <HiddenWolf> Nice!
[05:14] <Keybuk> yeah, all the pending stuff went into 0ubuntu5
[05:26] <makx> Keybuk: in 0.40ubuntu1 you mention Copy across modprobe blacklist, as well aliases, is this the same file?
[05:28] <Keybuk> /etc/modprobe.d/aliases
[05:28] <Keybuk> /etc/modprobe.d/blacklist
[05:28] <Keybuk> different files
[05:29] <makx> ohh overseen, yes thanks!
[05:30] <makx> debian but #337318 wanted to have all /etc/modprobe.d
[05:30] <makx> s/but/bug/
[05:30] <makx> i've asked him for clarification.
[05:30] <Keybuk> it makes some amount of sense to copy the entire directory
[06:00] <ogra> Keybuk, just to report back, my thin clients boot fine again
[06:00] <ogra> thanks for the quick fix :)
[06:09] <ogra> Keybuk, if you have an uploade of initramfs-tools pending, could you pretty please finally remove the sleep 3 from /usr/share/initramfs-tools/scripts/nfs ?
[06:10] <Keybuk> I don't have an upload pending, it's infinity's job now :p
[06:10] <ogra> ok, i'll poke him....
[06:11] <ogra> thin clients stilltake over a minute for booting :(
[06:13] <Keybuk> yeah, lots of changes yet to come
[06:16] <jbailey> ogra: Still takes is fine.
[06:16] <ogra> oh, i thought this was it already
[06:16] <jbailey> ogra: TAkes a minute longer would suck. =)
[06:16] <ogra> i target 45 seconds .... but i am at 1:03~1:09
[06:17] <jbailey> ogra: Just upload it with the NFS fix.  There's no reason to wait on a BML.
[06:17] <Keybuk> what were you before?
[06:17] <ogra> at least i just could boot without usplash timing out
[06:17] <ogra> with all bootscripts it was ~1:45
[06:17] <ogra> with eliminating the bootscripts ~1:20
[06:17] <Keybuk> so it's taking 40s less?
[06:18] <Keybuk> ok, still 10-15s less then
[06:18] <ogra> so i won about 15sec
[06:18] <Keybuk> good
[06:18] <Keybuk> that's about my expected win
[06:18] <Keybuk> next we move several bits to udev rules
[06:18] <Keybuk> sort out networking
[06:18] <Keybuk> and reorder rcS to eliminate the bugs
[06:18] <Keybuk> that might give us up to 10-15s more
[06:18] <ogra> that'd be enough for me :)
[06:19] <Keybuk> then fix readahead, hopefully another 10-15s there
[06:19] <ogra> i just had the impression you were already done
[06:19] <Keybuk> hmm, no?  this was the FIRST upload :p
[06:19] <ogra> forget about readahead ... i cant use it
[06:19] <ogra> (wont gain much with 32-64 MB)
[09:40] <Keybuk> likewise
[09:40] <Keybuk> UDEV_LOG=info /sbin/udevd --daemon
[09:40] <Keybuk> :p
[09:41] <crimsun> ok, got that
[09:41] <Keybuk> right, did it output things?
[09:42] <crimsun> indeed, 3 lines (I'll have to by-hand)
[09:42] <Keybuk> ok
[09:42] <Keybuk> just that it output things
[09:42] <Keybuk> now following stuff will output various gubbins, you'll need to read the screens (use shift-pgup/dn) and look for anything suspicious
[09:42] <Keybuk> has_driver returning 1 isn't suspicious, that just means there's no driver loaded yet
[09:42] <Keybuk> modprobe returning 1 is suspicious
[09:42] <Keybuk> etc.
[09:42] <crimsun> k
[09:43] <Keybuk> now, first let's just sanity check that you don't have a /dev/sda* , /sys/class/block/sda* and /sys/bus/scsi* ?
[09:43] <crimsun> none of those
[09:43] <Keybuk> good, it's nice to make sure we're not in la-la land
[09:44] <Keybuk> now we'll run a few udevplug commands, these will dump a lot of udevd debugging information to the screen -- read it all and summarise for me anything suspicious
[09:44] <crimsun> k
[09:45] <Keybuk> we'll also write some output to a file, cat that file and say what you see (feel free to just replace long number strings with *)
[09:45] <Keybuk> udevplug -Bide -Bscsi -Bi2o -Busb -Bieee1394 > 1.txt
[09:45] <Keybuk> uh
[09:45] <Keybuk> stick -v in there too :p
[09:45] <Keybuk> udevplug -v -Bide -Bscsi -Bi2o -Busb -Bieee1394 > 1.txt
[09:47] <crimsun> no output (1.txt is a 0-byte)
[09:47] <Keybuk> exxxxcellent
[09:48] <Keybuk> ok, this is an easy one, don't worry about this, it just makes a bunch of stuff you'll need
[09:48] <Keybuk> (ie ignore the output)
[09:48] <Keybuk> udevplug -Cmem -Cmisc -Ctty -Cvc
[09:48] <Keybuk> then you may as well press enter lots so you can find your place
[09:48] <Keybuk> this one we care about
[09:48] <Keybuk> udevplug -v -b > 2.txt
[09:49] <Keybuk> in 2.txt you should only have /sys/block/ram* ... and nothing suspicious in the udevd dump
[09:52] <crimsun> doesn't appear to be anything suspicious, lots of /block/ram* and /dev/ram* with their associated has_driver returning 1, presumably innocuous according to above
[09:52] <Keybuk> yeah
[09:52] <Keybuk> has_driver is just a "can we skip modprobe" thing
[09:53] <Keybuk> right
[09:53] <Keybuk> so we still have no /dev/sda*, /sys/block/sd*, /sys/bus/scsi* ?
[09:53] <crimsun> correct
[09:54] <Keybuk> right
[09:54] <Keybuk> so now, in theory, we're in a sane state to probe for scsi controllers
[09:54] <Keybuk> now, I'm assuming it's a real scsi controller that we're looking for, yes?
[09:54] <crimsun> SATA (IBM TP X41-2527)
[09:54] <Keybuk> right, SATA controller
[09:54] <Keybuk> ok, that makes things more fun
[09:55] <Keybuk> so let's try this:
[09:55] <Keybuk> udevplug -v -Bpci -Iclass=0x0[12] * > 3.txt
[09:55] <Keybuk> you'll get a lot of output from that, read it all carefully
[09:55] <Keybuk> I'm interested in anything modprobe does (you'll see module/* events)
[09:55] <Keybuk> and also the 3.txt contents
[10:04] <crimsun> ok, as far back as the buffer permits, SCSI device sda is attached, a lots of scsi_id output (ID_VENDOR, ID_MODEL, etc.), lots of use of kernel name because node name not being set, edd_id spits out "main: no kernel EDD support" (returns 2), has_driver /block/sda returns 1, /dev/sda is created, lots of symlinks set up, lots of vol_id output, /dev/sda4 created, more vol_id output, /dev/sda3 created, more vol_id output, /dev/sda1 created
[10:05] <Keybuk> right
[10:05] <Keybuk> ls $ROOT finds something?
[10:05] <crimsun> 3.txt has /sys/devices/pci0000:00/0000:00:1[cef] *
[10:06] <crimsun> yep, ''ls $ROOT'' returns "/dev/sda3"
[10:06] <Keybuk> ok...
[10:06] <Keybuk> can you do
[10:06] <Keybuk> grep udevplug scripts/init-premount/udev
[10:07] <Keybuk> check that the calls are exactly as you've done above
[10:09] <crimsun> the output contains three lines: "/sbin/udevplug -Bide -Bscsi"[...] , "/sbin/udevplug -Bpci -Iclass=0x0[12] *", and "/sbin/udevplug -W"
[10:10] <Keybuk> ok
[10:10] <Keybuk> so what I think you have, is the "SCSI takes longer than udev" bug
[10:10] <Keybuk> it's not a udev version issue, it's just how fast your machine feels like
[10:10] <Keybuk> basically if it fails, it means your machine reached the "mount root filesystem" bit faster then your SCSI/SATA controller got around to finding the devices on its bus
[10:10] <Kamion> time: 0.50
[10:10] <Kamion> nice
[10:11] <crimsun> ah, so the change in 5 to probe the additional devices is probably the issue
[10:11] <Kamion> not sure what it was before though
[10:11] <Keybuk> Kamion: 1:20ish
[10:11] <Kamion> on *my* system, not yours
[10:11] <Keybuk> Kamion: they're surprisingly similar for broadly similar hardware
[10:12] <Keybuk> all those sleep statements <g>
[10:12] <crimsun> we pretty much walked through /etc/udev/rules.d/00*init (and maybe 20*names* ?), correct?
[10:12] <Keybuk> crimsun: actually, if anything, that makes it more likely to succeed
[10:12] <Kamion> http://people.ubuntu.com/~cjwatson/bootchart/dapper-20051201-2.png, anyway
[10:12] <Keybuk> crimsun: it was probably the fact that udevplug is faster in ubuntu5
[10:12] <Keybuk> we're taking heavily about adding a generic "spin until -e $ROOT" to initramfs
[10:13] <crimsun> Keybuk: ah. In any case, thanks for taking time.
[10:14] <Keybuk> are you on i386?
[10:14] <crimsun> yeah (2.6.15-6-686)
[10:14] <Keybuk> ok
[10:14] <Keybuk> to boot
[10:14] <Keybuk> ,pimtrppt
[10:14] <Keybuk> uh
[10:14] <Keybuk> mountroot
[10:14] <Keybuk> run_scripts scripts/init-bottom
[10:15] <Keybuk> exec run-init /root $init "$@" </root/dev/console >/root/dev/console
[10:15] <Keybuk> --
[10:15] <Keybuk> that should get you booted
[10:17] <crimsun> Keybuk: indeed, thanks again. It's kinda scary how much of the syntax is becoming familiar (spent a few hours this morning poring over /etc/udev/rules.d/ and the udev man page to get the firmware loading correctly again)
[10:18] <Keybuk> ok... one moment, I have a package for you
[10:19] <crimsun> k
[10:23] <Keybuk> http://people.ubuntu.com/~scott/initramfs-tools_0.40ubuntu5_all.deb
[10:23] <Keybuk> ^ download and install that
[10:24] <Keybuk> then update-initramfs -u
[10:24] <Keybuk> then reboot
[10:24] <Keybuk> see if that cures you
[10:25] <Keybuk> Kamion: neat ... should be able to take another 10s off you by the weekend too
[10:27] <crimsun> Keybuk: yep, boots fine
[10:27] <Keybuk> could yo do a few reboots, just to make sure
[10:27] <Keybuk> one or two warm
[10:27] <Keybuk> and one or two cold
[10:27] <crimsun> yup
[10:27] <Keybuk> (ie three-finger, reset button and power off/wait/power on)
[10:30] <Keybuk> crimsun: yeah, it's kinda kooky when you realise you can boot the system from kernel entirely from memory
[10:41] <crimsun> hmm, now it hangs after "Done.\nBegin: Mounting root file system ...\nBegin: Running /scripts/local-top ...\nDone."
[10:44] <crimsun> after ~25 seconds I'm dropped to a busybox shell
[10:44] <crimsun> reproducible on both warm and cold boots
[11:28] <Keybuk> crimsun: hmm, we'll have to continue this in the morning
[11:29] <Keybuk> is getting too late here, will be back in ~8 hours