**** BEGIN LOGGING AT Wed Apr 25 02:59:56 2007 Apr 25 05:02:46 Argh. My slug ate my flash drive again. :( Lots of bits magically get mixed around, and there's no log in the kernel logs. Apr 25 05:03:38 Is OpenSlug-BE known to do this stuff? Apr 25 05:04:36 00:04:14 up 17 days, 23:41 Apr 25 05:04:37 Nope Apr 25 05:05:03 That's running from a flash drive, too. Apr 25 05:05:15 http://pastebin.osuosl.org/1259 Apr 25 05:05:42 This is about the 4th time it's happened Apr 25 05:06:05 Upslug2'ing a new imagine will provide me with a working system for a few days, but then it does that Apr 25 05:06:30 That doesn't necessarily look like disk corruption to me. Apr 25 05:06:40 Looks like nano is broken. Apr 25 05:06:45 And you have a funny filename. Apr 25 05:06:53 That file didn't used to be there Apr 25 05:07:34 Mine does that all the time -- minicom sends garbage down the serial port, which creates bogus files everytime the shell sees the ">" character. Apr 25 05:07:47 hm Apr 25 05:07:52 No serial on this though Apr 25 05:08:08 If you have filesystem corruption, the fsck utility is what you would use to confirm that. Apr 25 05:08:27 I'll reboot it and run it off firmware then Apr 25 05:08:30 Otherwise I'm thinking you have bogus text coming in from your terminal emulator Apr 25 05:08:37 what are you using for a client? Apr 25 05:10:08 Just terminal and ssh Apr 25 05:14:41 Strange, fsck came up clean Apr 25 05:14:56 I wonder why nano would do that over multiple installs Apr 25 05:15:35 What do other text editors do? Could it be a terminal emulator problem - bogus text being sent to the NSLU2? Apr 25 05:15:48 hm Apr 25 05:16:03 Has there been any overheating issues pertaining to clocking it to 266? Apr 25 05:16:07 Maybe it's sending data in unicode or some other >8bit encoding? Apr 25 05:16:20 It worked when I first ipkg install nano'd though. Apr 25 05:16:28 Never been any overheating documented in any credible manner. Apr 25 05:16:44 Good to know then Apr 25 05:17:02 Those with the instruments to do it properly report minimal extra heat; basically if it dies it was pretty much cooking at 133 already. Apr 25 05:17:54 It may have worked, but perhaps something else changed. Config file? Maybe it doesn't know the term type on the other end? Apr 25 05:18:09 Maybe something replaced a library upon which nano depends? Apr 25 05:18:46 Perhaps Apr 25 05:18:49 I'd switch text editors to see if the funky garbage manifests only on nano, or if it also appears in some fashion on other editors (line and/or full-screen) Apr 25 05:19:05 I'll try emacs/vim Apr 25 05:19:18 Also consider switching the terminal emulator -- I would suggest trying PuTTY. Apr 25 05:19:53 er Apr 25 05:19:55 I'm on OS X Apr 25 05:20:55 tv104 utf8 ok? Apr 25 05:20:58 That's unfortunate. Apr 25 05:21:05 *vt104 Apr 25 05:21:11 I don't think that's ok. Apr 25 05:21:38 Perhaps, but I would be surprised if anything built for the slug can handle the full utf8 character set. Apr 25 05:22:27 Maybe, but I would try to find something that can do US/ASCII a la vt102 or vt100 or perhaps ANSI terminal emulation. Ugly, old, but the lowest common denominator. Apr 25 05:22:29 I've got xterm, I can just do vt102 with whatever charset I want Apr 25 05:22:38 Now that should work. Apr 25 05:23:16 Same junk :/ Apr 25 05:23:34 Although catting my nano file Apr 25 05:23:56 Well you'll see the same junk in the "ls" command, as the bogus files probably got created with those funky names. Apr 25 05:24:18 What does "echo $TERM" say on the NSLU2? Apr 25 05:24:52 http://pastebin.osuosl.org/1260 Apr 25 05:25:00 vt100 Apr 25 05:26:27 I see. Apr 25 05:26:52 Something wrote over your /usr/bin/nano file, replacing it with the text output from the nano "info" file. Apr 25 05:27:48 Strange Apr 25 05:27:58 It's not the nano "info" file, it's the as info file. Apr 25 05:27:59 :/ Apr 25 05:28:01 'as' Apr 25 05:28:06 As in the assembly compiler? Apr 25 05:28:45 Did you install any development tools? Apr 25 05:29:19 gcc, gcc-symlinks, libxml2, and libreadline Apr 25 05:29:35 Ok. Probably one of those packages did it. Apr 25 05:30:29 Either one of them is mis-packaged, or ipkg install did something very wrong and got confoosed about where to copy something, or a post-install script provided by a package messed up when it ran and did the dirty deed. Apr 25 05:30:39 hm Apr 25 05:30:49 ipkg remove nano && ipkg update && ipkg install nano fixed it Apr 25 05:31:19 Are you using the standard feeds, or did you add any new feeds other than the ones the firmware installs with? Apr 25 05:31:31 Nope, standard repos Apr 25 05:31:59 http://ipkg.nslu2-linux.org/feeds/slugos-bag/cross/3.10-beta/Packages.gz and native Apr 25 05:32:28 One thing I've been trying to build is microdc2, but it seems the implementation of binutils in the repo doesn't have creation support for 'ar'. Only extraction support. :/ Apr 25 05:32:32 Ok. If you can figure out with package messes up nano, that should be reported on the mailing list so that someone can correct that package - whatever is doign that is clearly wrong! Apr 25 05:32:42 yea Apr 25 05:32:54 Is there something like a world file where I can see what packages i've installed? Apr 25 05:33:08 should be in one of the files in /usr/lib/ipkg Apr 25 05:34:03 The default "ar" is almost certainly the busybox one -- that's probably brain-dead. Apr 25 05:35:00 Any package I could get to overwrite that bugger? It's cramping the Makefile's style. Apr 25 05:36:42 binutils should do it. Just be aware that binutils installs the tools with either funky names, or into a different set of directories. So /usr/bin/ar will usually continue to be the busybox ar. Apr 25 05:37:25 (unless someone implemented update-alternatives for binutils) Apr 25 05:38:56 Yep, if you ipkg install binutils, the new ar will appear as "armeb-linux-ar" Apr 25 05:39:01 o hay a real ar :) Apr 25 05:39:56 You'll have to manually create a symlink (replacing the /usr/bin/ar symlink to busybox) to point ot armeb-linux-ar instead, or many make utilities will accept an arg like AR=armeb-linux-ar Apr 25 05:40:32 well now that wasn't nice :/ Apr 25 05:40:48 It killed my ssh connection Apr 25 05:40:59 Out of memory...But it has 512mb of swap free Apr 25 05:42:11 Left a bunch of /bin/sh /usr/bin/ar's running, now they're zombied. :( Apr 25 05:42:53 Check the mailing list archives for some pointers on how Linux handles memory shortfalls -- I think you can change seme flags to make the kernel resort to killing processes as a very last resort; it's not the "last resort" by default. Apr 25 05:43:13 Yea heh Apr 25 05:43:19 But I'm wondering if ar is forkbombing Apr 25 05:44:08 Basically, the NSLU2 is a poor native build machine, as it just doesn't have enough memory for anything serious. But it does work, when you get the setting right -- swaps a lot, but it will eventually finish. Apr 25 05:45:25 heh Apr 25 05:45:35 I'm just wondering why I have 50 instances of ar Apr 25 05:45:47 That's a problem Apr 25 18:06:59 03bzhou * r5975 10optware/trunk/make/classpath.mk: classpath: 0.93 -> 0.95 Apr 25 18:49:27 03bzhou * r5976 10optware/trunk/make/classpath.mk: classpath: revert to 0.93, 0.95 does not support jikes out of the box Apr 25 20:39:59 03bzhou * r5977 10optware/trunk/make/git-core.mk: git: 1.5.1.1 -> 1.5.1.2 Apr 25 21:30:40 03fcarolo * r5978 10optware/trunk/ (5 files in 2 dirs): enhanced-ctorrent: upstream update to dnh3 Apr 25 21:32:31 03fcarolo * r5979 10optware/trunk/ (4 files in 2 dirs): ctcs: upstream update to 1.3 Apr 25 21:52:25 03bzhou * r5980 10optware/trunk/make/swi-prolog.mk: swi-prolog: 5.6.33 -> 5.6.34 Apr 25 22:22:56 03bzhou * r5981 10optware/trunk/scripts/optware-check-package.pl: optware-check-package.pl: made it executable Apr 25 22:33:14 hi Apr 25 23:14:41 03osas * r5982 10optware/trunk/make/asterisk14.mk: asterisk14: 1.4.2 -> 1.4.3 **** ENDING LOGGING AT Thu Apr 26 02:59:57 2007