[12:58] <makx> Md adds the initramfs-tools hooks to udev.
[12:58] <makx> much smaller diff now.. :)
[04:06] <infinity> makx : Excellent.  That should give me some motivation to look over the remaining diffs.
[09:58] <makx> infinity: would be cool if ubuntu's land again in bzr.
[09:58] <makx> my archive is public.
[09:59] <makx> infinity: the evms split is the next step, already spoken with the evms maintainer.
[09:59] <makx> bzr branch http://debian.stro.at/bzr-test/initramfs-tools/
[10:02] <infinity> makx : Oh, you rule, I'll happily take that change.
[10:02] <infinity> makx : As for bzr, it'll happen.  I'm just terminally lazy when it comes to such things.
[10:03] <makx> infinity: i try to sync with ubuntu whenever possible.
[10:03] <makx> there were some minor errors in Keybuk's latest changelog
[10:03] <infinity> That's because you're a far more diligent person than I am. :)
[10:03] <makx> s/changelog/changes/
[10:04] <infinity> (Or you have more spare time... Pick one)
[10:04] <infinity> Have you told him about them?
[10:04] <makx> he removed support for the resume conf.
[10:04] <makx> when splitting udev out.
[10:04] <infinity> I'm sitting around waiting for him to show up so I can give him shit about something in udev. :)
[10:48] <fabbione> Kamion: assuming i want to test my rescue hook stuff.. i guess i will need the udeb in the archive for anna to merge the templates properly....
[10:49] <fabbione> otherwise it won't show up.. right?
[10:50] <Kamion> fabbione: easiest way is probably to build a monolithic image from debian-installer with your changed udeb in build/localudebs/
[10:51] <Kamion> type 'make' in build to see the image list; if monolithic isn't there then add it to config/blah, it's usually there but commented out; then 'fakeroot make build_monolithic' or similar
[10:55] <fabbione> Kamion: ok.. thanks
[11:01] <makx> Kamion: is there a nice howto build udeb?
[11:02] <makx> (looked at several rules ssh, udev everyone does it his way)
[11:04] <Kamion> not really, but I'd recommend using XC-Package-Type: udeb in the appropriate binary stanza in debian/control and letting debhelper (>= 4.2) do most of the work
[11:05] <Kamion> after that it's just a matter of adjusting what files end up in the package; debhelper will take care of avoiding documentation etc.
[11:06] <makx> Kamion: ok thx.
[11:06] <Kamion> installer/doc/devel/modules.txt in the d-i repo documents what features are/aren't supported in udebs
[11:06] <Kamion> oh, and it has a two-minute primer at the end which is essentially what I just said :)
[11:07] <Kamion> http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/modules.txt?op=file&rev=0&sc=0
[11:08] <Kamion> libraries that need to go in the d-i initrd are the main tricky case, because they need to play nicely with library reduction
[11:13] <fabbione> Command failed with status 1 : objdump --private-headers ./tmp/monolithic/tree/lib/md5client/checkpkg
[11:13] <fabbione> With output: objdump: ./tmp/monolithic/tree/lib/md5client/checkpkg: File format not recognized
[11:13] <fabbione> HMMMM
[11:13] <fabbione> file checkpkg
[11:13] <fabbione> checkpkg: ASCII English text
[11:13] <fabbione> that's correct.. it's a shell lib
[11:15] <fabbione> Kamion: any idea of what i am doing wrong?
[11:24] <Kamion> put it in /usr/lib instead
[11:25] <fabbione> hm ok
[11:25] <fabbione> strange that it doesn't barf on lib/rescue.d
[11:25] <Kamion> hmm
[11:25] <Kamion> where exactly is it failing?
[11:25] <Kamion> as in, a bit more context
[11:25] <fabbione> at lib reduction
[11:25] <fabbione> monolitich build
[11:25] <Kamion> the three preceding lines of the output would be useful
[11:26] <Kamion> oh, never mind
[11:26] <Kamion> fabbione: put #! /bin/sh at the top
[11:27] <Kamion> even if it isn't executed, that makes mklibs ignore it
[11:27] <fabbione> ah ok
[11:27] <fabbione> works for me
[11:27] <Kamion> then it should be fine in /lib
[11:30] <fabbione> yeps
[11:30] <fabbione> thanks a lot
[11:39] <fabbione> it's not my lucky day apparently
[11:40] <fabbione> Kamion: can you tell me when you have 10/15 minutes to help me? i am need of help here :(
[11:45] <Kamion> fabbione: now's fine
[11:46] <fabbione> Kamion: ok thanks!
[11:46] <fabbione> well i did build the monolith mini.iso
[11:46] <fabbione> i boot with rescue/enable=true
[11:46] <fabbione> or rescue from syslinux
[11:46] <fabbione> but there is no rescue menu at all
[11:46] <fabbione> i get pushed to the partitioner
[11:46] <Kamion> did you include rescue-mode in your initrd?
[11:46] <fabbione> if i <go back> to the main menu i can't see anything like rescue..
[11:46] <Kamion> I bet you only have rescue-chekc
[11:46] <Kamion> ck
[11:47] <fabbione> yeps
[11:48] <fabbione> ok.. i guess that explain
[11:48] <fabbione> why isn't it included by default?
[11:48] <Kamion> I'll fix that upstream now; in the meantime, put rescue-mode in pkg-lists/monolithic/local
[11:48] <fabbione> (given that we offer the rescue option at boot i mean)
[11:48] <fabbione> yes i can do that..
[11:48] <fabbione> thanks
[11:48] <Kamion> mostly I just forgot to include it there
[11:48] <fabbione> ahhh ehehe
[11:49] <Kamion> fixed
[11:50] <fabbione> i am building right now
[12:23] <fabbione> Kamion: it starts to look better but i still don't get my menu.. do i need to use one of this isinstallable thingy?
[12:24] <fabbione> i can see there are no templates from my pkg..
[12:24] <Kamion> does the rescue operations menu show up?
[12:24] <fabbione> the rescue does
[12:24] <fabbione> my entry in it doesn't
[12:24] <Kamion> can you put your udeb somewhere?
[12:25] <fabbione> sure
[12:26] <fabbione> brz clone http://people.ubuntu.com/~fabbione/archives/md5client/
[12:26] <fabbione> just a sec.. it's still pushing
[12:26] <fabbione> damn adsl
[12:26] <fabbione> i need to kill my isp sooner or later
[12:26] <fabbione> ok done
[12:26] <Kamion> oh, just the udeb would do fine, if you could put it on rookery
[12:26] <Kamion> but ok
[12:27] <fabbione> doing
[12:27] <fabbione> people/~fabbione/md5client-udeb_0.1-0ubuntu1_all.udeb
[12:28] <Kamion> bzr mv debian/md5client.templates debian/md5client-udeb.templates; sed -i 's/md5client/md5client-udeb/' debian/po/POTFILES.in; debconf-updatepo
[12:29] <Kamion> oh and: echo '2 utf8' > debian/po/output
[12:29] <fabbione> thanks Kamion
[12:29] <Kamion> ... while you're at it
[12:29] <Kamion> cdebconf can only deal with UTF-8 templates so forcing it is a good idea
[12:29] <fabbione> thanks a lot
[12:29] <Kamion> np
[12:30] <fabbione> do i need to echo at build time? or just once?
[12:30] <Kamion> no just once, then bzr add debian/po/output
[12:30] <Kamion> that's fine in the source tarball
[12:31] <fabbione> cool done
[12:32] <infinity> Keybuk : Feel like having someone be irrtated in your direction?
[12:35] <Keybuk> are they cute?
[12:35] <infinity> I dunno, am I?
[12:37] <Keybuk> :)
[12:37] <Keybuk> what's your problem?
[12:38] <Kamion> nicely dodged
[12:38] <infinity> Hrmph.
[12:38] <infinity> I feel so rejected.
[12:38] <infinity> Anyhow.
[12:39] <infinity> udevplug appears to suck in some way I haven't yet fully diagnosed.
[12:39] <infinity> I suspect 'udevplug -W' doesn't actually work as advertised.
[12:39] <infinity> (Well, I'm pretty positive of that)
[12:40] <infinity> When I boot with the normal udev initramfs setup, I get a race where coldplugging is still in progress when ide-generic loads, it grabs my drive first, and it gets named 'hda' instead of 'sda'
[12:40] <infinity> So, being the clever sort I am, I changed the script to call "udevplug -W" before the modprobe.  Which changes nothing.  Same race happens.
[12:41] <infinity> (If I remove the modprobe or put a massive sleep before it, all is just fine, for the record... it's just when the modprobe happens before libata gets around to owning my drive that the world ends)
[12:42] <Kamion> works?
[12:42] <fabbione> yup
[12:42] <Kamion> rock on
[12:42] <fabbione> it takes a long time to do a test
[12:42] <fabbione> mainly because i need a CDreader in a machine
[12:42] <Kamion> qemu isn't too bad for stuff that's early in the installer
[12:43] <Kamion> for anything like full installs I find it way too slow
[12:43] <Keybuk> infinity: right, so how this works (in theory) is this
[12:43] <infinity> Keybuk : How is it actually meant to work?... Does 'udevplug -W' check for a semaphore file, loop on that, and return when it's gone?
[12:43] <fabbione> the main issue is that to run the md5sum stuff can take WAYYYYY longer than install
[12:43] <fabbione> + i still need an installed system to test against
[12:43] <Keybuk> udevd exposes it's queue of events its received from the kernel, but not yet completed processing of
[12:43] <infinity> Keybuk : In which case, 'udevplug -anythingelse' can't return until after it writes said semaphore, or you have a race.
[12:44] <Keybuk> it does that as a directory called /dev/.udev/queue which contains symlinks to the sysfs paths queued
[12:44] <Keybuk> now, udevplug "in normal operation" does the following
[12:44] <Keybuk> 1) wait for this directory to vanish
[12:44] <Keybuk> 2) make it again
[12:44] <Keybuk> 3) touch all the uevents
[12:44] <Keybuk> 4) wait for this directory to vanish
[12:45] <infinity> At which step does it return?
[12:45] <Keybuk> so it "waits for there to be nothing in the queue" before going ahead, then waits for there to be nothing in the queue before resuming
[12:45] <Keybuk> step 5
[12:45] <Keybuk> udevplug -W just does step 4
[12:45] <Kamion> fabbione: works on an amd64 *host* emulating i386, I'm not sure if it does amd64 targets yet
[12:45] <infinity> Keybuk : So it's udevd at fault here, not udevplug?
[12:45] <Keybuk> it's hard to define "at fault"
[12:46] <infinity> Keybuk : In that it clearly must have something in the queue, but it's not advertising it... Or something.
[12:46] <Keybuk> no, it's not that
[12:46] <Keybuk> it might be simply that it DOESN'T have anything in the queue
[12:46] <Keybuk> if the modprobe returns successfully, it's possible for the queue to become empty
[12:46] <Keybuk> while the IDE controller is still waking up, and rubbing the sleep out of its eyes
[12:46] <infinity> It's forked-and-forgot 20 modprobes that aren't done?
[12:46] <infinity> Hrm.
[12:47] <infinity> (returned, but not "done"...)
[12:47] <Keybuk> and then when the IDE driver is ready, and spits out the "I found this shit" events, udevplug has moved on because the queue was empty
[12:47] <fabbione> Kamion: that would be perfect
[12:47] <Keybuk> it's the "no way of knowing an IDE/SCSI/USB controller is busy" problem
[12:47] <infinity> Keybuk : Then we have a problem... That ide-generic load just plain can NOT happen there.
[12:47] <Keybuk> right
[12:47] <Keybuk> now, that ide-generic modprobe is interesting
[12:48] <Keybuk> it was there because of a bug in our kernels
[12:48] <Keybuk> which I fixed
[12:48] <Keybuk> so in theeeory we can take that away now
[12:48] <Keybuk> but we still need it for cases where we don't have an IDE controller we know about
[12:48] <Keybuk> and again, we come to this "need to wait for the kernel" thing
[12:48] <infinity> Well, the world certainly doesn't blow up for me if I take it away, but I'd like to ask someone who's not on SATA to confirm. :)
[12:49] <fabbione> d if=/dev/urandom of=hda bs=4G count=1
[12:49] <fabbione> dd: memory exhausted
[12:49] <fabbione> suck! :)
[12:49] <infinity> Keybuk : Hrm.  Non-PCI controllers become an issue here, I guess.
[12:49] <Keybuk> yup
[12:50] <Keybuk> also I'm not sure, but I think we need ide-generic loaded to cope with pcmcia IDE devices too
[12:50] <infinity> Can we do a few-second loop, waiting for the root device to appear, and if it doesn't show up, load ide-generic under the assumption we needed it?
[12:51] <infinity> (Then load it again WAY later in the root filesystem, should people need it for non-root devices and we haven't loaded it yet)
[12:51] <Keybuk> right, that's kinda where I'm thinking of going for this
[12:53] <Keybuk> it had to wait until today, and the -7 kernel to be -meta
[12:53] <Keybuk> the trouble is "how long do we wait" ? :p
[12:53] <infinity> Yeah, scanning a real SCSI bus can take ages.
[12:54] <infinity> Any guarantees that SCSI devices will get scanned after IDE/SATA, perchance?
[12:54] <Keybuk> not currently
[12:54] <infinity> So we can "wait long enough for a reasonable full ATA scan, then give up"
[12:54] <infinity> Meaning it wouldn't matter if we're stuck in SCSI-land.
[12:55] <infinity> If we get stuck scanning a SCSI bus before we hit SATA, then load ide-generic, we're back where I am now.
[12:55] <Keybuk> I increasingly see why nobody else has tried to make a generic initramfs :p
[12:56] <infinity> We will prevail.
[12:56] <infinity> Somehow. :)
[12:56] <infinity> For now, though, I'd recommend any hack that doesn't land people like me where I am.
[12:57] <Keybuk> so here's my current theory
[12:57] <infinity> Real SCSI busses, while an important case to work on, are probably a corner case for people testing dapper right this instant.
[12:57] <Keybuk> we plug storage controllers, if we find at least one, we don't load ide-generic
[12:57] <Keybuk> if we don't find any, we load ide-generic
[12:57] <infinity> That's touchy.
[12:57] <Keybuk> why?
[12:58] <infinity> If you find my shitty SCSI card I have my scanner attached to, but not my root filesystem controller, I cry.
[12:58] <Keybuk> meh, good point
[12:58] <infinity> (In theory... I haven't had a SCSI scanner for years)
[12:58] <Keybuk> and I bet you $10 that your SATA controller doesn't advertise as one
[12:59] <infinity> Do they have a specific PCI class?
[12:59] <Keybuk> they tend to pretend to be PCI_CLASS_STORAGE_SCSI :p
[12:59] <Keybuk> or, more hilariously, PCI_CLASS_STORAGE_RAID
[12:59] <infinity> How would I find this out, out of curiosity?
[01:00] <Keybuk> lspci -n
[01:00] <Keybuk> (use ordinary lspci first if you don't know which line is your controller)
[01:00] <infinity> 0000:00:1f.2 0101: 8086:2653 (rev 03)
[01:00] <Keybuk> wow, it actually claims to be an IDE controler
[01:01] <Keybuk> most don't
[01:01] <Keybuk> yay Intel
[01:03] <makx> Keybuk: the kernel bug you mentioned is related to modular ide?
[01:03] <infinity> Anyhow, my local initramfs is hacked to just not load ide-generic at all, but I happen to know I'm not the only person with this sort of controller. :)
[01:03] <infinity> makx : yes.
[01:03] <makx> need to look up what you did with that strange Xu legacy.
[01:03] <Keybuk> infinity: right, the upstream solution is "don't load ide-generic unless you need to"; we just need to find a way of determining need
[01:04] <Keybuk> makx: http://people.ubuntu.com/~scott/fixed-ide.patch
[01:04] <Keybuk> makx: this is still the same bug we're discussing, the patch just makes it fixable
[01:05] <jbailey> The final problem that we hit was for controllers without a sexy chipset and that don't appear on the PCI bus.
[01:05] <Keybuk> jbailey: whiteholespewingtimeidedriverscansbusbutidegenericloadsandclaimsthedevicesbeforescanhascompleted
[01:06] <jbailey> Near the end of the breezy cycle, Matt had me always oad ide-generic no matter what because a class of devices existed that weren't getting an IDE controller at all.
[01:06] <makx> Keybuk: why am i not hit with debian's udev?
[01:06] <infinity> And that's fine, but it has to happen way AFTER everything else it detected.
[01:06] <Keybuk> makx: ya know, I was never entirely sure of that
[01:07] <jbailey> Keybuk: Yeah, well.  I've said more than once that that I want bus scanning state to be visible from userspace.
[01:07] <jbailey> Even if ther kernel's bus scans were.
[01:07] <jbailey> I knwo that HW ones will always suck.
[01:07] <Keybuk> yeah, the problem with just waiting for devices to appear is the "what if there aren't any on that bus?" problem
[01:09] <Keybuk> oooooooh
[01:09] <Keybuk> does something appear in sysfs after the scan has completed, in the ide case
[01:09] <Keybuk> the scan takes place in the middle of the init
[01:10] <Keybuk> we could WAIT_FOR_SYSFS that
[01:10] <jbailey> Well, hmm.  You're not waiting for the scan of the IDE bus, right?
[01:10] <Keybuk> we are
[01:10] <jbailey> Just the PCI bus so that all the DMAable controllers are found.
[01:11] <Keybuk> no, we're waiting for the IDE bus scan to complete
[01:11] <Keybuk> so we don't carry on and load ide-generic while the scan is still going on
[01:11] <jbailey> What does it interfere with there?  By that time, shouldn't the other controller have already allocated all the resources?
[01:11] <makx> Keybuk: i saw no check of /dev/.udev/queue in your udev hooks.
[01:12] <Keybuk> the problem is that if we load ide-generic, while a scan is still going on, then ide-generic can become the favourite to win the devices
[01:12] <Keybuk> the ide scanning stuff doesn't hard-code the winning driver
[01:12] <Keybuk> makx: that's what udevplug does
[01:12] <makx> that's the part requiring > 2.6.14
[01:13] <makx> ?
[01:13] <jbailey> Keybuk: Wha?  That's crazy.
[01:13] <jbailey> I would've thought the IDE devices would be recognised as subdevices of their controller, and not be interfered with.
[01:13] <Keybuk> apparently not
[01:14] <Keybuk> at least, not where ide-generic is concerned
[01:15] <Keybuk> I need to sit down with the ide subsystem code, I think
[01:16] <jbailey> The libata stuff isn't 2.6.15-bound is it?
[01:16] <infinity> Keybuk : I think the breakage happens in my case before libata is even loaded.
[01:17] <infinity> Keybuk : It goes something like "PCI scan starts, while other devices (like tg3) are being loaded, we modprobe ide-generic, then libata gets loaded and it's already lost"
[01:17] <infinity> I'm not sure we actually have a race AFTER libata starts scannind for devices.  We might.  That would be scary.
[01:18] <Keybuk> that shouldn't happen ... if tg3 is loaded first, then udevplug will still be blocking while ata_piix gets loaded
[01:18] <Keybuk> or, in theory, both get loaded at the same time, and udevplug waits for them both to complete
[01:18] <Keybuk> are you heading for bed soon, or are you still going to be up for a couple of hours?
[01:19] <infinity> I'm going to go watch a movie and slack for a couple of hours, then I'll be back at my computer.
[01:19] <Keybuk> ok, grab me when you're up for some hot debugging action
[01:19] <Keybuk> want to poke around and see what is actually happening with your controller
[01:20] <infinity> Yeah, it's kinda hard to tell for sure what order events occur in, since I can't type four thousand words per minute.
[01:20] <infinity> If you can script something to watch WTF is really going on behind the scenes...
[01:20] <makx> Keybuk: while splitting udev out, you removed probably unintentionaly the initramfs.conf resume variable support.
[01:20] <infinity> (Of course, given the delicate race conditions at play, adding any more CPU usage may just make them go away)
[01:21] <infinity> Note that I actually booted successfully once, while all the other times were miserable failures.
[01:21] <Keybuk> I can give you an "a;b;c" thing to run in the shell, without "quiet" so we can see which is running when
[01:21] <Keybuk> where shell ~= initramfs
[01:21] <infinity> That irritated me more than anything else... The debug boot that worked.
[01:21] <Keybuk> makx: that block was duplicated elsewhere
[01:22] <infinity> My girlfriend backed away slowly as I was cursing at my laptop for booting correctly when it bloody well wasn't supposed to.
[01:23] <makx> Keybuk: oh indeed, hadn't seen that while going throught the diff.
[01:23] <jbailey> infinity: Ah good.  Keep this one.
[01:23] <jbailey> She understands that programmers are most dangerous in the presence of XPASS.
[01:24] <Kamion> infinity: how goes the m-f-l-a stuff? if it's part-done I could take over
[01:24] <infinity> Kamion : Smashingly, if I could figure out where the heck the rtlclassic theme comes from..
[01:27] <Kamion> you already know more than me, then :)
[01:29] <infinity> Maybe it's not required anymore...
[01:36] <infinity> Oh, hot diggity.  We don't need rtlclassic anymore.
[01:36] <infinity> firefox does right-to-left natively.
[01:38] <infinity> Man, right-to-left menus really hurt my brain.
[01:43] <infinity> On second thought, this package may be too confusing for a man who's supposedly not working right now.
[01:44] <Kamion> it's a flight 2 blocker, so if you can't do it feel free to send it to me (with instructions on how to build the .orig.tar.gz if that's quicker than uploading it)
[01:45] <infinity> Well, the orig is the problem, really.
[01:45] <infinity> Upstream renamed a mess of locales, and I'm trying to decide if I fudge it and just rename them back, or if I do it correctly, and have the packages conflict with the old ones, etc...
[01:46] <infinity> But the Right Way looks very... Odd.  It's not a sane source package. :)
[01:47] <infinity> Alright, you want me to fix it in 2 hours, or you want to find another sucker?
[01:48] <Kamion> two hours is fine
[01:49] <Kamion> you've got it in your brain already :)
[01:49] <Kamion> (if you don't mind too much)
[01:49] <infinity> Yeah, it's floating around up there.
[01:49] <infinity> I think I'll just hack it up to be buildable and installable enough to make flight-2 happy for you, then make pitti deal with the fallout. :)
[01:49] <Kamion> yeah
[01:50] <infinity> Off to watch a movie first, then back to bending my brain at firefox.
[01:50] <infinity> At least the lack of rtl theme dependencies is good news.
[01:50] <infinity> An he_IL is a confusing locale to use a computer in.
[01:51] <infinity> Worse than jp_JP, and I didn't think that was possible.
[01:58] <fabbione> Kamion: in yaboot-installer/rescue.d/80...
[01:58] <fabbione>         db_input critical yaboot-installer/ybinerr
[01:58] <fabbione> shouldn't that one be || true ?
[01:59] <Kamion> cdebconf always displays error templates so it doesn't really matter
[02:00] <fabbione> ok
[02:00] <infinity> Kamion : You know, the quicker fix would just be to temporarily upload a lanpack-en that doesn't depend on the firefox locale...
[02:00] <Kamion> infinity: yeah, but ugh
[02:01] <Kamion> I'd rather not regress if we don't have to
[02:13] <Keybuk> infinity: can you, for my sanity, confirm that you're having those sata issues on 2.6.15-7 ... and not -6 ?
[02:15] <infinity> Keybuk : I saw it a total of once on -6, but it may have been unrelated.  I get it every boot on -7
[02:15] <infinity> (Well, every boot but that one where it worked..)
[02:20] <Keybuk> right
[02:20] <Keybuk> of course, we're looking at entirely the wrong subsystem :p
[02:22] <Keybuk> real IDE drivers seem to not led modprobe complete until they've taken ownership of the drives they wanted
[02:22] <infinity> What do you mean by "real IDE"?
[02:22] <Keybuk> SUBSYSTEM=="ide"
[02:22] <infinity> Anything not libata?
[02:22] <Keybuk> as apposed to IDE-in-drag
[02:23] <Keybuk> as you've got a double-whammy-wait
[02:23] <Keybuk> you have to wait for the IDE subsystem to find the devices, then the SCSI subsystem to take them and export them
[02:23] <infinity> As I said, though, I THINK ide-generic is loading before libata even kicks in, but it's hard to tell.
[02:24] <Keybuk> yeah
[02:24] <infinity> Anyhow, movie, or I'll never get back to be Kamion's bitch, and he'll hate me forever.
[02:24] <Keybuk> after your movie, we'll have an initramfs play session
[03:06] <Keybuk> (diff: scsi-devfs/installer fixed -- new known: ide-generic beats sata)
[04:54] <Keybuk> hmm, ok
[05:00] <Keybuk> infinity: anyway, is your laptop free to do a little debugging
[05:13] <infinity> It can be made free.
[05:14] <infinity> Let me fire up the auxiliary laptop for IRC, and stop all the crap I'm doing on this one.
[05:17] <Keybuk> the modprobe in initramfs is the same as the real one, right?
[05:17] <Keybuk> it's not some Kamion busybox special?
[05:19] <jbailey> It should be, yes.
[05:19] <jbailey> The modprobe in busybox had issues on ppc64 so I ditched it. =)
[05:25] <infinity> Okay, IRC is on the laptop of doom.
[05:25] <infinity> Keybuk : Give me 5 mins for a smoke, then you have me for about 30 mins (more, if we're really getting somewhere interesting) before I pass out. :)
[05:31] <infinity> Keybuk : I'm all yours.  Hurt me.
[05:32] <Keybuk> ok, so reboot it WITHOUT "quiet" or "splash" and with "break=premount"
[05:32] <Keybuk> and scripts/init-premount/thermal if your laptop dies, like mine does :p
[05:33] <infinity> Hrm,I've only done this a dozen times today...
[05:33] <Keybuk> then UDEV_LOG=info udevd --daemon
[05:33] <Keybuk> this should mean you get the dmesg output and udevd log messages
[05:34] <Keybuk> so you can get a good idea of when things actually happen, relative to each other
[05:34] <Keybuk> then do:
[05:34] <Keybuk> udevplug -Bpci -Iclass=0x0[12] *; echo WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
[05:34] <Keybuk> or something
[05:34] <Keybuk> so in the middle of that log output, there'll be a great big scream, so you can get a rough idea of what finishes first
[05:35] <infinity> Hrm.  I get my scream at the end.
[05:36] <infinity> This wasn't what I was expecting.
[05:36] <infinity> You?
[05:36] <Keybuk> nope, me neither
[05:36] <Keybuk> ok
[05:36] <Keybuk> so that's kinda interesting
[05:36] <Keybuk> now, can you cat /proc/modules
[05:36] <Keybuk> in particular, the ones at the top
[05:37] <infinity> sd_mod, ata_piix, ahci, libata, scsi_mod, generic, ide_core
[05:38] <Keybuk> right, unless I'm going mad, none of those is a plain-old-IDE driver?
[05:38] <Keybuk> now, do you have a /dev/sda* ?
[05:38] <infinity> Yeah, I have /dev/sda*
[05:38] <Keybuk> what happens if you modprobe ide-generic now?
[05:39] <infinity> The good ol' I/O resource not free messages.  ie: nothing bad.
[05:39] <Keybuk> and you don't end up with /dev/hda ?
[05:39] <infinity> This is whaty I epxect from running things in this order.
[05:39] <infinity> No /dev/hda, right.
[05:39] <Keybuk> right,
[05:39] <infinity> I never have BOTH, only one or the other.
[05:39] <Keybuk> now, let's try that again (from a fresh reboot), but instead make a two-line shell-script that contains those two lines
[05:39] <Keybuk> beware the fact you don't have ^D
[05:40] <Keybuk> so echo '#!/bin/sh' > test.sh; echo 'udevplug -Bpci -Iclass=0x0101*' >> test.sh; echo WOOOO >> test.sh
[05:40] <infinity> I also have shit for scrollback, which sucks.
[05:40] <Keybuk> yeah, is more just whether it's an "at the end, or in the middle" thing
[05:41] <Keybuk> (uh, echo echo WOOO, clearly :p)
[05:42] <infinity> Alrighty.
[05:43] <infinity> Right. Two things of note.
[05:43] <infinity> 1) I forgot the UDEV_LOG. :)
[05:43] <infinity> 2) The script never returned.
[05:43] <infinity> Thanks, busybox.
[05:44] <Keybuk> heh
[05:44] <infinity> Never did echo either, so I think this is some kinda special going on here.
[05:44] <Keybuk> did you forget to run udevd all together?
[05:45] <infinity> Oh, right.  I ran into that a few hours ago when debugging this.
[05:45] <Keybuk> heh
[05:45] <Keybuk> udevplug will be sitting there waiting for udevd to start :p
[05:45] <infinity> Why does udevplug block indefinitely with no udevd running? :)
[05:45] <Keybuk> because that's what it's designed to do
[05:45] <Keybuk> not exit until the events you plugged have actually been handlecd
[05:45] <Keybuk> if that means waiting for udevd to start, that's what it means <g>
[05:46] <Keybuk> it actually exits after about 3 minutes anyway
[05:46] <infinity> Seems a bit obtuse. :)
[05:46] <Keybuk> *shrug*
[05:46] <Keybuk> udevd is always running
[05:46] <Keybuk> the alternative would be some evil, unreliable, "check udevd is running" check
[05:47] <Kamion> SCORE, got gfxboot to work
[05:47] <jbailey> alarm(10); echo "WTF are you doing that udev is taking so long?"
[05:47] <Keybuk> jbailey: pretty much, except it's alarm(180)
[05:47] <Keybuk> 10s is less time than my sound card driver takes to load <g>
[05:48] <Kamion> though judging from the way I just had to adjust nearly every setting on my monitor to make it look decent, it's using a video mode my monitor has never heard of before
[05:48] <jbailey> Ugh, really?
[05:48] <infinity> Keybuk : Okay, same result when run as a shell script.
[05:49] <Keybuk> meh
[05:49] <Keybuk> removing the ide-generic call fixes it every time, right?
[05:49] <infinity> Yup.
[05:49] <Keybuk> fair enough, I'll just assume what's really happening then :(
[05:49] <infinity> As does a massive sleep before the ide-generic call (for obviousl reasons)
[05:50] <Keybuk> right
[05:51] <infinity> Is it possible udevd behaves differently (other than the syslog output) when UDEV_LOG is set to info?
[05:51] <infinity> Anyhow, let me try this again, with the modprobe in there.
[05:51] <infinity> And see where it happens.
[05:51] <Keybuk> yeah, it goes slower
[05:51] <Keybuk> mayyybe try without that, and just with dmesg
[05:55] <infinity> No dmesg in initramfs.  I suppose I should copy it over.
[05:56] <infinity> Anyhow, running 'udevplug blah blah' followed by 'modprobe ide-generic' (basically what init-premount/udev does) didn't break with udevd running with info-level logging.
[05:57] <infinity> This is a rather fragile race, if it's a race at all.  Or we've completely mis-diagnosed it.
[05:59] <Keybuk> and what about without info-level logging?
[06:00] <Keybuk> so far this _feels_ like a race ... it's of the "hides when you try and debug it" variety
[06:00] <infinity> I'm booting so I can add dmesg to my initramfs. :)
[06:00] <Keybuk> Fly On The Wall Bug
[06:00] <Keybuk> changes when you point the debugger at it
[06:00] <Keybuk> heh, why?  just boot without quiet, then you get dmesg spat all over the console
[06:01] <Keybuk> "xg" ?
[06:01] <Keybuk> what happened to pitti server 2005 ?
[06:01] <pitti_xg> Keybuk: I'm trying xchat-gnome :)
[06:01] <infinity> Yeah, but no backscroll in said dmesg.
[06:01] <infinity> Meh.
[06:02] <infinity> Remind me to add that DEBUG flag next week.
[06:02] <pitti_xg> heh
[06:02] <infinity> I'm taking suggestions on what we want copied in there as of now. :)
[06:03] <Keybuk> lsmod, dmesg, udevmonitor, lspci, lsusb
[06:03] <Keybuk> syslog?
[06:03] <Keybuk> less, vi
[06:03] <infinity> nvi, or nano?
[06:03] <infinity> Or I could upload ae to universe and impose my own view of the world on you.
[06:03] <Keybuk> some kind of stty stuff to make ^C and ^D work
[06:03] <infinity> Muahaha.
[06:03] <Keybuk> nvi, it's a sysadmin area
[06:07] <infinity> Hrm, some echoing would have been smart there.
[06:07] <infinity> I broke it successfully, though.
[06:08] <infinity> I hope the echoing doesn't slow it down enough to unbreak it.
[06:10] <Keybuk> that would be a bitch -- echo being slower than modprobe <g>
[06:10] <Kamion> hey, udevmonitor's only 6K
[06:10] <Kamion> would that be useful in the installer?
[06:10] <Kamion> I tend to think so ...
[06:11] <infinity> Damnit.  echo made it work.
[06:12] <infinity> That SCREAMS race now.
[06:12] <infinity> The only difference between the broken script and working script was an echo statement between the udevplug and the modprobe.
[06:13] <Keybuk> Kamion: you can have it in there if you want
[06:14] <Keybuk> infinity: yup, almost certainly a race then
[06:14] <Keybuk> well, that's nice to know
[06:14] <Keybuk> btw, if you omit the udevplug call, do you get the same behaviour ? :p
[06:15] <infinity> If I just modprobe ide-generic?
[06:15] <Keybuk> yup
[06:15] <Keybuk> just to make reallly sure that's the culprit here
[06:16] <infinity> Yeah, ide-generic does what one would expect, give me geenric IDE drives.
[06:17] <Keybuk> right
[06:17] <Keybuk> now what if you do this
[06:17] <Keybuk> udevd --daemon
[06:17] <Keybuk> modprobe ata_piix
[06:18] <Keybuk> modprobe ide-generic
[06:20] <infinity> D'oh, I just rebooted.
[06:20] <infinity> I think 4:20am may be past my bedtime.
[06:23] <infinity> modprobe ata_piix ; modprobe ide-generic was so close to racing, it's no funny.
[06:23] <infinity> If my shell were faster, maybe it would have broken.
[06:23] <infinity> (the ide-generic output in dmesg was interlaced with the ata_piix output, but just late enough that ata_piix seemed to claim the driver first...)
[06:23] <infinity> s/driver/drive/
[06:26] <Keybuk> heh, it's meeting time in 8 hours :p
[06:26] <Kamion> Keybuk: udevmonitor in udev-udeb> yes please
[06:27] <infinity> Okay, rebooting the laptop to normal land and going to try to sleep before the meeting.
[06:28] <Keybuk> right, so it definitely is a race then
[06:32] <infinity> Certainly smells like one.
[06:55] <Kamion> (I know you want it removed, but I don't want to be the one pressing that button :-))
[07:01] <Keybuk> why is it still in the archive?
[07:01] <Keybuk> elmo: WHY? WHY? WHY?
[07:01] <Keybuk> uh, -ENOELMO
[07:11] <Keybuk> Kamion: would you like udevinfo and udevtest in there too?
[07:13] <Kamion> Keybuk: udevinfo probably yes, udevtest seems a bit more nebulous given the size
[07:14] <Keybuk> right, I don't tend to use udevtest much -- it's often easier just to punt it through udevd again and see what happens :)