=== JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-boot [12:58] Md adds the initramfs-tools hooks to udev. === JanC [n=janc@lugwv/member/JanC] has joined #ubuntu-boot [12:58] much smaller diff now.. :) [04:06] makx : Excellent. That should give me some motivation to look over the remaining diffs. === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-boot === HiddenWolf [n=HiddenWo@136.169.dynamic.phpg.net] has joined #ubuntu-boot [09:58] infinity: would be cool if ubuntu's land again in bzr. [09:58] my archive is public. [09:59] infinity: the evms split is the next step, already spoken with the evms maintainer. [09:59] bzr branch http://debian.stro.at/bzr-test/initramfs-tools/ [10:02] makx : Oh, you rule, I'll happily take that change. [10:02] makx : As for bzr, it'll happen. I'm just terminally lazy when it comes to such things. [10:03] infinity: i try to sync with ubuntu whenever possible. [10:03] there were some minor errors in Keybuk's latest changelog [10:03] That's because you're a far more diligent person than I am. :) [10:03] s/changelog/changes/ [10:04] (Or you have more spare time... Pick one) [10:04] Have you told him about them? [10:04] he removed support for the resume conf. [10:04] when splitting udev out. [10:04] I'm sitting around waiting for him to show up so I can give him shit about something in udev. :) [10:48] 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] otherwise it won't show up.. right? [10:50] fabbione: easiest way is probably to build a monolithic image from debian-installer with your changed udeb in build/localudebs/ [10:51] 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] Kamion: ok.. thanks [11:01] Kamion: is there a nice howto build udeb? [11:02] (looked at several rules ssh, udev everyone does it his way) [11:04] 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] 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] Kamion: ok thx. [11:06] installer/doc/devel/modules.txt in the d-i repo documents what features are/aren't supported in udebs [11:06] oh, and it has a two-minute primer at the end which is essentially what I just said :) [11:07] http://svn.debian.org/wsvn/d-i/trunk/installer/doc/devel/modules.txt?op=file&rev=0&sc=0 [11:08] 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] Command failed with status 1 : objdump --private-headers ./tmp/monolithic/tree/lib/md5client/checkpkg [11:13] With output: objdump: ./tmp/monolithic/tree/lib/md5client/checkpkg: File format not recognized [11:13] HMMMM [11:13] file checkpkg [11:13] checkpkg: ASCII English text [11:13] that's correct.. it's a shell lib [11:15] Kamion: any idea of what i am doing wrong? [11:24] put it in /usr/lib instead [11:25] hm ok [11:25] strange that it doesn't barf on lib/rescue.d [11:25] hmm [11:25] where exactly is it failing? [11:25] as in, a bit more context [11:25] at lib reduction [11:25] monolitich build [11:25] the three preceding lines of the output would be useful [11:26] oh, never mind [11:26] fabbione: put #! /bin/sh at the top [11:27] even if it isn't executed, that makes mklibs ignore it [11:27] ah ok [11:27] works for me [11:27] then it should be fine in /lib [11:30] yeps [11:30] thanks a lot === fabbione sighs [11:39] it's not my lucky day apparently [11:40] Kamion: can you tell me when you have 10/15 minutes to help me? i am need of help here :( [11:45] fabbione: now's fine [11:46] Kamion: ok thanks! [11:46] well i did build the monolith mini.iso [11:46] i boot with rescue/enable=true [11:46] or rescue from syslinux [11:46] but there is no rescue menu at all [11:46] i get pushed to the partitioner [11:46] did you include rescue-mode in your initrd? [11:46] if i to the main menu i can't see anything like rescue.. [11:46] I bet you only have rescue-chekc [11:46] ck [11:47] yeps [11:48] ok.. i guess that explain [11:48] why isn't it included by default? [11:48] I'll fix that upstream now; in the meantime, put rescue-mode in pkg-lists/monolithic/local [11:48] (given that we offer the rescue option at boot i mean) [11:48] yes i can do that.. [11:48] thanks [11:48] mostly I just forgot to include it there [11:48] ahhh ehehe [11:49] fixed === pitti [n=pitti@ubuntu/member/pitti] has joined #ubuntu-boot [11:50] i am building right now === pitti [n=pitti@ubuntu/member/pitti] has left #ubuntu-boot [] === pitti [n=pitti@195.227.105.180] has joined #ubuntu-boot === pitti [n=pitti@ubuntu/member/pitti] has left #ubuntu-boot [] === Keybuk [n=scott@descent.netsplit.com] has joined #ubuntu-boot [12:23] 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] i can see there are no templates from my pkg.. [12:24] does the rescue operations menu show up? [12:24] the rescue does [12:24] my entry in it doesn't [12:24] can you put your udeb somewhere? [12:25] sure [12:26] brz clone http://people.ubuntu.com/~fabbione/archives/md5client/ [12:26] just a sec.. it's still pushing [12:26] damn adsl [12:26] i need to kill my isp sooner or later [12:26] ok done [12:26] oh, just the udeb would do fine, if you could put it on rookery [12:26] but ok === Kamion gets [12:27] doing [12:27] people/~fabbione/md5client-udeb_0.1-0ubuntu1_all.udeb [12:28] bzr mv debian/md5client.templates debian/md5client-udeb.templates; sed -i 's/md5client/md5client-udeb/' debian/po/POTFILES.in; debconf-updatepo === fabbione sighs === fabbione feels hutterly dumb [12:29] oh and: echo '2 utf8' > debian/po/output [12:29] thanks Kamion [12:29] ... while you're at it [12:29] cdebconf can only deal with UTF-8 templates so forcing it is a good idea [12:29] thanks a lot [12:29] np [12:30] do i need to echo at build time? or just once? [12:30] no just once, then bzr add debian/po/output [12:30] that's fine in the source tarball [12:31] cool done === fabbione tests again [12:32] Keybuk : Feel like having someone be irrtated in your direction? [12:35] are they cute? [12:35] I dunno, am I? [12:37] :) [12:37] what's your problem? [12:38] nicely dodged [12:38] Hrmph. [12:38] I feel so rejected. [12:38] Anyhow. [12:39] udevplug appears to suck in some way I haven't yet fully diagnosed. [12:39] I suspect 'udevplug -W' doesn't actually work as advertised. [12:39] (Well, I'm pretty positive of that) [12:40] 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] 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] (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) === fabbione sends some love over IP to Kamion [12:42] works? [12:42] yup [12:42] rock on [12:42] it takes a long time to do a test [12:42] mainly because i need a CDreader in a machine [12:42] qemu isn't too bad for stuff that's early in the installer [12:43] for anything like full installs I find it way too slow [12:43] infinity: right, so how this works (in theory) is this [12:43] 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] the main issue is that to run the md5sum stuff can take WAYYYYY longer than install [12:43] + i still need an installed system to test against [12:43] udevd exposes it's queue of events its received from the kernel, but not yet completed processing of [12:43] Keybuk : In which case, 'udevplug -anythingelse' can't return until after it writes said semaphore, or you have a race. === fabbione wonders if qemu works on amd64 [12:44] it does that as a directory called /dev/.udev/queue which contains symlinks to the sysfs paths queued [12:44] now, udevplug "in normal operation" does the following [12:44] 1) wait for this directory to vanish [12:44] 2) make it again [12:44] 3) touch all the uevents [12:44] 4) wait for this directory to vanish [12:45] At which step does it return? [12:45] 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] step 5 [12:45] udevplug -W just does step 4 [12:45] fabbione: works on an amd64 *host* emulating i386, I'm not sure if it does amd64 targets yet [12:45] Keybuk : So it's udevd at fault here, not udevplug? [12:45] it's hard to define "at fault" [12:46] Keybuk : In that it clearly must have something in the queue, but it's not advertising it... Or something. [12:46] no, it's not that [12:46] it might be simply that it DOESN'T have anything in the queue [12:46] if the modprobe returns successfully, it's possible for the queue to become empty [12:46] while the IDE controller is still waking up, and rubbing the sleep out of its eyes [12:46] It's forked-and-forgot 20 modprobes that aren't done? [12:46] Hrm. [12:47] (returned, but not "done"...) [12:47] 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] Kamion: that would be perfect [12:47] it's the "no way of knowing an IDE/SCSI/USB controller is busy" problem [12:47] Keybuk : Then we have a problem... That ide-generic load just plain can NOT happen there. [12:47] right [12:47] now, that ide-generic modprobe is interesting [12:48] it was there because of a bug in our kernels [12:48] which I fixed [12:48] so in theeeory we can take that away now [12:48] but we still need it for cases where we don't have an IDE controller we know about [12:48] and again, we come to this "need to wait for the kernel" thing [12:48] 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] d if=/dev/urandom of=hda bs=4G count=1 [12:49] dd: memory exhausted [12:49] suck! :) [12:49] Keybuk : Hrm. Non-PCI controllers become an issue here, I guess. [12:49] yup [12:50] also I'm not sure, but I think we need ide-generic loaded to cope with pcmcia IDE devices too [12:50] 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] (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] right, that's kinda where I'm thinking of going for this [12:53] it had to wait until today, and the -7 kernel to be -meta [12:53] the trouble is "how long do we wait" ? :p [12:53] Yeah, scanning a real SCSI bus can take ages. [12:54] Any guarantees that SCSI devices will get scanned after IDE/SATA, perchance? [12:54] not currently [12:54] So we can "wait long enough for a reasonable full ATA scan, then give up" [12:54] Meaning it wouldn't matter if we're stuck in SCSI-land. [12:55] 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] I increasingly see why nobody else has tried to make a generic initramfs :p [12:56] We will prevail. [12:56] Somehow. :) [12:56] For now, though, I'd recommend any hack that doesn't land people like me where I am. [12:57] so here's my current theory [12:57] Real SCSI busses, while an important case to work on, are probably a corner case for people testing dapper right this instant. [12:57] we plug storage controllers, if we find at least one, we don't load ide-generic [12:57] if we don't find any, we load ide-generic [12:57] That's touchy. [12:57] why? [12:58] If you find my shitty SCSI card I have my scanner attached to, but not my root filesystem controller, I cry. [12:58] meh, good point [12:58] (In theory... I haven't had a SCSI scanner for years) [12:58] and I bet you $10 that your SATA controller doesn't advertise as one [12:59] Do they have a specific PCI class? [12:59] they tend to pretend to be PCI_CLASS_STORAGE_SCSI :p [12:59] or, more hilariously, PCI_CLASS_STORAGE_RAID [12:59] How would I find this out, out of curiosity? [01:00] lspci -n [01:00] (use ordinary lspci first if you don't know which line is your controller) [01:00] 0000:00:1f.2 0101: 8086:2653 (rev 03) [01:00] wow, it actually claims to be an IDE controler [01:01] most don't [01:01] yay Intel === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-boot [01:03] Keybuk: the kernel bug you mentioned is related to modular ide? [01:03] 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] makx : yes. [01:03] need to look up what you did with that strange Xu legacy. [01:03] 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] makx: http://people.ubuntu.com/~scott/fixed-ide.patch [01:04] makx: this is still the same bug we're discussing, the patch just makes it fixable === jbailey phases into the discussion. [01:05] The final problem that we hit was for controllers without a sexy chipset and that don't appear on the PCI bus. [01:05] jbailey: whiteholespewingtimeidedriverscansbusbutidegenericloadsandclaimsthedevicesbeforescanhascompleted [01:06] 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] Keybuk: why am i not hit with debian's udev? [01:06] And that's fine, but it has to happen way AFTER everything else it detected. [01:06] makx: ya know, I was never entirely sure of that [01:07] Keybuk: Yeah, well. I've said more than once that that I want bus scanning state to be visible from userspace. [01:07] Even if ther kernel's bus scans were. [01:07] I knwo that HW ones will always suck. [01:07] yeah, the problem with just waiting for devices to appear is the "what if there aren't any on that bus?" problem [01:09] oooooooh [01:09] does something appear in sysfs after the scan has completed, in the ide case [01:09] the scan takes place in the middle of the init [01:10] we could WAIT_FOR_SYSFS that [01:10] Well, hmm. You're not waiting for the scan of the IDE bus, right? [01:10] we are [01:10] Just the PCI bus so that all the DMAable controllers are found. [01:11] no, we're waiting for the IDE bus scan to complete [01:11] so we don't carry on and load ide-generic while the scan is still going on [01:11] What does it interfere with there? By that time, shouldn't the other controller have already allocated all the resources? [01:11] Keybuk: i saw no check of /dev/.udev/queue in your udev hooks. [01:12] 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] the ide scanning stuff doesn't hard-code the winning driver [01:12] makx: that's what udevplug does [01:12] that's the part requiring > 2.6.14 [01:13] ? [01:13] Keybuk: Wha? That's crazy. [01:13] I would've thought the IDE devices would be recognised as subdevices of their controller, and not be interfered with. [01:13] apparently not [01:14] at least, not where ide-generic is concerned [01:15] I need to sit down with the ide subsystem code, I think [01:16] The libata stuff isn't 2.6.15-bound is it? [01:16] Keybuk : I think the breakage happens in my case before libata is even loaded. [01:17] 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] I'm not sure we actually have a race AFTER libata starts scannind for devices. We might. That would be scary. [01:18] that shouldn't happen ... if tg3 is loaded first, then udevplug will still be blocking while ata_piix gets loaded [01:18] or, in theory, both get loaded at the same time, and udevplug waits for them both to complete [01:18] are you heading for bed soon, or are you still going to be up for a couple of hours? === fabbione feels the pain of qemu [01:19] 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] ok, grab me when you're up for some hot debugging action [01:19] want to poke around and see what is actually happening with your controller [01:20] 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] If you can script something to watch WTF is really going on behind the scenes... [01:20] Keybuk: while splitting udev out, you removed probably unintentionaly the initramfs.conf resume variable support. [01:20] (Of course, given the delicate race conditions at play, adding any more CPU usage may just make them go away) [01:21] Note that I actually booted successfully once, while all the other times were miserable failures. [01:21] 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] where shell ~= initramfs [01:21] That irritated me more than anything else... The debug boot that worked. [01:21] makx: that block was duplicated elsewhere [01:22] 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] Keybuk: oh indeed, hadn't seen that while going throught the diff. [01:23] infinity: Ah good. Keep this one. [01:23] She understands that programmers are most dangerous in the presence of XPASS. [01:24] infinity: how goes the m-f-l-a stuff? if it's part-done I could take over [01:24] Kamion : Smashingly, if I could figure out where the heck the rtlclassic theme comes from.. [01:27] you already know more than me, then :) [01:29] Maybe it's not required anymore... === infinity tests this theory. [01:36] Oh, hot diggity. We don't need rtlclassic anymore. [01:36] firefox does right-to-left natively. [01:38] Man, right-to-left menus really hurt my brain. [01:43] On second thought, this package may be too confusing for a man who's supposedly not working right now. [01:44] 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] Well, the orig is the problem, really. [01:45] 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] But the Right Way looks very... Odd. It's not a sane source package. :) [01:47] Alright, you want me to fix it in 2 hours, or you want to find another sucker? [01:48] two hours is fine [01:49] you've got it in your brain already :) [01:49] (if you don't mind too much) [01:49] Yeah, it's floating around up there. [01:49] 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] yeah [01:50] Off to watch a movie first, then back to bending my brain at firefox. [01:50] At least the lack of rtl theme dependencies is good news. [01:50] An he_IL is a confusing locale to use a computer in. [01:51] Worse than jp_JP, and I didn't think that was possible. [01:58] Kamion: in yaboot-installer/rescue.d/80... [01:58] db_input critical yaboot-installer/ybinerr [01:58] shouldn't that one be || true ? [01:59] cdebconf always displays error templates so it doesn't really matter [02:00] ok [02:00] 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] infinity: yeah, but ugh [02:01] I'd rather not regress if we don't have to [02:13] infinity: can you, for my sanity, confirm that you're having those sata issues on 2.6.15-7 ... and not -6 ? [02:15] 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] (Well, every boot but that one where it worked..) [02:20] right [02:20] of course, we're looking at entirely the wrong subsystem :p [02:22] real IDE drivers seem to not led modprobe complete until they've taken ownership of the drives they wanted [02:22] What do you mean by "real IDE"? [02:22] SUBSYSTEM=="ide" [02:22] Anything not libata? [02:22] as apposed to IDE-in-drag [02:23] as you've got a double-whammy-wait [02:23] you have to wait for the IDE subsystem to find the devices, then the SCSI subsystem to take them and export them [02:23] As I said, though, I THINK ide-generic is loading before libata even kicks in, but it's hard to tell. [02:24] yeah [02:24] Anyhow, movie, or I'll never get back to be Kamion's bitch, and he'll hate me forever. [02:24] after your movie, we'll have an initramfs play session === ..[topic/#ubuntu-boot:Keybuk] : known: oss drivers loaded, no network plugging, alsa rules not reloaded, mtab not updated, /dev/pts not mounted, ide-generic beats sata drivers || fixed: notify-reboot, vio_type segfault, no modules loaded, hal/pcmcia rules not reloaded, nfs root fails, sata root fails, pnp devices not loaded, init stop/start, grepmap bitching, fb drivers loaded, installer "devfs" rules [03:06] (diff: scsi-devfs/installer fixed -- new known: ide-generic beats sata) === HiddenWolf [n=HiddenWo@136.37.dynamic.phpg.net] has joined #ubuntu-boot === jbailey_ [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-boot [04:54] hmm, ok [05:00] infinity: anyway, is your laptop free to do a little debugging [05:13] It can be made free. [05:14] Let me fire up the auxiliary laptop for IRC, and stop all the crap I'm doing on this one. [05:17] the modprobe in initramfs is the same as the real one, right? [05:17] it's not some Kamion busybox special? [05:19] It should be, yes. [05:19] The modprobe in busybox had issues on ppc64 so I ditched it. =) [05:25] Okay, IRC is on the laptop of doom. [05:25] 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] Keybuk : I'm all yours. Hurt me. [05:32] ok, so reboot it WITHOUT "quiet" or "splash" and with "break=premount" [05:32] and scripts/init-premount/thermal if your laptop dies, like mine does :p [05:33] Hrm,I've only done this a dozen times today... [05:33] then UDEV_LOG=info udevd --daemon [05:33] this should mean you get the dmesg output and udevd log messages [05:34] so you can get a good idea of when things actually happen, relative to each other [05:34] then do: [05:34] udevplug -Bpci -Iclass=0x0[12] *; echo WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO [05:34] or something [05:34] 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] Hrm. I get my scream at the end. [05:36] This wasn't what I was expecting. [05:36] You? [05:36] nope, me neither [05:36] ok [05:36] so that's kinda interesting [05:36] now, can you cat /proc/modules [05:36] in particular, the ones at the top [05:37] sd_mod, ata_piix, ahci, libata, scsi_mod, generic, ide_core [05:38] right, unless I'm going mad, none of those is a plain-old-IDE driver? [05:38] now, do you have a /dev/sda* ? [05:38] Yeah, I have /dev/sda* [05:38] what happens if you modprobe ide-generic now? [05:39] The good ol' I/O resource not free messages. ie: nothing bad. [05:39] and you don't end up with /dev/hda ? [05:39] This is whaty I epxect from running things in this order. [05:39] No /dev/hda, right. [05:39] right, [05:39] I never have BOTH, only one or the other. [05:39] 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] beware the fact you don't have ^D [05:40] so echo '#!/bin/sh' > test.sh; echo 'udevplug -Bpci -Iclass=0x0101*' >> test.sh; echo WOOOO >> test.sh [05:40] I also have shit for scrollback, which sucks. [05:40] yeah, is more just whether it's an "at the end, or in the middle" thing [05:41] (uh, echo echo WOOO, clearly :p) [05:42] Alrighty. [05:43] Right. Two things of note. [05:43] 1) I forgot the UDEV_LOG. :) [05:43] 2) The script never returned. [05:43] Thanks, busybox. [05:44] heh [05:44] Never did echo either, so I think this is some kinda special going on here. [05:44] did you forget to run udevd all together? [05:45] Oh, right. I ran into that a few hours ago when debugging this. [05:45] heh [05:45] udevplug will be sitting there waiting for udevd to start :p [05:45] Why does udevplug block indefinitely with no udevd running? :) [05:45] because that's what it's designed to do [05:45] not exit until the events you plugged have actually been handlecd [05:45] if that means waiting for udevd to start, that's what it means [05:46] it actually exits after about 3 minutes anyway [05:46] Seems a bit obtuse. :) [05:46] *shrug* [05:46] udevd is always running [05:46] the alternative would be some evil, unreliable, "check udevd is running" check [05:47] SCORE, got gfxboot to work [05:47] alarm(10); echo "WTF are you doing that udev is taking so long?" [05:47] jbailey: pretty much, except it's alarm(180) [05:47] 10s is less time than my sound card driver takes to load [05:48] 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] Ugh, really? [05:48] Keybuk : Okay, same result when run as a shell script. [05:49] meh [05:49] removing the ide-generic call fixes it every time, right? [05:49] Yup. [05:49] fair enough, I'll just assume what's really happening then :( [05:49] As does a massive sleep before the ide-generic call (for obviousl reasons) [05:50] right [05:51]