**** BEGIN LOGGING AT Thu Nov 09 02:59:57 2006 Nov 09 03:21:22 anyone around? Nov 09 09:25:59 anyone about ? Nov 09 09:41:20 matttt: best just to ask Nov 09 09:46:02 I can see the hdd attached to port Disk1, as /dev/sdb1,sdb2 and sdb3 Nov 09 09:46:17 how do I erase everything and start again ? Nov 09 09:47:30 It shows a drive in the web console, but Format doesn;t seem to do anything. Nov 09 09:58:39 matttt: what firmware are you running? Nov 09 09:59:46 V2.3R63-uNSLUng-6.8-beta Nov 09 10:00:11 I'm trying to unsling again. Nov 09 10:01:09 Error: /share/hdd/data appears to have already been unslung to: Nov 09 10:03:31 the web i/f keeps saying theres a scandisk happening but there isn;t. Nov 09 10:03:42 matttt: firstly, this channel is for SlugOS, not Unslung, so not many here will be able to help you. #nslu2-general is the channel for Unslung user questions Nov 09 10:04:06 oh, sorry. Nov 09 10:04:09 np Nov 09 10:04:13 see you thre Nov 09 11:42:18 rwhitby: any idea why udev isn't running my script when a device is UNplugged? Nov 09 11:43:34 tzanger: no idea Nov 09 11:45:06 http://pastebin.ca/244157 Nov 09 11:45:08 that's the script Nov 09 11:45:34 BUS=="usb", SYSFS{product}=="Belkin Components", KERNEL=="ttyUSB*", SYMLINK+="gps2treo", RUN+="/root/gpspassthrough.sh" Nov 09 11:45:37 BUS=="usb", SYSFS{product}=="USB-Serial Controller", KERNEL=="ttyUSB*", SYMLINK+="gps", RUN+="/root/gpspassthrough.sh" Nov 09 11:45:52 and those are teh two lines in udev.rules that invoke it Nov 09 12:00:55 tzanger: I'm not a udev expert. Nov 09 12:05:41 <[g2]> tzanger I hook GPS up to my Loft Nov 09 12:05:45 rwhitby: sucks to be me. :-( Nov 09 12:05:52 [g2]: do you use udev at all? Nov 09 12:06:29 <[g2]> I think I use stty to set the buad rate and a "C" program to directly access the port Nov 09 12:06:43 <[g2]> I have a tiny 2MB jffs2 system Nov 09 12:07:02 <[g2]> it boot starts the GPS and logs all the GPS raw data to a file Nov 09 12:07:29 <[g2]> based on date/timestamp Nov 09 12:07:55 <[g2]> apply power and in about 20-25 seconds data is being logged Nov 09 12:08:17 <[g2]> I'm working on a GPS product right now and that was all proof-of-concept Nov 09 20:35:18 Anyone running SlugOS/LE, and would not be in a position to move to Debian/NSLU2 ? If so, why? Nov 09 20:35:40 Because I run from flash only ;-) Nov 09 20:35:59 bloat Nov 09 20:36:06 (And value the speed advantage SlugOS/LE has over Debian/NSLU2) Nov 09 20:36:09 or if that is too harsh: 'size' Nov 09 20:36:15 So why use /LE then? Why not use /BE for the networking speed advantage? Nov 09 20:36:26 (I'm only talking about SlugOS/LE, not SlugOS in general) Nov 09 20:36:31 Portability issues Nov 09 20:36:47 ok, that's a good answer I didn't think of Nov 09 20:37:18 I'm not trying to be negative in any way. SlugOS/LE is perfect for one of my needs. SlugOS/BE is perfect for another. Nov 09 20:37:28 I'm going to rename DebianSlug, cause SlugOS/LE should no longer be used for Debian since the goal of getting the installer up to scratch has been met. Nov 09 20:37:39 NAiL: what's a better name for SlugOS/LE ? Nov 09 20:37:39 Good Nov 09 20:37:48 I'm tired of the confusion, tbh Nov 09 20:37:53 me too. Nov 09 20:38:20 LEetSlug ? Nov 09 20:38:34 hehe ;) Nov 09 20:38:40 I'm lousy with names Nov 09 21:20:31 rwhitby: same here. FLash only. slim and fast. Nov 09 21:21:13 * NAiL notes VoodooZ won't be happy with the bootkernel proposal Nov 09 21:21:24 VoodooZ: but why LE instead of SlugOS/BE ? Nov 09 21:21:26 which is? Nov 09 21:21:36 oops. sorry. I read it too fast. Nov 09 21:21:44 Basic default slugos is fine with me. Nov 09 21:21:56 Whatever endianess that is. :) Nov 09 21:22:03 right - so you stay with OpenSlug Nov 09 21:22:32 although the endianess bit me a few times while interfacing via i2c to other devices. Nov 09 21:22:38 yep Nov 09 21:22:45 VoodooZ: redboot -> tiny initial kernel w/initramfs -> load microcode and stuff -> kexec full kernel -> proper userspace. Nov 09 21:23:10 'tis a suggestion at the time Nov 09 21:23:13 yeah. I read that quickly. Let me guess. an even slower boot! Nov 09 21:23:18 yes Nov 09 21:23:28 F___! Nov 09 21:23:44 alternative 2 is using apex as a second stage bootloader Nov 09 21:24:03 I guess I can't bitch too much considering i'm the only one that cares about boot speed. Nov 09 21:24:17 Most other people (the devs) care about flexibility. Nov 09 21:24:18 you're not the only one, but you're the most extreme ;-) Nov 09 21:24:26 hehehe damn right! Nov 09 21:24:27 (understandably) Nov 09 21:24:45 are you running apex on your slug(s)? Nov 09 21:24:46 Even with all the frills and bloat removed it's ~30sec which frankly sucks! Nov 09 21:24:51 yep Nov 09 21:24:58 mmhmm Nov 09 21:25:25 if the initial kernel thingy goes through, it doesn't mean you're screwed though ;-) Nov 09 21:25:33 <[g2]> VoodooZ in BE it's < 15 seconds from power to busybox pompt on the loft for a busybox shell Nov 09 21:25:50 <[g2]> it's <10 from exec Nov 09 21:26:07 <[g2]> and I think there's a 3 second delay in redboot Nov 09 21:26:14 VoodooZ: btw, you might want to check out adjusting the flash timings in apex before loading the kernel. That might speed things up noticeably. Nov 09 21:26:20 well, the fact is I'm not knowledgeable (or motivated!) enough to make custom changes. Nov 09 21:26:44 * VoodooZ hates [g2]. Nov 09 21:26:46 ;-) Nov 09 21:26:52 (not that I know if apex can adjust them without added code though) Nov 09 21:27:36 that's what people expect out of an "appliance" type of box. instant on! Nov 09 21:28:31 NAiL: nice. do you have any docs for that flash tweak. Nov 09 21:28:49 not at all. Someone mentioned either here or in #nslu2-linux Nov 09 21:29:15 cool. I'll check in yahoo groups. Nov 09 21:29:19 the timings are way too high for the flash used in nslu2-linux Nov 09 21:29:27 I'm a bit paranoid to reflash it though. Nov 09 21:29:50 oh, you don't have jtag? Nov 09 21:29:59 I feel lucky It worked the first time! Nov 09 21:30:07 nope. that's the problem. Nov 09 21:30:20 even then, that's a whole extra hobby. Nov 09 21:31:12 I wanted to look into the upstart/initng initscript replacements but it's going to be way too complicated. Nov 09 21:31:36 it's quite probably going to take more time, considering the initscripts on the slug is simple Nov 09 21:31:48 true. Nov 09 21:32:19 I have a blank. What is the default endianess on openslug? Nov 09 21:32:36 but if you're booting from flash only, adjusting the timings should improve the boot times markedly Nov 09 21:32:39 BE Nov 09 21:34:00 ok. Nov 09 21:34:10 so you're saying BE is faster overall? Nov 09 21:34:33 atleast until NPE-C is used as a DMA engine Nov 09 21:34:43 cool. Nov 09 21:34:56 maybe I'll get a Loft for my next bot. Nov 09 21:35:13 The plan appears to be to use the open driver, and use NPE-C to compensate for the endianness conversions when running in LE Nov 09 21:35:13 anyways. I have to leave work so I'll be back in a few minutes... Nov 09 21:35:24 later Nov 09 21:35:24 ok :) Nov 09 21:35:38 we'll talk about the whole libc/angstrom too. :) Nov 09 21:35:43 brb Nov 09 21:38:50 anyone know how to repartition the flash from redboot? Nov 09 21:39:01 the kernel partition on the thecus is too small for the kernel I've compiled :-\ Nov 09 21:39:01 <[g2]> NAiL sure Nov 09 21:39:15 <[g2]> on sane RedBoot anyway Nov 09 21:39:25 thecus' RB appears to be sane Nov 09 21:39:37 It even passes correct ATAG :) Nov 09 21:39:49 (on the latest revision, atleast) Nov 09 21:39:53 <[g2]> NAiL you'll have to make room for it Nov 09 21:40:09 <[g2]> and it's probably up against the partition that's after it Nov 09 21:40:26 yeah, but that's the "user" partition, and tbh, I don't really need that partition at all Nov 09 21:40:39 <[g2]> then just delete both partitions Nov 09 21:40:41 (and from what I can see, RB doesn't touch it either) Nov 09 21:41:08 <[g2]> NAiL well, backup the partitions and a copy of the FIS layout Nov 09 21:41:20 neh, backups are for wusses :-P Nov 09 21:41:50 <[g2]> after the backup then just "fis delete" the partitions Nov 09 21:41:57 <[g2]> then dl the kernel Nov 09 21:41:57 done Nov 09 21:41:58 done Nov 09 21:42:09 Raw file loaded 0x00800000-0x0096748b, assumed entry at 0x00800000 Nov 09 21:42:29 <[g2]> what's the flash address Nov 09 21:42:40 <[g2]> is this right after RedBoot ? Nov 09 21:42:46 kernel 0xF0D40000 0x00200000 0x00160000 0x00200000 Nov 09 21:43:08 no, Redboot, ramdisk, kernel is the order of the partitions Nov 09 21:43:09 <[g2]> is that the current kernel ? Nov 09 21:43:32 The file I've loaded is the new kernel, and the kernel partition line I pasted was the previous partition Nov 09 21:44:05 so it needs to start at 0xF0D40000 and be atleast 0x16748b long Nov 09 21:44:41 <[g2]> ok so fis del the kernel Nov 09 21:44:47 that's done Nov 09 21:45:25 <[g2]> fis create -b 0x800000 -l 0x200000 -e 0xF0D40000 -f 0xf0d40000 kernel Nov 09 21:45:49 sure? :) Nov 09 21:45:54 * [g2] assumes F0D40000 is the flash address Nov 09 21:46:01 yeah Nov 09 21:46:11 <[g2]> help fis Nov 09 21:46:25 <[g2]> -b is the binary address Nov 09 21:46:27 fis create -b -l [-s ] Nov 09 21:46:28 [-f ] [-e ] [-r ] [-n] Nov 09 21:46:51 -b is where the new kernel is loaded in ram? Nov 09 21:46:51 are there any known problems with the openslug optware compiler and floating point? There's meniton of gpsd building incorrectly due to it, but I'm not usre if it's the optware build environment he's talking about Nov 09 21:47:10 tzanger: openslug doesn't use optware Nov 09 21:47:25 <[g2]> NAiL nod on the -b Nov 09 21:47:38 NAiL: hmm; I'm using the optware build system to build third party apps Nov 09 21:47:51 I thought that optware was *just* that section of openslug's development environment Nov 09 21:48:15 tzanger: no, openslug builds everything through openembedded. unslung uses optware Nov 09 21:48:29 kernel 0xF0D40000 0xF0D40000 0x00200000 0xF0D40000 Nov 09 21:48:38 ohhhhhhhhh Nov 09 21:48:38 hmm Nov 09 21:48:45 NAiL: hmm, I wonder if that is my problem Nov 09 21:48:48 [g2]: why is the second number cmopletely different? Nov 09 21:49:01 what's the channel for unslung? Nov 09 21:49:22 nslu2-general, I guess Nov 09 21:49:25 aha Nov 09 21:49:26 thanks Nov 09 21:49:34 #nslu2-linux would work if it's dev questions ;) Nov 09 21:50:40 :-) it kind of is, but I'll start in -general Nov 09 21:50:41 thanks Nov 09 21:51:03 [g2]: the second and fourth number is different from the original partition (#3 obviously is since it's length). Should it be? Nov 09 21:51:14 original: kernel 0xF0D40000 0x00200000 0x00160000 0x00200000 Nov 09 21:51:23 new: kernel 0xF0D40000 0xF0D40000 0x00200000 0xF0D40000 Nov 09 21:54:08 <[g2]> NAiL I think you may have wanted -r instead of -e Nov 09 21:54:31 <[g2]> I often get the two switched Nov 09 21:55:23 <[g2]> and you may want an address of 0x200000 Nov 09 21:55:53 <[g2]> you can just retype the fis create command and it'll ask if you want to overwrite Nov 09 21:58:17 ah, change entry point too? Nov 09 21:59:43 [g2]: ping? Nov 09 21:59:48 <[g2]> NAiL pong Nov 09 21:59:59 change the entry point too? Nov 09 22:00:09 <[g2]> just need a -e of 0x200000 Nov 09 22:00:17 <[g2]> that's the 2M entry point Nov 09 22:01:42 <[g2]> NAiL all done ? Nov 09 22:02:14 yup Nov 09 22:02:16 and it boots Nov 09 22:02:20 well, kinda Nov 09 22:02:25 it loads the kernel and executes it Nov 09 22:02:30 <[g2]> nod Nov 09 22:02:37 but for some reason it doesn't use the script I've stored Nov 09 22:02:46 do you have any idea why? :) Nov 09 22:02:54 <[g2]> is it overridden by the fconfig ? Nov 09 22:02:55 if I run fconfig, it shows the script I've stored Nov 09 22:03:06 but when I reset, it runs another script Nov 09 22:03:12 <[g2]> and the cmdline is different right ? Nov 09 22:03:17 yeah :-\ Nov 09 22:03:36 <[g2]> NAiL there was an override in the nslu2 linux repo for the cmdline Nov 09 22:03:48 yeah, I know Nov 09 22:03:51 <[g2]> I always disabled that for the Loft Nov 09 22:04:13 <[g2]> but I don't know if that's there anymore Nov 09 22:04:15 but I shouldn't need to use that on the n2100, since it actually can store the config I put in. I just can't figure out why it's using another cmdline. Nov 09 22:05:27 <[g2]> well that should be pretty easy to figure out Nov 09 22:05:33 anyway, thanks a bunch for the fis stuff :) Nov 09 22:05:37 oh, how? Nov 09 22:06:04 <[g2]> where the kernel dumps the cmdline print the address and cmdline with a printk Nov 09 22:06:25 <[g2]> unless that's in the real early assembler stuff Nov 09 22:07:34 ah, it's not using any overrides and stuff. RedBoot passes a cmdline, but for some reason I can't overwrite it with fconfig, even though fconfig actually stores the cmdline I write... Nov 09 22:08:20 <[g2]> ok, so exec -c "foo" works, but from fconfig it doesn't ? Nov 09 22:08:43 yeah. It uses a bootscript from somewhere else apparently... Nov 09 22:09:07 == Executing boot script in 1.000 seconds - enter ^C to abort Nov 09 22:09:07 RedBoot> fis load ramdisk Nov 09 22:09:07 RedBoot> fis load kernel Nov 09 22:09:07 RedBoot> exec -c "console=ttyS0,115200 root=/dev/ram0 initrd=0xa0800000,42M mem=128M@0xa0000000" Nov 09 22:09:17 That's the script it executes Nov 09 22:09:32 <[g2]> do a fconfig -l Nov 09 22:09:37 Boot script: Nov 09 22:09:37 .. fis load kernel Nov 09 22:09:37 .. exec -c "console=ttyS0,115200 root=/dev/sda3 mem=128M@0xa0000000" Nov 09 22:09:43 That's the part from fconfig -l Nov 09 22:09:54 (which is correct) Nov 09 22:10:33 <[g2]> NAiL when you manually run it it works right ? Nov 09 22:10:40 yup, without a hitch Nov 09 22:10:49 <[g2]> so the exec command is working properly Nov 09 22:11:00 yup Nov 09 22:11:15 the redboot is sane: Nov 09 22:11:18 RedBoot> exec -c "console=ttyS0,115200 root=/dev/ram0 initrd=0xa0800000,42M mem=128M@0xa0000000" Nov 09 22:11:21 Build ATAG Nov 09 22:11:24 ATAG_MEM: Overwrite ram_end with real_region_top=0x08000000, memsize=128 M Nov 09 22:11:26 ATAG_MEM=134217728@0xa0000000, MACH_TYPE=1101 Nov 09 22:11:28 (except it passes the wrong cmdline) Nov 09 22:11:30 Using base address 0x00200000 and length 0x00200000 Nov 09 22:11:32 Uncompressing Linux.............................................................................................. done, booting the kernel. Nov 09 22:11:51 <[g2]> so there's some disconnect between fconfig and the bootscript Nov 09 22:11:58 yeah :-\ Nov 09 22:12:12 <[g2]> 1.92 ? Nov 09 22:12:26 Red Hat certified release, version 1.93 - built 19:55:20, Aug 8 2006 Nov 09 22:12:46 I do have the sources, but no idea where to look. Nov 09 22:13:00 * [g2] out of curiosity would strings RedBoot Nov 09 22:13:27 <[g2]> and the whole flash if I didn't find the other cmdline string Nov 09 22:13:56 <[g2]> just to get an idea of where it's coming from Nov 09 22:14:05 *booting Nov 09 22:14:06 * Nov 09 22:14:52 hmm Nov 09 22:15:27 oops Nov 09 22:15:45 it appears I don't have access to flash after booting for some reason Nov 09 22:17:45 [g2]: ok, you know a bit about this flash stuff. Is the flash accessible in the physical memory map ? Nov 09 22:18:42 <[g2]> NAiL not really, but you can dd from the partitions Nov 09 22:18:59 yeah, if I had /dev/mtd* Nov 09 22:19:04 but they don't show up :-\ Nov 09 22:19:09 <[g2]> mknod Nov 09 22:19:13 <[g2]> it's your friend Nov 09 22:19:29 <[g2]> mknod /dev/mtdblock0 b 31 0 Nov 09 22:19:35 dmesg doesn't say anything about flash... Nov 09 22:19:49 <[g2]> is this DoC ? Nov 09 22:19:54 no, Intel Nov 09 22:21:48 I'm probably missing something in the kernel config, but I don't know much about flash Nov 09 22:29:32 If I could get the bootscript to work properly, I could finally get rid of the ramdisk partition, speeding up the boot a bit Nov 09 22:33:17 <[g2]> NAiL I'm sure you will Nov 09 22:34:55 * NAiL goes to bed Nov 09 22:56:36 <[g2]> sweet dreams NAiL Nov 09 23:03:41 um...is openslug be or le, I can *never* remember Nov 09 23:04:34 be Nov 09 23:06:18 <[g2]> BE Nov 09 23:06:31 * [g2] can never forget :) Nov 09 23:12:46 hmm Nov 09 23:13:03 okay how do I go about building my own package to the openembedded build? Nov 09 23:15:10 the "adding a new package" manual entry is just a stub Nov 09 23:15:49 I can't start explaining it right now, but the openembedded.org wiki should give you quite a few hints Nov 09 23:15:56 http://www.openembedded.org/user-manual&dpage=ch02s04 <- that one? Nov 09 23:16:04 "Writing Meta Data (Adding packages)" Nov 09 23:16:06 what koen said ;-) Nov 09 23:16:10 doesn't look empty to me Nov 09 23:16:54 koen: I believe he meant on the nslu2-linux wiki Nov 09 23:16:56 no Nov 09 23:16:57 http://www.openembedded.org/user-manual&dpage=ch05s03 Nov 09 23:17:02 oh Nov 09 23:17:08 * NAiL just goes to bed :-P Nov 09 23:17:20 but gpsd is already there.. how do I tell openembedded/bitbake to make the package for me? Nov 09 23:17:30 'bitbake gpsd' Nov 09 23:17:31 someone showed me a crazy incantation to make just the kernel but I've forgotten it Nov 09 23:17:36 koen: that's *far* too simple :-) Nov 09 23:17:42 'bitbake virtual/kernel' Nov 09 23:17:49 cd openslug && source setup-env && bb gpsd Nov 09 23:17:56 ah right Nov 09 23:18:04 the openslug obfuscation Nov 09 23:18:22 sets up all the vars you need ;-) Nov 09 23:18:26 aha Nov 09 23:18:30 okay I'll try that Nov 09 23:18:41 see if it's the unslung compiler env that is buggered Nov 09 23:21:16 I have to try getting xfs going again Nov 09 23:21:21 but the gps thing is higher priority for me ofr now Nov 09 23:22:45 I'm gonna have to see about using OE to build more of the things I want Nov 09 23:22:50 too bad OE doesn't work with m68knommu Nov 09 23:25:14 patches accepted Nov 09 23:26:40 koen: I'm not shying away from that (I've subitted a few to the uclinux project which is what I currently use) but it seemed that openembedded was pretty unfriendly towared m68knommu Nov 09 23:26:52 does OE work on *any* nommu systems? Nov 09 23:27:02 sure Nov 09 23:27:11 it even works on msp430 systems Nov 09 23:27:19 hmm I may have to take a closer look Nov 09 23:27:45 if gcc knows it, OE can build for it Nov 09 23:28:31 :-) Nov 09 23:33:00 hmmm Nov 09 23:33:07 woglinde didn't apply the msp patch yet Nov 09 23:33:08 * tzanger grrs Nov 09 23:33:13 but you can see it at http://page.mi.fu-berlin.de/~heinold/msp430.diff Nov 09 23:33:18 gpsd won't build since expat has a patch that fails Nov 09 23:34:12 NOTE: package expat-2.0.0-r2: task do_patch: started Nov 09 23:34:13 NOTE: Applying patch 'autotools.patch' Nov 09 23:34:13 NOTE: package expat-2.0.0-r2: task do_patch: completed Nov 09 23:34:14 ? Nov 09 23:34:22 wtf Nov 09 23:35:00 NOTE: package expat-2.0.0: started Nov 09 23:35:00 NOTE: package expat-2.0.0-r1: task do_fetch: started Nov 09 23:35:00 NOTE: package expat-2.0.0-r1: task do_fetch: completed Nov 09 23:35:00 NOTE: package expat-2.0.0-r1: task do_patch: started Nov 09 23:35:02 ERROR: function do_patchcleancmd failed Nov 09 23:35:48 the log shows the quilt command spitting out its help Nov 09 23:36:16 and this is r1.. Nov 09 23:39:06 I edited the .bb file for expat to grab r2, hope that owrks Nov 09 23:39:19 nope same issue Nov 09 23:39:24 maybe my version of quilt's old Nov 09 23:39:46 OE builds its own version of quilt Nov 09 23:39:54 unless you instruct it otherwise Nov 09 23:40:33 like saying ASSUME_PROVIDED += "quilt-native" or something like that Nov 09 23:40:44 yeah I don't have a version on my system Nov 09 23:40:47 its' the openembedded one Nov 09 23:41:17 this is 3.10-beta... is that ok?? Nov 09 23:41:38 ? Nov 09 23:41:45 what's 3.10 beta? Nov 09 23:41:54 it's all from the openslug-3.10-beta Nov 09 23:41:59 er Nov 09 23:42:03 slugos-3.10-beta Nov 09 23:43:18 http://ftp.osuosl.org/pub/nslu2/releases/ <-- that still shows 3.10-beta as the latest Nov 09 23:44:34 the last slugos I built 2.7 or something Nov 09 23:45:05 nevermind Nov 09 23:45:08 after that I just pestered g2 and nail for binaries Nov 09 23:45:09 it's something screwy on my laptop Nov 09 23:45:14 on my other system it seems to be happy Nov 09 23:45:35 sorry to bother you with this crap, ugh Nov 09 23:46:26 it's not as bad as spending 4 days to figure out 'noexec' is the culprit for "not a valid interpreter" Nov 09 23:48:28 ouch Nov 09 23:51:09 heh, it's gotta build glib first. Nov 09 23:51:14 I'll be here a while Nov 10 00:08:10 woo Nov 10 00:08:44 openembedded compiler's good. unslung's (optware) is not Nov 10 00:08:44 gpsd works just fine with oe's compiler Nov 10 00:12:10 preaching to the choir :) Nov 10 00:14:52 :-) Nov 10 00:24:45 tzanger: optware compiler is designed for compatibility with hacked linksys libraries. I wouldn't recommend it for any other use. Nov 10 00:25:12 but someone should see whether we can use a more recent compiler and get the same compatibility ... Nov 10 00:37:09 so the OE compiler's *older* ? Nov 10 00:46:23 no, the OE compiler is newer Nov 10 01:28:18 rwhitby: oh to answer my question from earlier.. why udev wasn't executing the script on a remove action Nov 10 01:28:38 udev does not seem able to say "THIS usb device is being removed" only "a usb device is being removed" Nov 10 01:28:54 basically SUBSYSTEM=="usb" is all you can trap on to get a remove action Nov 10 01:29:13 SUBSYSTEM=="usb", ACTION=="remove", RUN+="usb-removescript.sh" Nov 10 01:29:29 or SUBSYSTEM=="usb", RUN+="usb-someaction.sh" **** ENDING LOGGING AT Fri Nov 10 02:59:56 2006