**** BEGIN LOGGING AT Mon May 16 23:59:56 2005 **** BEGIN LOGGING AT Tue May 17 02:40:15 2005 May 17 08:40:30 FYI: package gnu-config-native fails. Seems there's a problem with config-guess-uclibc.patch May 17 08:42:49 VoodooZ_log, this is a OE package? or in the toolchain? May 17 08:43:38 I guess it's an OE package. May 17 08:44:28 k May 17 08:44:32 thanks May 17 08:44:58 the #oe guys seem to know about it. May 17 08:46:28 the fix is in the OE repo i think May 17 08:46:55 so that means we need to pull from the OE repo...let me check to see that is happening. May 17 08:49:56 must run to work...bbiaf May 17 08:51:07 later May 17 09:14:24 Anyone on? May 17 09:23:14 mornin beewoolie May 17 09:23:23 Morning. May 17 09:23:34 ka6sox-away: I wonder if you can answer an openslug question. May 17 09:23:48 I *might* be able to... May 17 09:23:56 Does Openslug use a ramdisk? May 17 09:24:23 dunno. May 17 09:24:41 VoodooZ_log, we are pulling from the OE repo ever hour. May 17 09:24:51 repull and see if the fix is in there. May 17 09:25:13 beewoolie, I"m the infrastructure guy...ask me if the wiki is working... May 17 09:25:26 That's why I was just wondering. :-) May 17 09:25:49 you might want to gander at the openslug wiki (g2 has a section on what needs done...let me find it) May 17 09:28:42 it appears to boot into jffs2 without a ramdisk. http://www.nslu2-linux.org/wiki/OpenSlug/BootDirectlyToJffs2 May 17 09:34:08 ka6sox-office: I thought that was the case. I just wanted to make sure, hear it from someone who knew. May 17 09:34:46 * ka6sox-office pays attention to the developers talk...doesn't know a whole lot but knows where to look. May 17 09:46:58 openslug doesn't use a ramdisk - the one in the flash is just to satisfy RedBoot's desire to copy a ramdisk May 17 09:48:05 It does run /etc/init.d/S30ramdisk, but that' May 17 09:48:14 s probably an error - it doesn't do anything May 17 09:50:58 jbowler-zzz: K. We're adding an APEX config for openslug. I thought that we didn't need to copy the ramdisk. Now, I'm sure. thx. May 17 09:59:49 beewoolie: the RedBoot problem is that if we don't put a ramdisk in the partition (i.e. have a partition called RamDisk with a valid length) RedBoot still copies stuff and the boot fails (it overwrites the kernel) May 17 10:00:25 we really don't want that parition. We don't need the boot loader to do any copying (the boot just uses jffs2) May 17 10:00:33 jbowler-zzz: Fair enough. Know that these kinds of issues don't affect APEX since we can update the code appropriately. May 17 10:00:46 Right ;-) May 17 10:00:59 I just wanted to remove the ramdisk copy so that the boot is faster. May 17 10:02:19 Yes! Or check for the existence of "Ramdisk" and only copy it if it is there (I'm assuming the /proc/mtd partition map still exists somewhere.) May 17 10:03:11 Well, that sort of logic is still a bit harder. We can add that, but i'd rather jettison the partition stuff altogether. It's is an unnecessary artifact, IMHO. May 17 10:04:58 I believe that is fine - the result won't be able to boot the stock LinkSys kernel but that doesn't seem a problem to me (APEX will require a kernel which can boot from jffs2, at least for an NSLU2) May 17 10:05:58 APEX can boot the stock setup when it is configured to do so. it's the switching back and forth that isn't so simple. I'd rather require a new loader configuration for openslug than try to build a loader than can detect the user's config and do the right thing. May 17 10:07:45 I can't see any problem with that. The stock command line is root=/dev/mtdblock4 rw rootfstype=jffs2 mem=32M@0x00000000 init=/linuxrc May 17 10:08:00 ..and the stock kernel completely ignores the command line. May 17 10:08:30 Or, do you mean the openslug kernel? May 17 10:08:51 That's the command line which is compiled in to the openslug kernel. May 17 10:09:25 So far as I know it does ignore the one RedBoot passes in, but this is not something I'm familiar with. May 17 10:10:24 Hmm. I don't know the details on this either, though I'm pretty sure that openslug kernels use the passed command line. [g2] has given me this impression. May 17 10:11:56 It may be that the compiled line is simply applied afterward - so it would override the loader command line. May 17 10:12:34 Anyway, I'm sure it doesn't do any Ramdisk because the one in the flash is currently just a bunch of 255's - i.e. invalid. May 17 10:14:15 Ok, here's the stuff from the boot log: May 17 10:14:17 Kernel command line: root=/dev/mtdblock4 rw rootfstype=jffs2 mem=32M@0x00000000 init=/linuxrc console=ttyS0,115200n8 May 17 10:14:58 kernel: Searching for RedBoot partition table in IXP4XX-Flash0at offset 0x7e0000 May 17 10:15:16 kernel: 6 RedBoot partitions found on MTD device IXP4XX-Flash0 May 17 10:21:30 The kernel always tries to unpack a ramdisk, but if __initramfs_end - __initramfs_start == 0 the unpack does nothing and if initrd_start is 0 no attempt is made to mount the result. May 17 10:23:18 Those variables are all horrible statics set up in the arch initialisation, in particular mm/init.c May 17 10:25:22 I'm sure this code is happening at present but that it would if 'initrd=0x01000000,10M' appeared on the compiled-in command line (like it used to). May 17 10:25:33 s/is happening/isn't happening/ May 17 10:26:01 So you're safe to ignore it. May 17 10:26:12 done May 17 10:51:19 [g2]: hey man May 17 10:51:32 <[g2]> hey dude May 17 12:31:27 jacques: FYI. I've done more reading on the JFFS2 implementations in bootloaders. While there has been support for it in several loader, it looks like it's not such a simple thing to get right. May 17 15:04:55 jacques: You're an openslugger, right? May 17 15:05:56 Is there an openslugger in the house? May 17 15:06:49 [g2]: ping? May 17 15:06:56 <[g2]> pong May 17 15:07:04 I got a build error on openslug. May 17 15:07:08 From SVN. May 17 15:07:27 I think I know what it is, but I want to get some feedback on the right method for fixing it. May 17 15:08:53 It looks like when it builds coreutils, the '.' path is in PATH. May 17 15:09:01 the mv command fails. May 17 15:09:30 Oddly, '.' isn't in my path. May 17 15:09:47 shouldn't be either May 17 15:10:04 NAiL: what makes you say that? May 17 15:10:29 I'm pretty sure that this is a path problem because I've seen the symptom before. May 17 15:10:37 having the current dir in the PATH is a security hazard May 17 15:10:52 That's not the point. May 17 15:10:58 The build shouldn't fail. May 17 15:11:12 Moreover, there are plenty of people who put . in their path. May 17 15:11:14 Is it trying to use an armeb binary? May 17 15:11:20 It looks like it. May 17 15:11:23 Yes, I know. I used to. May 17 15:11:32 /bin/sh: line 1: ./mv: cannot execute binary file May 17 15:11:46 It's building coreutils. May 17 15:12:01 hang on, I'll boot my devbox May 17 15:12:03 <[g2]> it looks like you don't have execute privs on ./mv May 17 15:12:12 I don't think that's the problem. May 17 15:12:22 It got really far on the build. May 17 15:14:31 What I wonder is this. Do you let the user's path remain during the build? Or, does OE? May 17 15:15:32 As far as I can see, the only PATH-assignment is in setup-env.. PATH=$OESYS/bin/:$PATH May 17 15:16:09 Hmm. Doesn't seem likea good idea to me since we don't know what's in the user's path. May 17 15:16:11 <[g2]> beewoolie, you didn't pull the tarball from berlios ? May 17 15:16:18 I pulled from svn. May 17 15:16:35 <[g2]> I don't know what shape SVN is in May 17 15:16:49 <[g2]> It was used as a temporary measure when BK was down May 17 15:16:54 When I wrote my builder, I removed the user's path completely. Otherwise, there's no telling what is being used. May 17 15:17:00 <[g2]> things were snapshotted in there May 17 15:17:26 Hmm. I suspect this is just that it isn't paranoid about the path. May 17 15:17:34 <[g2]> well a couple lines up in the setup OESYS is set no ? May 17 15:17:42 I'll do that. May 17 15:20:36 Hmm. Same error. Very suspicious. May 17 15:30:21 <[g2]> echo your PATH May 17 15:30:35 I did better. I removed it completely. May 17 15:30:43 PATH=$OESYS/bin/:/bin:/usr/bin:/sbin:/usr/sbin May 17 15:30:50 That's in setenv. May 17 15:30:54 setup-env May 17 15:31:51 <[g2]> rep OESYS setup-env May 17 15:31:51 <[g2]> OESYS=$OEROOT/bitbake/ May 17 15:31:51 <[g2]> BBPATH=$OEBUILD:$PKGDIR:$OESYS May 17 15:31:51 <[g2]> PATH=$OESYS/bin/:$PATH May 17 15:32:04 <[g2]> s/rep/grep May 17 15:32:27 q\\OESYS=$OEROOT/bitbake/ May 17 15:32:28 BBPATH=$OEBUILD:$PKGDIR:$OESYS May 17 15:32:28 PATH=$OESYS/bin/:/bin:/usr/bin:/sbin:/usr/sbin May 17 15:32:35 Forget about the q\\ May 17 15:33:10 <[g2]> Ok so OEROOT/bitbake is there ? May 17 15:33:20 Yep. May 17 15:33:31 <[g2]> are you using bash ? May 17 15:33:36 elf@florence ...oe/openslug > pwd May 17 15:33:37 elf@florence ...oe/openslug > ls May 17 15:33:37 bitbake/ downloads@ Makefile~ openembedded/ tmp/ May 17 15:33:39 conf/ Makefile nslu2-linux/ setup-env May 17 15:33:42 I use tcsh. May 17 15:33:56 <[g2]> maybe a shell thing May 17 15:33:57 How coould the shell matter? May 17 15:34:19 <[g2]> well when you echo $PATH is the proper bitbake path in there ? May 17 15:34:54 <[g2]> it's really simple May 17 15:34:56 <[g2]> . setup-env May 17 15:35:00 <[g2]> which bitbake May 17 15:35:41 Doesn't the makefile run that script automatically? May 17 15:35:56 I know. I can tell that for myself. May 17 15:35:57 <[g2]> that first time May 17 15:36:08 <[g2]> and when you type mke May 17 15:36:09 <[g2]> make May 17 15:36:21 OK. so, I ran bash. sources the script. ran make. Same problem. May 17 15:36:33 <[g2]> on the ./mv May 17 15:36:39 elf@florence:/a/trans/embedded/oe/openslug$ printenv PATH May 17 15:37:10 Yeah. same error. May 17 15:37:24 <[g2]> can you run that same command from the work directory ? May 17 15:37:31 You mean mv? May 17 15:37:39 <[g2]> yeah May 17 15:37:43 mv --version works OK. May 17 15:37:48 Same path. May 17 15:37:55 <[g2]> no the ./mv from the place May 17 15:38:31 <[g2]> cd path; ./mv -h May 17 15:38:53 <[g2]> or .mv --help May 17 15:39:09 There is a mv in ./src/mv. May 17 15:39:24 It's an arm binary. May 17 15:39:42 <[g2]> is that the one it's trying to execute ? May 17 15:39:44 I'm guessing that that's the file that the makefile is trying to run. May 17 15:40:02 <[g2]> is says were the error is May 17 15:40:11 <[g2]> where May 17 15:40:22 Not really. May 17 15:40:45 <[g2]> it says something about do_compile..... May 17 15:40:49 <[g2]> ERROR May 17 15:40:58 ... May 17 15:41:14 ERROR: function do_compile failed May 17 15:41:15 ERROR: see log in /a/trans/embedded/oe/openslug/tmp/work/coreutils-5.1.3-r1/temp/log.do_compile.2369 May 17 15:41:18 I look in that file... May 17 15:41:44 <[g2]> right look in the run.do_compile.2369 May 17 15:41:46 OK. It is running in that directory. May 17 15:41:50 <[g2]> that's the code it's actually running May 17 15:41:55 And it's trying to execute this. May 17 15:42:08 mv -f ".deps/rmdir.Tpo" ".deps/rmdir.Po"; else rm -f ".deps/rmdir.Tpo"; exi May 17 15:42:09 t 1; fi May 17 15:42:14 <[g2]> well executing on the wrong arch is an error May 17 15:42:25 But that program shouldn't be in the path. May 17 15:42:35 It would only be in the path if . was in there. May 17 15:42:44 Let me see if I can get it to show me the path. May 17 15:46:59 Yeah. That's what's happening. The path isn't what setup-env tells it to be. May 17 15:50:43 OK. this is really odd. May 17 15:51:00 (source setup-env ; echo $(OEROOT) ; bb...) May 17 15:51:04 The OEROOT isn't set. May 17 15:53:14 Actually, that's what I would expect since that command is going to pull the environment from make instead of the shell. May 17 15:57:46 I can't explain it right now. When I insert a printenv between the source and the bb command, I can see the right environment. However, the package build shows the original path. May 17 16:24:27 hi there CW May 17 16:24:43 hi ka6sox-office May 17 16:24:57 wow, familiar crowd... May 17 16:25:00 openslug has gone beta.... May 17 16:25:07 (in case you haven't heard) May 17 16:25:10 seen that. May 17 16:25:37 in fact, I'm trying to get back up to speed. RL has been way too prominent the last few months. May 17 16:25:41 how you been? May 17 16:26:08 My dad died last month. Things have been kind... intense. May 17 16:26:44 ouch...sorry to hear that...when I lost my dad it was an intense time. May 17 16:27:20 hard to find the upside, if you know what I mean May 17 16:28:09 where's the superquickstart page? and how much disk am I gonna need? May 17 16:28:44 for building or firmware? May 17 16:29:07 firmware install. I have a fresh build of the beta Ssvn snapshot. May 17 16:29:39 it fitz in the onboard flash May 17 16:30:11 so the same dance as old times will work, then? load -r -v -b 0x01000000 ; fis write -f 0x50060000 -b 0x01060000 -l 0x7a0000 May 17 16:31:05 uses the same bootloader(redboot) although we are looking at a smaller/faster one. May 17 16:31:46 cool. how about the flashdisk image? what do I do with that? (gh0d, a few months and i'm a noob all over again :) May 17 16:33:13 we no longer use switchbox and boot directly into the rootfs (jffs2) May 17 16:33:30 the .img file is everything afaict May 17 16:34:01 ok, got it... ah, now I remember... the build keeps a separate rootfs image around, right? May 17 16:34:16 yes May 17 16:34:41 got it, thx May 17 16:36:19 ka6sox-office: reminds me.. did you get around to that cable? I've been a bit busy (and offline) the last few days May 17 16:36:56 hacked it today..now gluing it back together. May 17 16:37:37 gotta run for a bit...trying to make Fedex. May 17 16:37:48 k May 17 16:37:50 * NAiL goes to bed May 17 16:37:56 nitey May 17 16:38:03 <-- got some infection :( May 17 16:40:03 <[g2]> CodeWhacker, hey May 17 16:40:34 <[g2]> CodeWhacker, SORRY about your dad :( May 17 16:52:10 thanks, g2 May 17 16:52:43 strange... tftpd is timing out May 17 17:46:07 ho wierd. turn ethereal on and the tftp moves fine. hmmm... think I have a bridge wierdness May 17 17:46:28 :-\ May 17 18:17:14 anybody tried using perl? May 17 18:18:49 it's in the feed, but doesn't run. getting a symbol error in libperl.so.5 May 17 18:19:03 (or did I miss a package?) **** ENDING LOGGING AT Tue May 17 23:59:56 2005