From stuarth at freescale.com Wed Nov 1 02:00:31 2006 From: stuarth at freescale.com (Stuart Hughes) Date: Wed, 01 Nov 2006 10:00:31 +0000 Subject: building busybox with a different uclibc to the toolchain version In-Reply-To: <200611010049.56499.vda.linux@googlemail.com> References: <1162313110.27275.831.camel@m20> <200611010049.56499.vda.linux@googlemail.com> Message-ID: <1162375232.27275.862.camel@m20> On Wed, 2006-11-01 at 00:49 +0100, Denis Vlasenko wrote: > On Tuesday 31 October 2006 17:45, Stuart Hughes wrote: > > I'm not really sure if this is a uClibc/gcc or busybox question, but > > here goes: > > > > I'm trying to build a powerpc target image using an older uClibc (0.27) > > than the one in my cross compiler (0.28). The version of busybox I'm > > building is 1.1.3. > > > > The build works okay, but when I try to boot init just hangs. > > I tried building busybox statically and when this boots it dies: > > > > "init has generated signal 11 but has no handler for it" > > > > Anyone have any ideas what is wrong? > > 11 is SIGSEGV. Is it specific to init? (IOW: can you boot with > init=/bin/sh?) > -- > vda > No, this happens if I pass init=/bin/sh or any other applet. What I'm trying to do is to build an older uClibc-0.27 based rootfs with a pre-built cross compiler that includes uClibc-0.28. What I'm wondering is whether something incompatible can "leak" from the toolchain and cause this problem. I turned on debugging in uClibc and saw this: VFS: Mounted root (nfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 96k init?.ELF...0x30000000 .ELF...0x30016aac .ELF....ELF....ELF....ELF...Done relocating library loader, so we can now use globals and make function calls! Cool, we managed to make a function call. malloc: mmapping more memory Lib Loader: (0x0) /lib/ld-uClibc.so.0 calling mprotect on the application program Loading: (0x30017000) /lib/libcrypt.so.0 Loading: (0x3003d000) /lib/libgcc_s.so.1 Loading: (0x3005a000) /lib/libc.so.0 Loading: (0x3005a000) /lib/libc.so.0 Loading: (0x3005a000) /lib/libc.so.0 Beginning relocation fixups transfering control to application init has generated signal 11 but has no handler for it Kernel panic - not syncing: Attempted to kill init! Does that look familiar, or can you suggest anything else to try out. Regards, Stuart From rep.nop at aon.at Wed Nov 1 03:49:44 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Wed, 1 Nov 2006 12:49:44 +0100 Subject: svn commit: trunk/busybox: libbb shell In-Reply-To: <20061101091327.14A1D485CE@busybox.net> References: <20061101091327.14A1D485CE@busybox.net> Message-ID: <20061101114944.GH18267@aon.at> On Wed, Nov 01, 2006 at 01:13:27AM -0800, vda at busybox.net wrote: >Author: vda >Date: 2006-11-01 01:13:26 -0800 (Wed, 01 Nov 2006) >New Revision: 16483 > >Log: >#if CONFIG_xxx -> #if ENABLE_xxx Still, you didn't do this for cmdedit.h. Why? cheers, >Modified: trunk/busybox/shell/cmdedit.h >=================================================================== >--- trunk/busybox/shell/cmdedit.h 2006-10-31 23:39:37 UTC (rev 16482) >+++ trunk/busybox/shell/cmdedit.h 2006-11-01 09:13:26 UTC (rev 16483) >@@ -2,19 +2,19 @@ > #ifndef CMDEDIT_H > #define CMDEDIT_H > >-int cmdedit_read_input(char* promptStr, char* command); >+int cmdedit_read_input(char* promptStr, char* command); > > #ifdef CONFIG_ASH > extern const char *cmdedit_path_lookup; > #endif > > #ifdef CONFIG_FEATURE_COMMAND_SAVEHISTORY >-void load_history ( const char *fromfile ); >-void save_history ( const char *tofile ); >+void load_history(const char *fromfile); >+void save_history(const char *tofile); > #endif > >-#if CONFIG_FEATURE_COMMAND_EDITING_VI >-void setvimode ( int viflag ); >+#if ENABLE_FEATURE_COMMAND_EDITING_VI >+void setvimode(int viflag); > #endif From bjthomas3 at gmail.com Wed Nov 1 07:08:05 2006 From: bjthomas3 at gmail.com (B Thomas) Date: Wed, 1 Nov 2006 10:08:05 -0500 Subject: [PATCH] - allow specification of alternate inittab files In-Reply-To: References: <200611010111.33473.vda.linux@googlemail.com> Message-ID: Yeah... that was stupid. Let's try again with a much smaller, much improved version. Thanks for pointing out the obvious silliness in the original patch. -b On 10/31/06, B Thomas wrote: > > Hey, you're probably correct. It was a long, twisty path before I got to > the final patch including many detours and changes of direction. Let me > rework it with the environment variables and resubmit. > > Thanks, > -b > > > On 10/31/06, Denis Vlasenko wrote: > > > > On Tuesday 31 October 2006 23:22, B Thomas wrote: > > > Hi, > > > > > > There are circumstances in which it would be great to allow the > > selection of > > > different inittab file at boot time. This patch adds the ability to > > select > > > the inittab file via a command line option (bb_inittab). > > > > > > One of the things that I don't like about this patch is the need to > > mount > > > /proc on systems in which it isn't mounted. The mount is cleaned up > > and > > > handled carefully; I just don't like having to do it. Having said > > that, > > > this patch has proven to be quite useful. > > > > > > Signed-off-by: Ben Thomas (ben at virtualiron.com ) > > > > I thought that all unrecognized kernel params are passed in the > > environment > > to init: kernel tree, init/main.c: > > > > /* > > * Unknown boot options get handed to init, unless they look like > > * failed parameters > > */ > > static int __init unknown_bootoption(char *param, char *val) > > { > > .... > > if (val) { > > /* Environment option */ > > unsigned int i; > > for (i > > if (i = MAX_INIT_ENVS) { > > panic_later > > `%s'"; > > panic_param > > } > > if (!strncmp(param, envp_init[i], val - param)) > > break; > > } > > .... > > > > So you do not need to parse /proc/commandline > > -- > > vda > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061101/d0113ffc/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: bbinit.patch Type: text/x-patch Size: 891 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061101/d0113ffc/attachment.bin From floydpink at gmail.com Wed Nov 1 07:19:58 2006 From: floydpink at gmail.com (Jason Schoon) Date: Wed, 1 Nov 2006 09:19:58 -0600 Subject: [PATCH] - allow specification of alternate inittab files In-Reply-To: References: <200611010111.33473.vda.linux@googlemail.com> Message-ID: <78a54e1b0611010719g7c993185h79a0d56a6ff526a7@mail.gmail.com> On 11/1/06, B Thomas wrote: > > Yeah... that was stupid. Let's try again with a much smaller, much > improved version. Thanks for pointing out the obvious silliness in the > original patch. > > -b Is this really something that busybox init should be handling? There is nothing saying you have to use the init out of busybox to start your system. Init could simply be a shell script or C application that you write. In that case, especially in a shell script, it would be trivial to look for a command line parameter specifying the inittab (or any other config file, there is no requirement that you have to use /etc/inittab either) to use for that boot. At the very least, I would think this should be a config item, and it should be wrapped in the existing inittab config item. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061101/c3aa3668/attachment.html From stuarth at freescale.com Wed Nov 1 07:58:19 2006 From: stuarth at freescale.com (Stuart Hughes) Date: Wed, 01 Nov 2006 15:58:19 +0000 Subject: building busybox with a different uclibc to the toolchain version In-Reply-To: <1162375232.27275.862.camel@m20> References: <1162313110.27275.831.camel@m20> <200611010049.56499.vda.linux@googlemail.com> <1162375232.27275.862.camel@m20> Message-ID: <1162396699.14292.14.camel@m20> On Wed, 2006-11-01 at 10:00 +0000, Stuart Hughes wrote: > On Wed, 2006-11-01 at 00:49 +0100, Denis Vlasenko wrote: > > On Tuesday 31 October 2006 17:45, Stuart Hughes wrote: > > > I'm not really sure if this is a uClibc/gcc or busybox question, but > > > here goes: > > > > > > I'm trying to build a powerpc target image using an older uClibc (0.27) > > > than the one in my cross compiler (0.28). The version of busybox I'm > > > building is 1.1.3. > > > > > > The build works okay, but when I try to boot init just hangs. > > > I tried building busybox statically and when this boots it dies: > > > > > > "init has generated signal 11 but has no handler for it" > > > > > > Anyone have any ideas what is wrong? > > > > 11 is SIGSEGV. Is it specific to init? (IOW: can you boot with > > init=/bin/sh?) > > -- > > vda > > > > No, this happens if I pass init=/bin/sh or any other applet. > > What I'm trying to do is to build an older uClibc-0.27 based rootfs with > a pre-built cross compiler that includes uClibc-0.28. What I'm > wondering is whether something incompatible can "leak" from the > toolchain and cause this problem. I turned on debugging in uClibc and > saw this: > > VFS: Mounted root (nfs filesystem) readonly. > Mounted devfs on /dev > Freeing unused kernel memory: 96k init?.ELF...0x30000000 > .ELF...0x30016aac > .ELF....ELF....ELF....ELF...Done relocating library loader, so we can > now > use globals and make function calls! > Cool, we managed to make a function call. > malloc: mmapping more memory > Lib Loader: (0x0) /lib/ld-uClibc.so.0 > calling mprotect on the application program > Loading: (0x30017000) /lib/libcrypt.so.0 > Loading: (0x3003d000) /lib/libgcc_s.so.1 > Loading: (0x3005a000) /lib/libc.so.0 > Loading: (0x3005a000) /lib/libc.so.0 > Loading: (0x3005a000) /lib/libc.so.0 > Beginning relocation fixups > transfering control to application > init has generated signal 11 but has no handler for it > Kernel panic - not syncing: Attempted to kill init! > > Does that look familiar, or can you suggest anything else to try out. > Okay I figured out the problem. I was picking up crt?.o from the toolchain rather than the built uClibc when linking. Now that I've fixed that it boots okay. Thanks to everyone that helped out. Regards, Stuart From rob at landley.net Wed Nov 1 08:15:33 2006 From: rob at landley.net (Rob Landley) Date: Wed, 1 Nov 2006 11:15:33 -0500 Subject: building busybox with a different uclibc to the toolchain version In-Reply-To: <1162375232.27275.862.camel@m20> References: <1162313110.27275.831.camel@m20> <200611010049.56499.vda.linux@googlemail.com> <1162375232.27275.862.camel@m20> Message-ID: <200611011115.33793.rob@landley.net> On Wednesday 01 November 2006 5:00 am, Stuart Hughes wrote: > Cool, we managed to make a function call. > malloc: mmapping more memory > Lib Loader: (0x0) /lib/ld-uClibc.so.0 Is this the library loader that came with compiler's uClibc, or the one that came with the one you're building against? Also, your headers are probably all wrong for your library. This really isn't a busybox bug. Try the uClibc list. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From bjthomas3 at gmail.com Wed Nov 1 08:35:08 2006 From: bjthomas3 at gmail.com (B Thomas) Date: Wed, 1 Nov 2006 11:35:08 -0500 Subject: [PATCH] - allow specification of alternate inittab files In-Reply-To: <78a54e1b0611010719g7c993185h79a0d56a6ff526a7@mail.gmail.com> References: <200611010111.33473.vda.linux@googlemail.com> <78a54e1b0611010719g7c993185h79a0d56a6ff526a7@mail.gmail.com> Message-ID: Well, you might think so, and perhaps there is some avenue that I haven't explored. I ended up in situations in which a given inittab just wouldn't do the trick and only a different inittab would. For example, what serial lines are started and how. In the end, no amount of scripting seemed to help. Only a separate inittab. My vague memories of the issue (I solved this some time ago and am only now getting around to submitting the change), is that serial lines were a prominent pain. Some systems would start them, others would just error over and over and over (the serial line didn't exist, for instance). A lot of experimenting with all of the different knobs (boot command options, inittab, scripts, etc) ended up with no real answer and only frustration. Each system and configuration had its own unique combination of requirements. A simple, to the point, change was to simply allow the specification of the inittab that you wish to be using. A second scenario is, say, for an environment in which you want no serial input, but want a debug option. A simple approach is a default inittab with no serial lines, and a debug version with serial lines and shells. Overall, inittab is a very simple, sane, usable solution. This patch very simply allows you a choice to provide some flexibility and builds upon the existing mechanism. As you point out, there are many other choices. This was one, low-cost, incredibly simple to implement one that I happened to put together. thanks, -b On 11/1/06, Jason Schoon wrote: > > On 11/1/06, B Thomas wrote: > > > > Yeah... that was stupid. Let's try again with a much smaller, much > > improved version. Thanks for pointing out the obvious silliness in the > > original patch. > > > > -b > > > Is this really something that busybox init should be handling? There is > nothing saying you have to use the init out of busybox to start your > system. Init could simply be a shell script or C application that you > write. > > In that case, especially in a shell script, it would be trivial to look > for a command line parameter specifying the inittab (or any other config > file, there is no requirement that you have to use /etc/inittab either) to > use for that boot. > > At the very least, I would think this should be a config item, and it > should be wrapped in the existing inittab config item. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061101/3dee4455/attachment.html From vda.linux at googlemail.com Wed Nov 1 09:36:36 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Wed, 1 Nov 2006 18:36:36 +0100 Subject: svn commit: trunk/busybox: libbb shell In-Reply-To: <20061101114944.GH18267@aon.at> References: <20061101091327.14A1D485CE@busybox.net> <20061101114944.GH18267@aon.at> Message-ID: <200611011836.36857.vda.linux@googlemail.com> On Wednesday 01 November 2006 12:49, Bernhard Fischer wrote: > On Wed, Nov 01, 2006 at 01:13:27AM -0800, vda at busybox.net wrote: > >Author: vda > >Date: 2006-11-01 01:13:26 -0800 (Wed, 01 Nov 2006) > >New Revision: 16483 > > > >Log: > >#if CONFIG_xxx -> #if ENABLE_xxx > > Still, you didn't do this for cmdedit.h. Why? Because cmdedit.h don't have #if CONFIG (it has #ifdef CONFIG). The difference is that #if CONFIG_xxx is, strictly speaking, a bug, because if symbol is not defined, it expands into #if CONFIG_xxx not "#if 0" or "#if 1" as was intended! This is wrong (and IIRC newer gcc will complain). -- vda From vda.linux at googlemail.com Wed Nov 1 09:55:25 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Wed, 1 Nov 2006 18:55:25 +0100 Subject: [PATCH] - allow specification of alternate inittab files In-Reply-To: References: <78a54e1b0611010719g7c993185h79a0d56a6ff526a7@mail.gmail.com> Message-ID: <200611011855.25507.vda.linux@googlemail.com> On Wednesday 01 November 2006 17:35, B Thomas wrote: > Well, you might think so, and perhaps there is some avenue that I haven't > explored. I ended up in situations in which a given inittab just wouldn't > do the trick and only a different inittab would. For example, what serial > lines are started and how. In the end, no amount of scripting seemed to > help. Only a separate inittab. > > My vague memories of the issue (I solved this some time ago and am only now > getting around to submitting the change), is that serial lines were a > prominent pain. Some systems would start them, others would just error over > and over and over (the serial line didn't exist, for instance). A lot of > experimenting with all of the different knobs (boot command options, > inittab, scripts, etc) ended up with no real answer and only frustration. > Each system and configuration had its own unique combination of > requirements. A simple, to the point, change was to simply allow the > specification of the inittab that you wish to be using. > > A second scenario is, say, for an environment in which you want no serial > input, but want a debug option. A simple approach is a default inittab with > no serial lines, and a debug version with serial lines and shells. > > Overall, inittab is a very simple, sane, usable solution. What is so simple about inittab? Don't forget that you have dedicated C code in init which needs to handle it, with all that nasty little quirks about signal handling, controlling ttys, respawning etc... and I did not even started to mention sysV runlevel insanity, or that idiotic "reboot by signalling init". All this can be handled without inittab *at all*. My init parameter is: init=/init. cat /init: #!/bin/sh # Set up env unset HOSTNAME unset devfs unset MACHTYPE unset SHLVL unset SHELL unset HOSTTYPE unset OSTYPE unset HOME unset TERM export PATH=/bin:/usr/bin # Open console exec >/dev/console 2>&1 &- 2>&- <&- # Sleep forever while true; do env - sleep 32000; done There you have it. Make /etc/rc.d/start start gettys, network daemons, serial line daemons, databases etc etc etc. Use whatever "daemon controller" tool which suits you (there are several popular ones on the Net). Kernel's parameters are propagated into /etc/rc.d/start too (in the environment). Why bother init task with this mess? It is critical and harder to debug than "normal" programs, so keep it simple. Of course I do not plan to throw init out of busybox, there are too many users of it, but I am sort of reluctant to _add_ even_ more_ code_ to it. For one, why other init's out there do not have such thing as alternate inittab? > This patch very > simply allows you a choice to provide some flexibility and builds upon the > existing mechanism. As you point out, there are many other choices. This > was one, low-cost, incredibly simple to implement one that I happened to put > together. -- vda From bjthomas3 at gmail.com Wed Nov 1 10:52:27 2006 From: bjthomas3 at gmail.com (B Thomas) Date: Wed, 1 Nov 2006 13:52:27 -0500 Subject: [PATCH] - allow specification of alternate inittab files In-Reply-To: <200611011855.25507.vda.linux@googlemail.com> References: <78a54e1b0611010719g7c993185h79a0d56a6ff526a7@mail.gmail.com> <200611011855.25507.vda.linux@googlemail.com> Message-ID: Hi, Well, here I think we have to agree to disagree. I like it; I use it; I added some more flexibility to it in a very few lines of code. The wonderful thing about busybox is that you can choose to have this support or not. For inittab, I chose to. I understand why you may not wish to. Likewise, there are a number of things that I wouldn't chose to include in busybox. So, I don't. Anyhow, I'm not on a mission to convince anyone of anything. I was simply trying to contribute a change back to a package that I've found useful. That's all. Best wishes, -b On 11/1/06, Denis Vlasenko wrote: > > On Wednesday 01 November 2006 17:35, B Thomas wrote: > > Well, you might think so, and perhaps there is some avenue that I > haven't > > explored. I ended up in situations in which a given inittab just > wouldn't > > do the trick and only a different inittab would. For example, what > serial > > lines are started and how. In the end, no amount of scripting seemed to > > help. Only a separate inittab. > > > > My vague memories of the issue (I solved this some time ago and am only > now > > getting around to submitting the change), is that serial lines were a > > prominent pain. Some systems would start them, others would just error > over > > and over and over (the serial line didn't exist, for instance). A lot of > > experimenting with all of the different knobs (boot command options, > > inittab, scripts, etc) ended up with no real answer and only > frustration. > > Each system and configuration had its own unique combination of > > requirements. A simple, to the point, change was to simply allow the > > specification of the inittab that you wish to be using. > > > > A second scenario is, say, for an environment in which you want no > serial > > input, but want a debug option. A simple approach is a default inittab > with > > no serial lines, and a debug version with serial lines and shells. > > > > Overall, inittab is a very simple, sane, usable solution. > > What is so simple about inittab? Don't forget that you have > dedicated C code in init which needs to handle it, with all that > nasty little quirks about signal handling, controlling ttys, > respawning etc... and I did not even started to mention sysV > runlevel insanity, or that idiotic "reboot by signalling init". > > All this can be handled without inittab *at all*. My init > parameter is: init=/init. cat /init: > > #!/bin/sh > # Set up env > unset HOSTNAME > unset devfs > unset MACHTYPE > unset SHLVL > unset SHELL > unset HOSTTYPE > unset OSTYPE > unset HOME > unset TERM > export PATH=/bin:/usr/bin > # Open console > exec >/dev/console 2>&1 # Run startup script > /etc/rc.d/start 3 > # Close all descriptors > exec >&- 2>&- <&- > # Sleep forever > while true; do env - sleep 32000; done > > There you have it. Make /etc/rc.d/start start gettys, > network daemons, serial line daemons, databases etc etc etc. > Use whatever "daemon controller" tool which suits you > (there are several popular ones on the Net). > Kernel's parameters are propagated into /etc/rc.d/start > too (in the environment). > > Why bother init task with this mess? It is critical > and harder to debug than "normal" programs, so keep it simple. > > Of course I do not plan to throw init out of busybox, > there are too many users of it, but I am sort of reluctant > to _add_ even_ more_ code_ to it. For one, why other > init's out there do not have such thing as alternate inittab? > > > This patch very > > simply allows you a choice to provide some flexibility and builds upon > the > > existing mechanism. As you point out, there are many other choices. > This > > was one, low-cost, incredibly simple to implement one that I happened to > put > > together. > -- > vda > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061101/fda81400/attachment.htm From bet at rahul.net Wed Nov 1 10:25:47 2006 From: bet at rahul.net (Bennett Todd) Date: Wed, 1 Nov 2006 13:25:47 -0500 Subject: ash backticks busted in 1.2.2.1 Message-ID: <20061101182547.GX95055@og.latency.net> At least I'm assuming that the "sh" cmd in busybox is ash when ash is enabled. I did a busybox build on Red Hat Enterprise Linux 4, statically linking against glibc, with everything in busybox turned on; in the result backticks don't work. E.g. echo `ls` prints nothing. If you have trouble reproducing this let me know, I can provide the .config, gcc and libc details, etc. -Bennett From ddaney at avtrex.com Wed Nov 1 14:24:30 2006 From: ddaney at avtrex.com (David Daney) Date: Wed, 01 Nov 2006 14:24:30 -0800 Subject: ash backticks busted in 1.2.2.1 In-Reply-To: <20061101182547.GX95055@og.latency.net> References: <20061101182547.GX95055@og.latency.net> Message-ID: <45491E9E.2050804@avtrex.com> Bennett Todd wrote: > At least I'm assuming that the "sh" cmd in busybox is ash when ash > is enabled. I did a busybox build on Red Hat Enterprise Linux 4, > statically linking against glibc, I suggest that you read all the comments on the list about what a bad idea it is to statically link to glibc. David Daney From bet at rahul.net Wed Nov 1 14:33:36 2006 From: bet at rahul.net (Bennett Todd) Date: Wed, 1 Nov 2006 17:33:36 -0500 Subject: ash backticks busted in 1.2.2.1 In-Reply-To: <45491E9E.2050804@avtrex.com> References: <20061101182547.GX95055@og.latency.net> <45491E9E.2050804@avtrex.com> Message-ID: <20061101223336.GD95055@og.latency.net> 2006-11-01T17:24:30 David Daney: > I suggest that you read all the comments on the list about what a bad > idea it is to statically link to glibc. Thanks for the suggestion, it'll be a few days but when I get a nice chunk of hack-at-home time I'll do that very thing. Had a weird problem where an installer initrd was getting itself into a wedged state where every attempt to run bunzip or cpio segved instantly, as best strace could tell without issuing a single syscall. Still have no clue what's the root cause but have been experimenting with different ways of building initrd components. Ended up having to pile on a ton of shlibs to get dns to work but otherwise the static glibc seemed to be ok, until I realized ash couldn't do backticks. I'll try rebuilding 1.2.2.1 on my home uclibc-based distro (in a few days, I'm afraid), and will send another note if I can reproduce the problem there, otherwise we'll happily blame it on glibc. Meanwhile the mysterious segv-ing persisted even with glibc. Persisted even when I switched to using the Red Hat bunzip and cpio. So I'm off the theory that uclibc had anything to do with that problem. I'm currently hoping it's skunky hardware. -Bennett From rep.nop at aon.at Thu Nov 2 03:29:23 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu, 2 Nov 2006 12:29:23 +0100 Subject: [PATCH] dhcprelay In-Reply-To: <20060923063139.GC28982@zelow.no> References: <4513DC51.5010307@bfs.de> <20060923063139.GC28982@zelow.no> Message-ID: <20061102112923.GV18267@aon.at> On Sat, Sep 23, 2006 at 08:31:39AM +0200, Thomas Lundquist wrote: >On Fri, Sep 22, 2006 at 12:48:17PM -0700, Jesse Dutton wrote: > >> In essence, it routes dhcp. > >and yes, it is useful. Didn't look at the code, but it sounds useful. vda, care to apply this? > > > >Thomas, voting (if needed) From rep.nop at aon.at Thu Nov 2 09:06:12 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu, 2 Nov 2006 18:06:12 +0100 Subject: kbuild transition misc issues Message-ID: <20061102170612.GA18267@aon.at> Hi, Random notes that beg for patches/ideas/comments from any interrested party.. 1) duplicate Config.in entry $ make oldconfig > /dev/null .config:525:warning: trying to reassign symbol FEATURE_IFUPDOWN_IP_BUILTIN .config:637:warning: symbol value '' invalid for FEATURE_COMMAND_HISTORY And indeed, there is something wrong there: $ grep -A1 FEATURE_IFUPDOWN_IP_BUILTIN networking/Config.in config FEATURE_IFUPDOWN_IP_BUILTIN bool "Use busybox ip applet" -- config FEATURE_IFUPDOWN_IP_BUILTIN bool "Use busybox ifconfig and route applets" Looks like the second one wants another config symbol, no? 2) FEATURE_COMMAND_HISTORY $ make defconfig > /dev/null ; grep FEATURE_COMMAND_HISTORY .config CONFIG_FEATURE_COMMAND_HISTORY= We (try to) guard against improper values in cmdedit.c via /* Maximum length of the linked list for the command line history */ #ifndef CONFIG_FEATURE_COMMAND_HISTORY #define MAX_HISTORY 15 #else #define MAX_HISTORY CONFIG_FEATURE_COMMAND_HISTORY #endif #if MAX_HISTORY < 1 #warning cmdedit: You set MAX_HISTORY < 1. The history algorithm switched off. #else static char *history[MAX_HISTORY+1]; /* history + current */ /* saved history lines */ static int n_history; /* current pointer to history line */ static int cur_history; #endif But if i play stoopid (\"Doctor, it hurts when i..\") and CONFIG_FEATURE_COMMAND_HISTORY=18446744073709551619 which is a tad more than (unsigned long long)-1+3 then i expect that bad things will happen.. I suggest that we do: 2a) Index: shell/Config.in =================================================================== --- shell/Config.in (revision 16488) +++ shell/Config.in (working copy) @@ -257,6 +257,7 @@ config FEATURE_COMMAND_HISTORY int "History size" + range 0 4294967295 default 15 depends on FEATURE_COMMAND_EDITING help to limit it to something vaguely reasonable. This doesn't seem to work with our fork of the kbuild stuff, i fear. Lingering bug? Due to our defconfig ignoring all of shell/* ? 2b) add a check against an upper limit in cmdedit.c 2c) xmalloc the static char *history 3) Config.in and improper CONFIG_foo leftovers $ find ./ -name Config.in -exec grep -Hirn "[^_F]CONFIG_" {} \; ./networking/Config.in:56: depends on GETOPT_LONG && (CONFIG_FTPGET || FTPPUT) ./networking/Config.in:248: depends on IFUPDOWN && !CONFIG_FEATURE_IFUPDOWN_IP Are (clear) bugs stemming from an incomplete transition. thanks for reading that far; friendly, Bernhard From vda.linux at googlemail.com Thu Nov 2 15:10:33 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Fri, 3 Nov 2006 00:10:33 +0100 Subject: kbuild transition misc issues In-Reply-To: <20061102170612.GA18267@aon.at> References: <20061102170612.GA18267@aon.at> Message-ID: <200611030010.33311.vda.linux@googlemail.com> On Thursday 02 November 2006 18:06, Bernhard Fischer wrote: > Hi, > > Random notes that beg for patches/ideas/comments from any interrested > party.. > > 1) duplicate Config.in entry > > $ make oldconfig > /dev/null > .config:525:warning: trying to reassign symbol FEATURE_IFUPDOWN_IP_BUILTIN > .config:637:warning: symbol value '' invalid for FEATURE_COMMAND_HISTORY > > And indeed, there is something wrong there: > $ grep -A1 FEATURE_IFUPDOWN_IP_BUILTIN networking/Config.in > config FEATURE_IFUPDOWN_IP_BUILTIN > bool "Use busybox ip applet" > -- > config FEATURE_IFUPDOWN_IP_BUILTIN > bool "Use busybox ifconfig and route applets" > > Looks like the second one wants another config symbol, no? Done: renamed to FEATURE_IFUPDOWN_IFCONFIG_BUILTIN > I suggest that we do: > 2a) > Index: shell/Config.in > =================================================================== > --- shell/Config.in (revision 16488) > +++ shell/Config.in (working copy) > @@ -257,6 +257,7 @@ > > config FEATURE_COMMAND_HISTORY > int "History size" > + range 0 4294967295 > default 15 > depends on FEATURE_COMMAND_EDITING > help > > to limit it to something vaguely reasonable. > This doesn't seem to work with our fork of the kbuild stuff, i fear. > Lingering bug? Due to our defconfig ignoring all of shell/* ? Done. I suppose "range 0 99999" is big enough. This hopefully helps with "#defined to ''" problem: #define MAX_HISTORY (CONFIG_FEATURE_COMMAND_HISTORY + 0) > 2b) > add a check against an upper limit in cmdedit.c > 2c) xmalloc the static char *history I'm cowardly trying to avoid looking into shell mess... > 3) Config.in and improper CONFIG_foo leftovers > $ find ./ -name Config.in -exec grep -Hirn "[^_F]CONFIG_" {} \; > ./networking/Config.in:56: depends on GETOPT_LONG && (CONFIG_FTPGET || FTPPUT) Done. > ./networking/Config.in:248: depends on IFUPDOWN && !CONFIG_FEATURE_IFUPDOWN_IP Done. Thank you. -- vda From vda.linux at googlemail.com Thu Nov 2 15:13:52 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Fri, 3 Nov 2006 00:13:52 +0100 Subject: [PATCH] dhcprelay In-Reply-To: <20061102112923.GV18267@aon.at> References: <20060923063139.GC28982@zelow.no> <20061102112923.GV18267@aon.at> Message-ID: <200611030013.52932.vda.linux@googlemail.com> On Thursday 02 November 2006 12:29, Bernhard Fischer wrote: > On Sat, Sep 23, 2006 at 08:31:39AM +0200, Thomas Lundquist wrote: > >On Fri, Sep 22, 2006 at 12:48:17PM -0700, Jesse Dutton wrote: > > > >> In essence, it routes dhcp. > > > >and yes, it is useful. > > Didn't look at the code, but it sounds useful. > > vda, care to apply this? Sure. Where's the patch? -- vda From guillaume.fortaine at wanadoo.fr Fri Nov 3 19:23:21 2006 From: guillaume.fortaine at wanadoo.fr (Guillaume FORTAINE) Date: Sat, 4 Nov 2006 04:23:21 +0100 Subject: Linux - PowerPC - Uclibc-nptl Message-ID: <200611040423.21829.guillaume.fortaine@wanadoo.fr> Hello, Let me introduce myself : Guillaume FORTAINE, French engineer in informatics. I would want to build a start up to sell mobile phones ( OEM Level ). I am currently in discussions with investors. ?We are currently searching people with a strong background in PowerPC / uclibc-nptl / Kernel development Our business model is in its early stage, but we would be interested into a break oppposite to the legacy one of our competitors who are nearly all ARM based. Our choice is to use the PowerPC ?architecture : all the challenge is here, that's why we need people with a strong background... ? This is a very big project. We would want to sign a contract with people ready for at least a one year full-time contract. ?We look forward to your answer, ?Best Regards, ??????????????????????Guillaume From rep.nop at aon.at Sat Nov 4 12:25:47 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sat, 4 Nov 2006 21:25:47 +0100 Subject: [BusyBox 0001076]: "ip addr del" does not work In-Reply-To: <200610262337.12161.vda.linux@googlemail.com> References: <6f174020f2f8d7b606bc29db1d78fd43@busybox.net> <200610262134.53740.vda.linux@googlemail.com> <200610262337.12161.vda.linux@googlemail.com> Message-ID: <20061104202547.GF18267@aon.at> On Thu, Oct 26, 2006 at 11:37:12PM +0200, Denis Vlasenko wrote: >On Thursday 26 October 2006 21:40, Robert P. J. Day wrote: >> > > int compare_string_array(const char * const string_array[], const char *key) >> > > { >> > > return compare_string_array_internal(string_array, key, 1); >> > > } >> > >> > compare_string_array({"aaa","bbb","ccc"}, "b") returns 1 -- ??! >> > >> > > int compare_substring_array(const char * const string_array[], const char *key) >> > >> > Name of this one doesn't immediately say what it is doing. >> > I have hard time imagining a "substring array" at all... >> > >> > compare_string_array() is also can have better name. >> > find_in_string_array()? >> >> there's a recommended rule that functions be given names so that, when >> used in their natural context, they make intuitive sense. for >> instance, >> >> if (compare_string_array(...)) { >> >> doesn't really suggest what's being returned, but >> >> if (string_array_contains_string(...)) { >> >> should be immediately obvious. or something like that. > >compare_string_array() returns index of string, not just 1/0. >index_in_str_array()? Given that my copy that reads strncmp() in there still lives on locally, i take it that this isn't fixed yet? From vda.linux at googlemail.com Sat Nov 4 16:57:26 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 5 Nov 2006 01:57:26 +0100 Subject: [BusyBox 0001076]: "ip addr del" does not work In-Reply-To: <20061104202547.GF18267@aon.at> References: <6f174020f2f8d7b606bc29db1d78fd43@busybox.net> <200610262337.12161.vda.linux@googlemail.com> <20061104202547.GF18267@aon.at> Message-ID: <200611050157.26110.vda.linux@googlemail.com> > >> there's a recommended rule that functions be given names so that, when > >> used in their natural context, they make intuitive sense. for > >> instance, > >> > >> if (compare_string_array(...)) { > >> > >> doesn't really suggest what's being returned, but > >> > >> if (string_array_contains_string(...)) { > >> > >> should be immediately obvious. or something like that. > > > >compare_string_array() returns index of string, not just 1/0. > >index_in_str_array()? > > Given that my copy that reads strncmp() in there still lives on locally, > i take it that this isn't fixed yet? Sorry, I was working on making ps vaguely resemble POSIX ps lately... now it is good time to actually test how it works. (I use ps in my shutdown scripts) What is the problem here? In svn I see the following: int compare_string_array(const char * const string_array[], const char *key) { int i; for (i = 0; string_array[i] != 0; i++) { if (strcmp(string_array[i], key) == 0) { return i; } } return -i; } Apart from name in need of changing to index_in_str_array(), I don't see any problem here. Please give more details. -- vda From rep.nop at aon.at Sun Nov 5 02:47:08 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun, 5 Nov 2006 11:47:08 +0100 Subject: [BusyBox 0001076]: "ip addr del" does not work In-Reply-To: <200611050157.26110.vda.linux@googlemail.com> References: <6f174020f2f8d7b606bc29db1d78fd43@busybox.net> <200610262337.12161.vda.linux@googlemail.com> <20061104202547.GF18267@aon.at> <200611050157.26110.vda.linux@googlemail.com> Message-ID: <20061105104708.GG18267@aon.at> On Sun, Nov 05, 2006 at 01:57:26AM +0100, Denis Vlasenko wrote: >> >> there's a recommended rule that functions be given names so that, when >> >> used in their natural context, they make intuitive sense. for >> >> instance, >> >> >> >> if (compare_string_array(...)) { >> >> >> >> doesn't really suggest what's being returned, but >> >> >> >> if (string_array_contains_string(...)) { >> >> >> >> should be immediately obvious. or something like that. >> > >> >compare_string_array() returns index of string, not just 1/0. >> >index_in_str_array()? >> >> Given that my copy that reads strncmp() in there still lives on locally, >> i take it that this isn't fixed yet? > >Sorry, I was working on making ps vaguely resemble POSIX ps lately... >now it is good time to actually test how it works. >(I use ps in my shutdown scripts) > > >What is the problem here? In svn I see the following: http://busybox.net/bugs/view.php?id=1076 > >int compare_string_array(const char * const string_array[], const char *key) >{ > int i; > > for (i = 0; string_array[i] != 0; i++) { > if (strcmp(string_array[i], key) == 0) { > return i; > } > } > return -i; >} > >Apart from name in need of changing to index_in_str_array(), I don't >see any problem here. Please give more details. The fix that went in as r16439 is wrong: Index: networking/libiproute/ipaddress.c =================================================================== --- networking/libiproute/ipaddress.c (revision 16438) +++ networking/libiproute/ipaddress.c (revision 16439) @@ -800,7 +800,7 @@ int do_ipaddr(int argc, char **argv) { static const char *const commands[] = { - "add", "delete", "list", "show", "lst", "flush", 0 + "add", "del", "delete", "list", "show", "lst", "flush", 0 }; int command_num = 2; [snip rest that introduced another bug, see the link above; The report was automatically sent to the busybox-cvs like any other bugtracker note]. "del" and (i suppose) "lst" are superfluous. We are supposed to recognize e.g. "a" "ad" as "add", etc. Adding every possible string strikes me as a very bad idea, size-wise. A sane approach is to use - if (strcmp(string_array[i], key) == 0) { + if (strncmp(string_array[i], key, strlen(key)) == 0) { but that did beg the question if we need an indicator to only accept exact matches (like the current code) or not (like the strncmp case). See earlier discussion in this thread. From minh1970 at yahoo.com Sun Nov 5 08:22:18 2006 From: minh1970 at yahoo.com (Min Hsu) Date: Sun, 5 Nov 2006 08:22:18 -0800 (PST) Subject: sendCgi() forked child needs to close opened server socket and accepted socket Message-ID: <20061105162218.34340.qmail@web53601.mail.yahoo.com> Hi List, I have tried to use busybox httpd CGI to launch busybox telnetd and found that telnetd inherits httpd's opend server socket and accepted socket, I checked the source code of httpd.c and found sendCgi() forked child does NOT close these sockets. The following patch will fix this issue. Regards, ============================================================ --- httpd.c.orig 2006-11-05 10:04:51.000000000 -0600 +++ httpd.c 2006-11-05 10:07:20.000000000 -0600 @@ -161,6 +161,7 @@ #endif #if ENABLE_FEATURE_HTTPD_WITHOUT_INETD + int server_socket; int accepted_socket; # define a_c_r config->accepted_socket # define a_c_w config->accepted_socket @@ -1038,6 +1039,9 @@ close(fromCgi[0]); close(fromCgi[1]); + close(config->accepted_socket); + close(config->server_socket); + /* * Find PATH_INFO. */ @@ -1975,6 +1979,7 @@ xchdir(home_httpd); #if ENABLE_FEATURE_HTTPD_WITHOUT_INETD server = openServer(); + config->server_socket = server; # ifdef CONFIG_FEATURE_HTTPD_SETUID /* drop privileges */ if (opt & OPT_SETUID) { ____________________________________________________________________________________ Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates (http://voice.yahoo.com) From mootaccount at gmail.com Sun Nov 5 08:30:01 2006 From: mootaccount at gmail.com (Moot Account) Date: Mon, 6 Nov 2006 00:30:01 +0800 Subject: Custom initrd using busybox Message-ID: Hi, This is a bloated idea but it's just an exercise. The idea is to use the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). This initrd should mount the _real_ rootfs using pivot_root. The real rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first by the kernel after mounting the initrd. Instead of pointing it to /bin/busybox, I'm going to create a custom linuxrc. My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 and execute the /linuxrc, which is still pointed /bin/busybox. I need to chroot because /linuxrc will initialize my rootfs and put up the login (ie /etc/inittab getty). Here are my arguments to the kernel: linux /boot/bzImage console=ttyS0,9600 (since it's a serial console) This is the custom linuxrc that does _not_ work: #!/bin/sh echo "linuxrc execute" mount -t proc /proc /proc mkdir new_root mount -t ext2 /dev/hda2 /new_root umount proc cd /new_root pivot_root . initrd mount -t proc proc proc mount -t devfs devfs dev exec /usr/sbin/chroot . 'exec /linuxrc' \ dev/console 2>&1 I'm stuck after the execution pivot_root. It seems that dev/console is busy. Thanks for any help. From zsdemi at psolv.hu Sun Nov 5 08:33:25 2006 From: zsdemi at psolv.hu (=?ISO-8859-2?Q?D=E9mi_Zsolt?=) Date: Sun, 05 Nov 2006 17:33:25 +0100 Subject: httpd on ppp0 Message-ID: <454E1255.5060302@psolv.hu> Hi 4ALL, I have a working busybox httpd server on my at91rm9200 based board (I can reach it throught ethernet). When I activate the gprs connnection on the board and there is no eth0 just ppp0 (ifdown eth0; pon gprs) I can't reach the httpd server with the public ip address of gprs connection. The telnted server do the same. Any idea? Is it normal? Thank you for your help, in advance! -- Best Regards, Zsolt D?mi From strange at nsk.no-ip.org Sun Nov 5 08:52:52 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 5 Nov 2006 16:52:52 +0000 Subject: Custom initrd using busybox In-Reply-To: References: Message-ID: <20061105165252.GA10932@nsk.no-ip.org> On Mon, Nov 06, 2006 at 12:30:01AM +0800, Moot Account wrote: > Hi, > > This is a bloated idea but it's just an exercise. The idea is to use > the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). > This initrd should mount the _real_ rootfs using pivot_root. The real > rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs > built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. > > Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first > by the kernel after mounting the initrd. Instead of pointing it to > /bin/busybox, I'm going to create a custom linuxrc. > > My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 > and execute the /linuxrc, which is still pointed /bin/busybox. I need > to chroot because /linuxrc will initialize my rootfs and put up the > login (ie /etc/inittab getty). > > Here are my arguments to the kernel: > linux /boot/bzImage console=ttyS0,9600 > (since it's a serial console) > > This is the custom linuxrc that does _not_ work: > > #!/bin/sh > echo "linuxrc execute" > mount -t proc /proc /proc > mkdir new_root > mount -t ext2 /dev/hda2 /new_root > umount proc > cd /new_root > pivot_root . initrd > mount -t proc proc proc > mount -t devfs devfs dev > exec /usr/sbin/chroot . 'exec /linuxrc' \ > dev/console 2>&1 > > I'm stuck after the execution pivot_root. It seems that dev/console is busy. And this stops linuxrc from continuing? Try: ... cd /new_root exec < dev/console &> dev/console pivot_root . initrd ... -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/78ae3c9d/attachment.pgp From strange at nsk.no-ip.org Sun Nov 5 08:54:54 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 5 Nov 2006 16:54:54 +0000 Subject: httpd on ppp0 In-Reply-To: <454E1255.5060302@psolv.hu> References: <454E1255.5060302@psolv.hu> Message-ID: <20061105165454.GB10932@nsk.no-ip.org> On Sun, Nov 05, 2006 at 05:33:25PM +0100, D?mi Zsolt wrote: > Hi 4ALL, > > I have a working busybox httpd server on my at91rm9200 based board (I > can reach it throught ethernet). > > When I activate the gprs connnection on the board and there is no eth0 > just ppp0 (ifdown eth0; pon gprs) I can't reach the httpd server with > the public ip address of gprs connection. The telnted server do the > same. Any idea? Is it normal? It could be a restriction imposed by your operator. Can you access an httpd server on a normal pc connected via gprs? -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/3c44fe33/attachment.pgp From mootaccount at gmail.com Sun Nov 5 09:09:43 2006 From: mootaccount at gmail.com (Moot Account) Date: Mon, 6 Nov 2006 01:09:43 +0800 Subject: Custom initrd using busybox In-Reply-To: <20061105165252.GA10932@nsk.no-ip.org> References: <20061105165252.GA10932@nsk.no-ip.org> Message-ID: Thanks! I'll try this when I get to the board (Soekris net4801) tomorrow. But I have another question. How is /sbin/init ( ->busybox ) accessed. When I use: exec /usr/sbin/chroot . /sbin/init dev/console 2>&1 the usage of init is printed. This probably means that init is not run as PID 1. Also, when I use /linuxrc it seems to be stuck. Any ideas? Thanks again. -Lenmarc On 11/6/06, Luciano Miguel Ferreira Rocha wrote: > On Mon, Nov 06, 2006 at 12:30:01AM +0800, Moot Account wrote: > > Hi, > > > > This is a bloated idea but it's just an exercise. The idea is to use > > the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz). > > This initrd should mount the _real_ rootfs using pivot_root. The real > > rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs > > built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2. > > > > Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first > > by the kernel after mounting the initrd. Instead of pointing it to > > /bin/busybox, I'm going to create a custom linuxrc. > > > > My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2 > > and execute the /linuxrc, which is still pointed /bin/busybox. I need > > to chroot because /linuxrc will initialize my rootfs and put up the > > login (ie /etc/inittab getty). > > > > Here are my arguments to the kernel: > > linux /boot/bzImage console=ttyS0,9600 > > (since it's a serial console) > > > > This is the custom linuxrc that does _not_ work: > > > > #!/bin/sh > > echo "linuxrc execute" > > mount -t proc /proc /proc > > mkdir new_root > > mount -t ext2 /dev/hda2 /new_root > > umount proc > > cd /new_root > > pivot_root . initrd > > mount -t proc proc proc > > mount -t devfs devfs dev > > exec /usr/sbin/chroot . 'exec /linuxrc' \ > > dev/console 2>&1 > > > > I'm stuck after the execution pivot_root. It seems that dev/console is busy. > > And this stops linuxrc from continuing? > > Try: > > ... > cd /new_root > exec < dev/console &> dev/console > pivot_root . initrd > ... From strange at nsk.no-ip.org Sun Nov 5 09:20:31 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 5 Nov 2006 17:20:31 +0000 Subject: Custom initrd using busybox In-Reply-To: References: <20061105165252.GA10932@nsk.no-ip.org> Message-ID: <20061105172031.GC10932@nsk.no-ip.org> On Mon, Nov 06, 2006 at 01:09:43AM +0800, Moot Account wrote: > Thanks! I'll try this when I get to the board (Soekris net4801) tomorrow. > > But I have another question. How is /sbin/init ( ->busybox ) accessed. > When I use: > > exec /usr/sbin/chroot . /sbin/init dev/console 2>&1 > > the usage of init is printed. This probably means that init is not run > as PID 1. Also, when I use /linuxrc it seems to be stuck. > > Any ideas? Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init (pid isn't 1). You're supposed to set the real root device writing to a /proc file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts the real root device and executes init. You can change that behaviour by booting your kernel with "init=/linuxrc root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). Other option you could check out would be using initramfs instead of old initrd: 1. name your script /init instead of /linuxrc; 2. call exec switch_root instead of pivot_root (and switch_root isn't supposed to return, it calls init by itself); 3. create the new "initrd" as a new-format cpio file: find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img More information about initramfs and initrd can be found in a kernel source tree: - Documentation/initrd.txt - Documentation/filesystems/ramfs-rootfs-initramfs.txt - Documentation/early-userspace/README -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/32f2f1f3/attachment-0001.pgp From vda.linux at googlemail.com Sun Nov 5 09:24:47 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 5 Nov 2006 18:24:47 +0100 Subject: [BusyBox 0001076]: "ip addr del" does not work In-Reply-To: <20061105104708.GG18267@aon.at> References: <6f174020f2f8d7b606bc29db1d78fd43@busybox.net> <200611050157.26110.vda.linux@googlemail.com> <20061105104708.GG18267@aon.at> Message-ID: <200611051824.47787.vda.linux@googlemail.com> > Index: networking/libiproute/ipaddress.c > =================================> --- networking/libiproute/ipaddress.c (revision 16438) > +++ networking/libiproute/ipaddress.c (revision 16439) > @@ -800,7 +800,7 @@ > int do_ipaddr(int argc, char **argv) > { > static const char *const commands[] > - "add", "delete", "list", "show", "lst", "flush", 0 > + "add", "del", "delete", "list", "show", "lst", "flush", 0 > }; > > int command_num > [snip rest that introduced another bug, see the link above; The report > was automatically sent to the busybox-cvs like any other bugtracker note]. "another bug" is that command_num wasn't updated to 3, right? > "del" and (i suppose) "lst" are superfluous. > We are supposed to recognize e.g. "a" "ad" as "add", etc. > Adding every possible string strikes me as a very bad idea, size-wise. > > > A sane approach is to use > - if (strcmp(string_array[i], key) = 0) { > + if (strncmp(string_array[i], key, strlen(key)) = 0) { > but that did beg the question if we need an indicator to only accept > exact matches (like the current code) or not (like the strncmp case). > See earlier discussion in this thread. Do you like attached patch? -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 8.patch Type: text/x-diff Size: 7932 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/d8b49e8d/attachment.bin From rep.nop at aon.at Sun Nov 5 09:59:15 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun, 5 Nov 2006 18:59:15 +0100 Subject: [BusyBox 0001076]: "ip addr del" does not work In-Reply-To: <200611051824.47787.vda.linux@googlemail.com> References: <6f174020f2f8d7b606bc29db1d78fd43@busybox.net> <200611050157.26110.vda.linux@googlemail.com> <20061105104708.GG18267@aon.at> <200611051824.47787.vda.linux@googlemail.com> Message-ID: <20061105175914.GJ18267@aon.at> On Sun, Nov 05, 2006 at 06:24:47PM +0100, Denis Vlasenko wrote: >> Index: networking/libiproute/ipaddress.c >> =================================================================== >> --- networking/libiproute/ipaddress.c (revision 16438) >> +++ networking/libiproute/ipaddress.c (revision 16439) >> @@ -800,7 +800,7 @@ >> int do_ipaddr(int argc, char **argv) >> { >> static const char *const commands[] = { >> - "add", "delete", "list", "show", "lst", "flush", 0 >> + "add", "del", "delete", "list", "show", "lst", "flush", 0 >> }; >> >> int command_num = 2; >> [snip rest that introduced another bug, see the link above; The report >> was automatically sent to the busybox-cvs like any other bugtracker note]. > >"another bug" is that command_num wasn't updated to 3, right? right. > >> "del" and (i suppose) "lst" are superfluous. >> We are supposed to recognize e.g. "a" "ad" as "add", etc. >> Adding every possible string strikes me as a very bad idea, size-wise. >> >> >> A sane approach is to use >> - if (strcmp(string_array[i], key) == 0) { >> + if (strncmp(string_array[i], key, strlen(key)) == 0) { >> but that did beg the question if we need an indicator to only accept >> exact matches (like the current code) or not (like the strncmp case). >> See earlier discussion in this thread. > >Do you like attached patch? Yes, i like it much better, from a short glance (and without having tested it if "ip route a" throws "ambiguous command" or defaults to add..). Thanks for looking into it! PS: A few vaguely related sidenotes. - I'd remove "chg", and point people to "change" instead. Not sure how many would complain about this, though. - iplink looks like is may benefit from redoing the way it parses it's arguments, too (just as a sidenote). - iproute.c: Instead of bb_error_msg_and_die("need at least destination address"); use shorter bb_error_msg_and_die("missing destination address"); Also this: bb_error_msg_and_die("an error :-)"); sounds a bit odd ;) From vda.linux at googlemail.com Sun Nov 5 10:02:18 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 5 Nov 2006 19:02:18 +0100 Subject: [BusyBox 0001076]: "ip addr del" does not work In-Reply-To: <200611051824.47787.vda.linux@googlemail.com> References: <6f174020f2f8d7b606bc29db1d78fd43@busybox.net> <20061105104708.GG18267@aon.at> <200611051824.47787.vda.linux@googlemail.com> Message-ID: <200611051902.18378.vda.linux@googlemail.com> On Sunday 05 November 2006 18:24, Denis Vlasenko wrote: > > Index: networking/libiproute/ipaddress.c > > =================================================================== > > --- networking/libiproute/ipaddress.c (revision 16438) > > +++ networking/libiproute/ipaddress.c (revision 16439) > > @@ -800,7 +800,7 @@ > > int do_ipaddr(int argc, char **argv) > > { > > static const char *const commands[] = { > > - "add", "delete", "list", "show", "lst", "flush", 0 > > + "add", "del", "delete", "list", "show", "lst", "flush", 0 > > }; > > > > int command_num = 2; > > [snip rest that introduced another bug, see the link above; The report > > was automatically sent to the busybox-cvs like any other bugtracker note]. > > "another bug" is that command_num wasn't updated to 3, right? > > > "del" and (i suppose) "lst" are superfluous. > > We are supposed to recognize e.g. "a" "ad" as "add", etc. > > Adding every possible string strikes me as a very bad idea, size-wise. > > > > > > A sane approach is to use > > - if (strcmp(string_array[i], key) == 0) { > > + if (strncmp(string_array[i], key, strlen(key)) == 0) { > > but that did beg the question if we need an indicator to only accept > > exact matches (like the current code) or not (like the strncmp case). > > See earlier discussion in this thread. > > Do you like attached patch? It didn't work well in testing, this one should be better: -- vda -------------- next part -------------- A non-text attachment was scrubbed... Name: 8.patch Type: text/x-diff Size: 9923 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/d867245f/attachment.bin From rep.nop at aon.at Sun Nov 5 10:07:30 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun, 5 Nov 2006 19:07:30 +0100 Subject: Custom initrd using busybox In-Reply-To: <20061105172031.GC10932@nsk.no-ip.org> References: <20061105165252.GA10932@nsk.no-ip.org> <20061105172031.GC10932@nsk.no-ip.org> Message-ID: <20061105180730.GK18267@aon.at> On Sun, Nov 05, 2006 at 05:20:31PM +0000, Luciano Miguel Ferreira Rocha wrote: >On Mon, Nov 06, 2006 at 01:09:43AM +0800, Moot Account wrote: >You can change that behaviour by booting your kernel with "init=/linuxrc >root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). resp. root=0100 which wastes less memory ;) btw, is there a way to flush all or some of these convenience vars out of the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i admit.. From floydpink at gmail.com Sun Nov 5 10:49:19 2006 From: floydpink at gmail.com (Jason Schoon) Date: Sun, 5 Nov 2006 12:49:19 -0600 Subject: Custom initrd using busybox In-Reply-To: <20061105180730.GK18267@aon.at> References: <20061105165252.GA10932@nsk.no-ip.org> <20061105172031.GC10932@nsk.no-ip.org> <20061105180730.GK18267@aon.at> Message-ID: <78a54e1b0611051049rbba3a7tc49a891707cffc73@mail.gmail.com> On 11/5/06, Bernhard Fischer wrote: > > On Sun, Nov 05, 2006 at 05:20:31PM +0000, Luciano Miguel Ferreira Rocha > wrote: > >On Mon, Nov 06, 2006 at 01:09:43AM +0800, Moot Account wrote: > > >You can change that behaviour by booting your kernel with "init=/linuxrc > >root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). > > resp. root00 which wastes less memory ;) > > btw, is there a way to flush all or some of these convenience vars out of > the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i admit.. By convenience vars, do you mean such as /dev/ram0? If so, turning of sysfs support will get rid of them. In many embedded scenarios sysfs doesn't buy you much anyway. If you are hotplugging or something similar though, the space savings are not likely to be worth not having sysfs. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061105/8a59f7e3/attachment.html From floydpink at gmail.com Sun Nov 5 10:55:15 2006 From: floydpink at gmail.com (Jason Schoon) Date: Sun, 5 Nov 2006 12:55:15 -0600 Subject: Custom initrd using busybox In-Reply-To: <78a54e1b0611051049rbba3a7tc49a891707cffc73@mail.gmail.com> References: <20061105165252.GA10932@nsk.no-ip.org> <20061105172031.GC10932@nsk.no-ip.org> <20061105180730.GK18267@aon.at> <78a54e1b0611051049rbba3a7tc49a891707cffc73@mail.gmail.com> Message-ID: <78a54e1b0611051055u39198c6t3df9ec7bdc671182@mail.gmail.com> On 11/5/06, Jason Schoon wrote: > > On 11/5/06, Bernhard Fischer wrote: > > > > On Sun, Nov 05, 2006 at 05:20:31PM +0000, Luciano Miguel Ferreira Rocha > > wrote: > > >On Mon, Nov 06, 2006 at 01:09:43AM +0800, Moot Account wrote: > > > > >You can change that behaviour by booting your kernel with > > "init=/linuxrc > > >root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC). > > > > resp. root00 which wastes less memory ;) > > > > btw, is there a way to flush all or some of these convenience vars out > > of > > the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i admit.. > > > > > By convenience vars, do you mean such as /dev/ram0? If so, turning of > sysfs support will get rid of them. In many embedded scenarios sysfs > doesn't buy you much anyway. If you are hotplugging or something similar > though, the space savings are not likely to be worth not having sysfs. > Nevermind, I figured out what you were really asking. I have never seen a scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were not available via /proc/cmdline. I'm guessing that means there isn't currently a way to get them out of memory. If anything, the linux-tiny guys might have a config option to do that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061105/68741ca9/attachment.htm From rep.nop at aon.at Sun Nov 5 11:11:15 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Sun, 5 Nov 2006 20:11:15 +0100 Subject: Custom initrd using busybox In-Reply-To: <78a54e1b0611051055u39198c6t3df9ec7bdc671182@mail.gmail.com> References: <20061105165252.GA10932@nsk.no-ip.org> <20061105172031.GC10932@nsk.no-ip.org> <20061105180730.GK18267@aon.at> <78a54e1b0611051049rbba3a7tc49a891707cffc73@mail.gmail.com> <78a54e1b0611051055u39198c6t3df9ec7bdc671182@mail.gmail.com> Message-ID: <20061105191115.GL18267@aon.at> On Sun, Nov 05, 2006 at 12:55:15PM -0600, Jason Schoon wrote: >On 11/5/06, Jason Schoon wrote: >>> resp. root=0100 which wastes less memory ;) >>> >>> btw, is there a way to flush all or some of these convenience vars out >>> of >>> the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i admit.. >>> > > I have never seen a >scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were not >available via /proc/cmdline. I'm guessing that means there isn't currently >a way to get them out of memory. > >If anything, the linux-tiny guys might have a config option to do that. Yeah, thought so too. Sounds like __user_init along with something like sysctl (or better, putting it into a /del_usermem fops.flush or the like). hm.. From vda.linux at googlemail.com Sun Nov 5 11:53:43 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 5 Nov 2006 20:53:43 +0100 Subject: sendCgi() forked child needs to close opened server socket and accepted socket In-Reply-To: <20061105162218.34340.qmail@web53601.mail.yahoo.com> References: <20061105162218.34340.qmail@web53601.mail.yahoo.com> Message-ID: <200611052053.43607.vda.linux@googlemail.com> On Sunday 05 November 2006 17:22, Min Hsu wrote: > Hi List, > > I have tried to use busybox httpd CGI to launch busybox telnetd and > found > that telnetd inherits httpd's opend server socket and accepted socket, > I > checked the source code of httpd.c and found sendCgi() forked child > does > NOT close these sockets. The following patch will fix this issue. Applied, thanks. httpd needs much more love. At least this needs improving: * audit/fix /../ style attacks * reduce #ifdef forest * make standalone/inetd a runtime, not compile-time option. -- vda From vda.linux at googlemail.com Sun Nov 5 11:56:01 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Sun, 5 Nov 2006 20:56:01 +0100 Subject: httpd on ppp0 In-Reply-To: <454E1255.5060302@psolv.hu> References: <454E1255.5060302@psolv.hu> Message-ID: <200611052056.01319.vda.linux@googlemail.com> On Sunday 05 November 2006 17:33, D?mi Zsolt wrote: > Hi 4ALL, > > I have a working busybox httpd server on my at91rm9200 based board (I > can reach it throught ethernet). > > When I activate the gprs connnection on the board and there is no eth0 > just ppp0 (ifdown eth0; pon gprs) I can't reach the httpd server with > the public ip address of gprs connection. The telnted server do the > same. Any idea? Is it normal? Do you see httpd's socket in "lsof -nP"? Is it bound to 0.0.0.0 or to specific IP? tcpdump of connection attempt? strace p `pidof httpd` of the same? -- vda From rob at landley.net Sun Nov 5 12:19:40 2006 From: rob at landley.net (Rob Landley) Date: Sun, 5 Nov 2006 15:19:40 -0500 Subject: Custom initrd using busybox In-Reply-To: <20061105172031.GC10932@nsk.no-ip.org> References: <20061105172031.GC10932@nsk.no-ip.org> Message-ID: <200611051519.40680.rob@landley.net> On Sunday 05 November 2006 12:20 pm, Luciano Miguel Ferreira Rocha wrote: > Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init (pid > isn't 1). You're supposed to set the real root device writing to a /proc > file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts > the real root device and executes init. Using initramfs and switch_root is way more straightforward than this. And doesn't have the magic behind the scenes stuff (like reparenting every running process whose ".", "..", or "/" points to the old root, yes including kernel threads). Just sayin'... Rob > Other option you could check out would be using initramfs instead of old > initrd: > > 1. name your script /init instead of /linuxrc; Or supply the kernel the "rdinit=/blah" argument to tell it what you called it. > 2. call exec switch_root instead of pivot_root (and switch_root isn't > supposed to return, it calls init by itself); Don't forget the "exec". Common mistake. If it's not PID 1, it'll abort. > 3. create the new "initrd" as a new-format cpio file: > find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img The kernel can do this for you, if you prefer. And even build it into the bzImage. > - Documentation/filesystems/ramfs-rootfs-initramfs.txt I wrote that one. If it's missing something, let me know. I also wrote a couple articles for TimeSys, earlier this year. It's a little long-winded, but might help: http://www.timesys.com/timesource/march_06.htm http://timesys.com/timesource/initramfs.htm Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Sun Nov 5 12:26:42 2006 From: rob at landley.net (Rob Landley) Date: Sun, 5 Nov 2006 15:26:42 -0500 Subject: [entirely off topic] In-Reply-To: <20061105172031.GC10932@nsk.no-ip.org> References: <20061105172031.GC10932@nsk.no-ip.org> Message-ID: <200611051526.43121.rob@landley.net> On Sunday 05 November 2006 12:20 pm, Luciano Miguel Ferreira Rocha wrote: > find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img Now _that_ is an ugly set of command line options (for cpio). Let's see, that should equate to: cpio -0 -o -H newc I'm interested in this because I'm about halfway through writing toybox's get_optflags(), which doesn't use getopt() so I have to parse all this myself. It's not actually that hard, but the tricky case is where some of your arguments have no dash, ala ps or tar. Then you can wind up with stuff like: tar xjfCv filename.tbz dirname blah Which is equivalent to: tar -x -j -f filename.tbz -C dirname -v blah And _not_ equivalent to: tar -x -j -f C -v filename.tbz blah Which is what you get with the getopt() in uClibc 0.9.28. (I realize this is a funky corner case, but it's one that bit me and I want to get it _right_ this time.) It looks like the nodash mode and the dash mode of the option parser have different sequencing requirements. Ok, I can do that... Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From zsdemi at psolv.hu Sun Nov 5 12:40:27 2006 From: zsdemi at psolv.hu (=?ISO-8859-2?Q?D=E9mi_Zsolt?=) Date: Sun, 05 Nov 2006 21:40:27 +0100 Subject: httpd on ppp0 In-Reply-To: <200611052056.01319.vda.linux@googlemail.com> References: <454E1255.5060302@psolv.hu> <200611052056.01319.vda.linux@googlemail.com> Message-ID: <454E4C3B.3060903@psolv.hu> Hi, > Do you see httpd's socket in "lsof -nP"? Is it bound to 0.0.0.0 or > to specific IP? > I will check it tomorrow! I have started the httpd server as follow: /usr/sbin/http -h /var/www I have tried with this conf file too (http://wiki.openwrt.org/OpenWrtDocs/httpd.conf), but the result is the same. >It could be a restriction imposed by your operator. I fear from it... :-) I will all ask my operator tomorrow! Thanks!!! Zsolt From bet at rahul.net Sun Nov 5 13:52:15 2006 From: bet at rahul.net (Bennett Todd) Date: Sun, 5 Nov 2006 21:52:15 +0000 Subject: ash backticks busted in 1.2.2.1 In-Reply-To: <20061101223336.GD95055@og.latency.net> References: <20061101182547.GX95055@og.latency.net> <45491E9E.2050804@avtrex.com> <20061101223336.GD95055@og.latency.net> Message-ID: <20061105215215.GA2841@rahul.net> 2006-11-01T22:33:36 Bennett Todd: > I'll try rebuilding 1.2.2.1 on my home uclibc-based distro (in > a few days, I'm afraid), and will send another note if I can > reproduce the problem there, otherwise we'll happily blame it on > glibc. Just recompiled, noticed something odd. It printed: LINK busybox_unstripped /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:21:2: warning: #warning Static linking against glibc produces buggy executables /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:22:2: warning: #warning See sources.redhat.com/bugzilla/show_bug.cgi?id=3400 /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:23:2: warning: #warning Note that glibc is utterly unsuitable for static linking anyway. This despite the fact that the chroot jail where I built it has no glibc. On the other hand, the good news is that ash backticks work fine:-). -Bennett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/3f9caaba/attachment.pgp From bet at rahul.net Sun Nov 5 13:38:59 2006 From: bet at rahul.net (Bennett Todd) Date: Sun, 5 Nov 2006 21:38:59 +0000 Subject: no signature for 1.2.2.1? Message-ID: <20061105213859.GB30736@rahul.net> My software packaging / automated build was expecting http://www.busybox.net/downloads/busybox-1.2.2.1.tar.bz2.sign but didn't find it. -Bennett -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/f2372c05/attachment.pgp From rob at landley.net Sun Nov 5 14:10:26 2006 From: rob at landley.net (Rob Landley) Date: Sun, 5 Nov 2006 17:10:26 -0500 Subject: no signature for 1.2.2.1? In-Reply-To: <20061105213859.GB30736@rahul.net> References: <20061105213859.GB30736@rahul.net> Message-ID: <200611051710.26766.rob@landley.net> On Sunday 05 November 2006 4:38 pm, Bennett Todd wrote: > My software packaging / automated build was expecting > http://www.busybox.net/downloads/busybox-1.2.2.1.tar.bz2.sign > but didn't find it. > > -Bennett I didn't put that one out, Denis did. My last release was 1.2.2, and I didn't notice that it was triggering the glibc static linking bug. (Which is a bug in glibc, not in busybox, but we're triggering it.) The proper fix is not to use --gc-sections when statically linking against glibc, although detecting glibc at build time turns out to be non-trivial. Instead Denis put in a warning. As far as I know, the _only_ difference between 1.2.2 and 1.2.2.1 is the warning. It doesn't actually fix anything, just warns you about a prominent glibc bug. (Which the glibc guys refuse to fix since they insist it's a gcc bug, which it isn't.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From strange at nsk.no-ip.org Sun Nov 5 15:02:12 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 5 Nov 2006 23:02:12 +0000 Subject: [entirely off topic] In-Reply-To: <200611051526.43121.rob@landley.net> References: <20061105172031.GC10932@nsk.no-ip.org> <200611051526.43121.rob@landley.net> Message-ID: <20061105230212.GA24095@nsk.no-ip.org> On Sun, Nov 05, 2006 at 03:26:42PM -0500, Rob Landley wrote: > On Sunday 05 November 2006 12:20 pm, Luciano Miguel Ferreira Rocha wrote: > > find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img > > Now _that_ is an ugly set of command line options (for cpio). Thank you. :) I used to use -0oc. But after wasting a coule of hours trying to make a kernel recognize a cpio archive, I found that -c doesn't mean exactly the same thing everywhere. So now I use -Hnewc everywhere. -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/fb8660e1/attachment.pgp From strange at nsk.no-ip.org Sun Nov 5 15:34:31 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 5 Nov 2006 23:34:31 +0000 Subject: Custom initrd using busybox In-Reply-To: <200611051519.40680.rob@landley.net> References: <20061105172031.GC10932@nsk.no-ip.org> <200611051519.40680.rob@landley.net> Message-ID: <20061105233431.GB24095@nsk.no-ip.org> On Sun, Nov 05, 2006 at 03:19:40PM -0500, Rob Landley wrote: > > - Documentation/filesystems/ramfs-rootfs-initramfs.txt > > I wrote that one. If it's missing something, let me know. Information about the rdinit parameter would be nice. :) It is in kernel-parameters.txt but I never searched for such an option. Also, it reads "The program run by the old initrd (which was called /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing /initrd anywhere else. And finally, could you add some bigger warnings about rootfs being ramfs, a non-swappable device? The file does say that initramfs is extracted to rootfs, an instance of ramfs. But I didn't read the file that carefully the first time... I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs, moves all remaining files to the tmpfs, and executes the new init, if anyone is interested. Regards, Luciano Rocha -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061105/6bd4039f/attachment.pgp From rob at landley.net Sun Nov 5 15:43:52 2006 From: rob at landley.net (Rob Landley) Date: Sun, 5 Nov 2006 18:43:52 -0500 Subject: Custom initrd using busybox In-Reply-To: <20061105233431.GB24095@nsk.no-ip.org> References: <200611051519.40680.rob@landley.net> <20061105233431.GB24095@nsk.no-ip.org> Message-ID: <200611051843.52354.rob@landley.net> On Sunday 05 November 2006 6:34 pm, Luciano Miguel Ferreira Rocha wrote: > On Sun, Nov 05, 2006 at 03:19:40PM -0500, Rob Landley wrote: > > > - Documentation/filesystems/ramfs-rootfs-initramfs.txt > > > > I wrote that one. If it's missing something, let me know. > > Information about the rdinit parameter would be nice. :) I think the current version (2.6.18 and up) mentions it? > It is in kernel-parameters.txt but I never searched for such an option. > > Also, it reads "The program run by the old initrd (which was called > /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing > /initrd anywhere else. Yeah, that's linuxrc. > And finally, could you add some bigger warnings about rootfs being > ramfs, a non-swappable device? There are patches floating around to make it tmpfs if you have tmpfs built into the kernel. I keep thinking they've been integrated. (This is the point of tmpfs.) > The file does say that initramfs is > extracted to rootfs, an instance of ramfs. But I didn't read the file > that carefully the first time... It should be possible for this to be tmpfs. When did this last crop up... http://lkml.org/lkml/2006/7/30/120 Dunno if it got integrated or not, but there's a start... > I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs, > moves all remaining files to the tmpfs, and executes the new init, if > anyone is interested. The proper thing to do is patch the kernel so initramfs is a tmpfs. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From strange at nsk.no-ip.org Sun Nov 5 16:20:07 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Mon, 6 Nov 2006 00:20:07 +0000 Subject: Custom initrd using busybox In-Reply-To: <200611051843.52354.rob@landley.net> References: <200611051519.40680.rob@landley.net> <20061105233431.GB24095@nsk.no-ip.org> <200611051843.52354.rob@landley.net> Message-ID: <20061106002007.GC24095@nsk.no-ip.org> On Sun, Nov 05, 2006 at 06:43:52PM -0500, Rob Landley wrote: > On Sunday 05 November 2006 6:34 pm, Luciano Miguel Ferreira Rocha wrote: > > On Sun, Nov 05, 2006 at 03:19:40PM -0500, Rob Landley wrote: > > > > - Documentation/filesystems/ramfs-rootfs-initramfs.txt > > > > > > I wrote that one. If it's missing something, let me know. > > > > Information about the rdinit parameter would be nice. :) > > I think the current version (2.6.18 and up) mentions it? Yes, the git version has it. It also has a typo: "the kernel's built-in initamfs image." > There are patches floating around to make it tmpfs if you have tmpfs built > into the kernel. I keep thinking they've been integrated. (This is the > point of tmpfs.) They'll be very welcome. > > I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs, > > moves all remaining files to the tmpfs, and executes the new init, if > > anyone is interested. > > The proper thing to do is patch the kernel so initramfs is a tmpfs. The program checks if / is already a tmpfs and only extracts the cpios then. I don't always have control over the kernel used, so I can't force the patch or option, and will keep using the program. Thanks for the pointers anyway. -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061106/3a48050e/attachment-0001.pgp From floydpink at gmail.com Sun Nov 5 18:41:52 2006 From: floydpink at gmail.com (Jason Schoon) Date: Sun, 5 Nov 2006 20:41:52 -0600 Subject: ash backticks busted in 1.2.2.1 In-Reply-To: <20061105215215.GA2841@rahul.net> References: <20061101182547.GX95055@og.latency.net> <45491E9E.2050804@avtrex.com> <20061101223336.GD95055@og.latency.net> <20061105215215.GA2841@rahul.net> Message-ID: <78a54e1b0611051841y4aa04cfeyc1f653164b50d512@mail.gmail.com> On 11/5/06, Bennett Todd wrote: > > 2006-11-01T22:33:36 Bennett Todd: > > I'll try rebuilding 1.2.2.1 on my home uclibc-based distro (in > > a few days, I'm afraid), and will send another note if I can > > reproduce the problem there, otherwise we'll happily blame it on > > glibc. > > Just recompiled, noticed something odd. It printed: > > LINK busybox_unstripped > /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:21:2: > warning: #warning Static linking against glibc produces buggy executables > /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:22:2: > warning: #warning See sources.redhat.com/bugzilla/show_bug.cgi?id400 > /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:23:2: > warning: #warning Note that glibc is utterly unsuitable for static linking > anyway. > > This despite the fact that the chroot jail where I built it has no > glibc. Agreed, I don't believe the check for toolchain is being done correctly. I get this warning when I cross-compile using my uclibc toolchain to do a static build as well. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061105/9def3953/attachment.htm From mihai.buha at nivis.com Mon Nov 6 00:42:16 2006 From: mihai.buha at nivis.com (Mihai Buha) Date: Mon, 6 Nov 2006 03:42:16 -0500 Subject: httpd on ppp0 In-Reply-To: <454E4C3B.3060903@psolv.hu> Message-ID: <0CA821586702744ABD33D819C63E9932AD683B@ATLEXCH01.nivis.com> > >It could be a restriction imposed by your operator. > I fear from it... :-) I will all ask my operator tomorrow! It MUST BE from your operator. GPRS connections are charged on a traffic basis (1 US$ / 1 MiB is typical), and incoming connection requests count as traffic. And due to the lots of port scanning activity on the today's internet, you could easily have to pay a few dollars a month for an unused connection if the provider didn't filter incoming traffic. And if you specifically ask your provider to allow incoming http connections to your device, then a simple SYN flood will send your phone bill through the roof. GPRS is very expensive. You should find a better way to communicate information from that device than a http server. Mihai Buha This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments. From zsdemi at psolv.hu Mon Nov 6 02:35:25 2006 From: zsdemi at psolv.hu (=?ISO-8859-2?Q?D=E9mi_Zsolt?=) Date: Mon, 06 Nov 2006 11:35:25 +0100 Subject: httpd on ppp0 In-Reply-To: <0CA821586702744ABD33D819C63E9932AD683B@ATLEXCH01.nivis.com> References: <0CA821586702744ABD33D819C63E9932AD683B@ATLEXCH01.nivis.com> Message-ID: <454F0FED.9050208@psolv.hu> Hi, > > It MUST BE from your operator. Yes, it is! > then a simple SYN flood will send your phone bill through the roof. > > I see! Thank you very much! -- udv, D?mi Zsolt From hinko.kocevar at cetrtapot.si Mon Nov 6 05:40:02 2006 From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si) Date: Mon, 06 Nov 2006 14:40:02 +0100 Subject: Chargen patch Message-ID: <454F3B32.6040703@cetrtapot.si> ?e???m????$?x????)b?)b??a?????&z??y??!??jYru?"u?m??z?^??n?*'o)???_"??y?^u??? zw?j???W??+a???r??z{lz z???{??LE?0v???+b??^?\"????h?J?????g??g?????m&?{?z???^?~)^r??j)?? '?-1[(?l??????u?l??^?*??-z???V??&???i??Z???????z??{^?~)^?w??kz????^??\??h?????~??z???????az?"???zW?y?h???z?m???*.????b??.???????Zey?v????"??^???r[?z?^j?ez????mn?2n?kzW???^??????????E097h????3?jx?k~4?B?jx?????(?M?~????o4???f?????(q??????????"?i? z??j?-?)???Z??'?{^?????!?????,r??m?Mjg????zzZ??S???{???r???7?V???z?'???j)ZnW??Xm???n?2n?gz????l?????1??mi?fz{l?m4?]t??9??|O?????g???? From floydpink at gmail.com Mon Nov 6 06:15:27 2006 From: floydpink at gmail.com (Jason Schoon) Date: Mon, 6 Nov 2006 08:15:27 -0600 Subject: Chargen patch In-Reply-To: <454F3B32.6040703@cetrtapot.si> References: <454F3B32.6040703@cetrtapot.si> Message-ID: <78a54e1b0611060615n1b9feb4hccce7dfe0436e5f9@mail.gmail.com> On 11/6/06, hinko.kocevar at cetrtapot.si wrote: > > Hello, > > I've been looking for a utility like this for some time and I finally > decided to code the solution by myself. > I've needed a way to generate files with same contents (eg. 16k file > with 0xFF). > Now, doing it in shell with echo took quite sometime (approx 20 minutes) > for 16k file containing only 0xFFs on my slow embedded system. So I > wrote small busybox applet and now I can generate 16k file in few ms;) > > Here is the patch. I hope I didn't forget any bits, otherwise feel free > to request them! > > If you think this could be useful please don't hesitate to include the > applet in next busybox release. You said this was fast compared to echo. Did you compare it to say 'cat', or 'dd'? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061106/a2c2cf1b/attachment.htm From pgf at brightstareng.com Mon Nov 6 06:50:05 2006 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 06 Nov 2006 09:50:05 -0500 Subject: Chargen patch In-Reply-To: hinko.kocevar's message of Mon, 06 Nov 2006 14:40:02 +0100. <454F3B32.6040703@cetrtapot.si> Message-ID: <14182.1162824605@brightstareng.com> > + while (nr--) > + { > + bb_printf ("%c", ch); > + } uh, no. i don't think so. =--------------------- paul fox, pgf at brightstareng.com From rep.nop at aon.at Mon Nov 6 07:15:51 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Mon, 6 Nov 2006 16:15:51 +0100 Subject: Chargen patch In-Reply-To: <14182.1162824605@brightstareng.com> References: <454F3B32.6040703@cetrtapot.si> <14182.1162824605@brightstareng.com> Message-ID: <20061106151551.GA18654@aon.at> On Mon, Nov 06, 2006 at 09:50:05AM -0500, Paul Fox wrote: > > + while (nr--) > > + { > > + bb_printf ("%c", ch); > > + } > > >uh, no. i don't think so. ditto for the getopt() call. Please use getopt32() instead (see libbb/getopt32.c for docs) PS: can't you do something like printf "\xff" | dd instead ? From dalias at aerifal.cx Mon Nov 6 11:35:52 2006 From: dalias at aerifal.cx (Rich Felker) Date: Mon, 6 Nov 2006 14:35:52 -0500 Subject: Chargen patch In-Reply-To: <454F3B32.6040703@cetrtapot.si> References: <454F3B32.6040703@cetrtapot.si> Message-ID: <20061106193552.GD32594@brightrain.aerifal.cx> On Mon, Nov 06, 2006 at 02:40:02PM +0100, hinko.kocevar at cetrtapot.si wrote: > Hello, > > I've been looking for a utility like this for some time and I finally > decided to code the solution by myself. > I've needed a way to generate files with same contents (eg. 16k file > with 0xFF). head dd bs=16384 count=1 < /dev/zero | tr '\0' '\377' Rich From mootaccount at gmail.com Mon Nov 6 12:07:15 2006 From: mootaccount at gmail.com (Moot Account) Date: Mon, 6 Nov 2006 20:07:15 +0000 Subject: Custom initrd using busybox In-Reply-To: <20061106002007.GC24095@nsk.no-ip.org> References: <200611051519.40680.rob@landley.net> <20061105233431.GB24095@nsk.no-ip.org> <200611051843.52354.rob@landley.net> <20061106002007.GC24095@nsk.no-ip.org> Message-ID: Hi all, Thanks all for the help, it's working now! Apparently, Ive been doing the right initrd and initramfs for the past few days. The problem is with my real rootfs (the one in /dev/hda2). Please pardon a newbie. My question is: what's the _difference_ between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz if I enable the gzipped output? I know this is related to buildroot but please answer if it's trivial. =) The working setup NOW is rootfs.i686.ext2.gz which is my initrd and also my real rootfs. The NON-working setup is rootfs.i686.ext2.gz as my initrd and "buildroot/build_i686/root" folder as my real rootfs, which I copied to /dev/hda2. Again, thanks all for the tips! -Lenmarc From carmen.badea at gmail.com Mon Nov 6 14:27:44 2006 From: carmen.badea at gmail.com (Carmen Badea) Date: Mon, 6 Nov 2006 14:27:44 -0800 Subject: BASH issue Message-ID: <953603a60611061427s1c872959vf0ae3ade50814452@mail.gmail.com> Hi everyone, So I am trying to build a JVM on a PPC 405EP board using BusyBox v 1.2.1 . The config files for this JVM use bash and from what I have seen on search results , BusyBox does not have Bash.However, I read somewhere that there is a shell called BBSH that would be a smaller version of BASH. Is that true and if so, what features is BBSH missing and how could I get it (my current version of BusyBox does not have it)? thank you for your help. -- Carmen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061106/d91033e0/attachment.htm From pgf at brightstareng.com Mon Nov 6 15:27:28 2006 From: pgf at brightstareng.com (Paul Fox) Date: Mon, 06 Nov 2006 18:27:28 -0500 Subject: BASH issue In-Reply-To: carmen.badea's message of Mon, 06 Nov 2006 14:27:44 -0800. <953603a60611061427s1c872959vf0ae3ade50814452@mail.gmail.com> Message-ID: <20486.1162855648@brightstareng.com> > > Hi everyone, > > So I am trying to build a JVM on a PPC 405EP board using BusyBox v 1.2.1 . > The config files for this JVM use bash and from what I have seen on search > results , BusyBox does not have Bash.However, I read somewhere that there is > a shell called BBSH that would be a smaller version of BASH. Is that true > and if so, what features is BBSH missing and how could I get it (my current > version of BusyBox does not have it)? bbsh is under development still, by rob landley. unless he's made a lot of progress recently, it's probably far from being ready to build your jvm. the most complete shell in busybox is "ash", which you're probably already using. depending on the needs of your build, you may be able to tweak the build scripts enough so that they work with ash. and finally, of course, you could try building bash for your target, and using it directly. paul =--------------------- paul fox, pgf at brightstareng.com From wharms at bfs.de Tue Nov 7 00:52:07 2006 From: wharms at bfs.de (walter harms) Date: Tue, 07 Nov 2006 09:52:07 +0100 Subject: BASH issue In-Reply-To: <953603a60611061427s1c872959vf0ae3ade50814452@mail.gmail.com> References: <953603a60611061427s1c872959vf0ae3ade50814452@mail.gmail.com> Message-ID: <45504937.6060406@bfs.de> hi carmen, there are some restriction using 'ash' most noteworthy missing support for arrays , (( (arithmetics) and [[ (extented testing). most scripts can easly be rewritten. simply let it run until it breaks. re, wh Carmen Badea wrote: > Hi everyone, > > So I am trying to build a JVM on a PPC 405EP board using BusyBox v 1.2.1 . > The config files for this JVM use bash and from what I have seen on search > results , BusyBox does not have Bash.However, I read somewhere that > there is > a shell called BBSH that would be a smaller version of BASH. Is that true > and if so, what features is BBSH missing and how could I get it (my current > version of BusyBox does not have it)? > > thank you for your help. > -- > Carmen > > > ------------------------------------------------------------------------ > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox From hinko.kocevar at cetrtapot.si Tue Nov 7 01:09:05 2006 From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si) Date: Tue, 07 Nov 2006 10:09:05 +0100 Subject: Chargen patch In-Reply-To: <20061106151551.GA18654@aon.at> References: <454F3B32.6040703@cetrtapot.si> <14182.1162824605@brightstareng.com> <20061106151551.GA18654@aon.at> Message-ID: <45504D31.6070402@cetrtapot.si> Bernhard Fischer wrote: > On Mon, Nov 06, 2006 at 09:50:05AM -0500, Paul Fox wrote: >>> + while (nr--) >>> + { >>> + bb_printf ("%c", ch); >>> + } >> >> uh, no. i don't think so. > > ditto for the getopt() call. Please use getopt32() instead (see > libbb/getopt32.c for docs) > > PS: can't you do something like printf "\xff" | dd instead ? Guess I could, but I still need to iterate, right? This would make it too slow on my small embedded system. best regards, hinko -- ?ETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hinko.kocevar at cetrtapot.si Http: www.cetrtapot.si From hinko.kocevar at cetrtapot.si Tue Nov 7 01:09:36 2006 From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si) Date: Tue, 07 Nov 2006 10:09:36 +0100 Subject: Chargen patch In-Reply-To: <20061106193552.GD32594@brightrain.aerifal.cx> References: <454F3B32.6040703@cetrtapot.si> <20061106193552.GD32594@brightrain.aerifal.cx> Message-ID: <45504D50.2060401@cetrtapot.si> Rich Felker wrote: > On Mon, Nov 06, 2006 at 02:40:02PM +0100, hinko.kocevar at cetrtapot.si wrote: >> Hello, >> >> I've been looking for a utility like this for some time and I finally >> decided to code the solution by myself. >> I've needed a way to generate files with same contents (eg. 16k file >> with 0xFF). > > head dd bs=16384 count=1 < /dev/zero | tr '\0' '\377' > YES. I like this one... Its fast even on my embedded system and does what I needed! Thanks, hinko -- ?ETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hinko.kocevar at cetrtapot.si Http: www.cetrtapot.si From hinko.kocevar at cetrtapot.si Tue Nov 7 01:11:41 2006 From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si) Date: Tue, 07 Nov 2006 10:11:41 +0100 Subject: Chargen patch In-Reply-To: <14182.1162824605@brightstareng.com> References: <14182.1162824605@brightstareng.com> Message-ID: <45504DCD.1090109@cetrtapot.si> Paul Fox wrote: > > + while (nr--) > > + { > > + bb_printf ("%c", ch); > > + } > > > uh, no. i don't think so. > Out of curiosity - what is wrong with the while() loop above? Or is it the bb_printf() usage wrong? regards, hinko -- ?ETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hinko.kocevar at cetrtapot.si Http: www.cetrtapot.si From hinko.kocevar at cetrtapot.si Tue Nov 7 01:13:26 2006 From: hinko.kocevar at cetrtapot.si (hinko.kocevar at cetrtapot.si) Date: Tue, 07 Nov 2006 10:13:26 +0100 Subject: Chargen patch In-Reply-To: <454F3B32.6040703@cetrtapot.si> References: <454F3B32.6040703@cetrtapot.si> Message-ID: <45504E36.1080307@cetrtapot.si> hinko.kocevar at cetrtapot.si wrote: > Hello, > > I've been looking for a utility like this for some time and I finally > decided to code the solution by myself. > I've needed a way to generate files with same contents (eg. 16k file > with 0xFF). I'll probably go with the solution posted by Rich Felker in this thread and dump the 'chargen' applet, since the problem can be solved fast enough in the shell. thank you, hinko -- ?ETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenija Tel. +386 (0) 4 280 66 37 E-mail: hinko.kocevar at cetrtapot.si Http: www.cetrtapot.si From bet at rahul.net Tue Nov 7 06:50:18 2006 From: bet at rahul.net (Bennett Todd) Date: Tue, 7 Nov 2006 14:50:18 +0000 Subject: ash backticks busted in 1.2.2.1 In-Reply-To: <200611070253.30714.vda.linux@googlemail.com> References: <20061101182547.GX95055@og.latency.net> <20061105215215.GA2841@rahul.net> <78a54e1b0611051841y4aa04cfeyc1f653164b50d512@mail.gmail.com> <200611070253.30714.vda.linux@googlemail.com> Message-ID: <20061107145018.GA28058@rahul.net> 2006-11-07T01:53:30 Denis Vlasenko: > then please try > > #if ENABLE_STATIC && (defined(__GLIBC__) && !defined(__UCLIBC__)) > > instead, and let me know. Dropping the extra close-parens, the attached patch built in my uClibc Bent Linux w/o producing the warning message. -Bennett -------------- next part -------------- diff -ru busybox-1.2.2.1.orig/applets/applets.c busybox-1.2.2.1/applets/applets.c --- busybox-1.2.2.1.orig/applets/applets.c 2006-10-29 20:25:18.000000000 +0000 +++ busybox-1.2.2.1/applets/applets.c 2006-11-07 14:14:02.000000000 +0000 @@ -17,7 +17,7 @@ #include #include -#if ENABLE_STATIC && defined(__GLIBC__) +#if ENABLE_STATIC && defined(__GLIBC__) && !defined(__UCLIBC__) #warning Static linking against glibc produces buggy executables #warning See sources.redhat.com/bugzilla/show_bug.cgi?id=3400 #warning Note that glibc is utterly unsuitable for static linking anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061107/09bb94ee/attachment.pgp From pgf at brightstareng.com Tue Nov 7 07:41:23 2006 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 07 Nov 2006 10:41:23 -0500 Subject: Chargen patch In-Reply-To: hinko.kocevar's message of Tue, 07 Nov 2006 10:11:41 +0100. <45504DCD.1090109@cetrtapot.si> Message-ID: <23904.1162914083@brightstareng.com> > > > + while (nr--) > > > + { > > > + bb_printf ("%c", ch); > > > + } > > > > > > uh, no. i don't think so. > > > > Out of curiosity - what is wrong with the while() loop above? > Or is it the bb_printf() usage wrong? printf() is a very high level, very expensive call, intended to do complex formatting of data. your chargen app doesn't need any of its features, so why use it? you were causing your program to waste cycles. instead, you could have written: while (nr--) putchar(ch); but what's really wasteful is your while loop. it's calling a lot of code for _every_ character. you're calling printf (or, in my replacement, putchar()) over 16000 times! consider something like this, instead: unsigned char buf[1024]; memset(buf, ch, sizeof(buf)); while (nr >= sizeof(buf)) { write(1, buf, sizeof(buf)); nr -= sizeof(buf); } if (nr) write(1, buf, nr); =--------------------- paul fox, pgf at brightstareng.com From clem.taylor at gmail.com Tue Nov 7 08:54:56 2006 From: clem.taylor at gmail.com (Clem Taylor) Date: Tue, 7 Nov 2006 11:54:56 -0500 Subject: Chargen patch In-Reply-To: <20061106193552.GD32594@brightrain.aerifal.cx> References: <454F3B32.6040703@cetrtapot.si> <20061106193552.GD32594@brightrain.aerifal.cx> Message-ID: I don't know if you have awk in your busybox, but I needed to do something like this and I pad=1024 awk -v cnt=$pad 'BEGIN{for(i=0;i> filename --Clem From roberto.bielli at axelsw.it Tue Nov 7 09:41:52 2006 From: roberto.bielli at axelsw.it (Roberto Bielli) Date: Tue, 07 Nov 2006 18:41:52 +0100 Subject: italian keyboard Message-ID: <4550C560.5060306@axelsw.it> Hi, i'm evaluating the choice to build an embedded system with linux on an Industrial Controller. I have busybox 1.2.2 and i'd like to build an italian keyboard for busybox. How i can make it ? Thanks From rob at landley.net Tue Nov 7 10:28:33 2006 From: rob at landley.net (Rob Landley) Date: Tue, 7 Nov 2006 13:28:33 -0500 Subject: Security hole in httpd? Message-ID: <200611071328.33740.rob@landley.net> Somebody on IRC was a bit concerned about the security hole in httpd: http://bugs.busybox.net/view.php?id=1008 Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From dalias at aerifal.cx Tue Nov 7 14:10:45 2006 From: dalias at aerifal.cx (Rich Felker) Date: Tue, 7 Nov 2006 17:10:45 -0500 Subject: Chargen patch In-Reply-To: References: <454F3B32.6040703@cetrtapot.si> <20061106193552.GD32594@brightrain.aerifal.cx> Message-ID: <20061107221044.GC4171@brightrain.aerifal.cx> On Tue, Nov 07, 2006 at 11:54:56AM -0500, Clem Taylor wrote: > I don't know if you have awk in your busybox, but I needed to do > something like this and I > > pad=1024 > awk -v cnt=$pad 'BEGIN{for(i=0;i> filename While this works, the dd/tr solution is a LOT more efficient. Rich From dalias at aerifal.cx Tue Nov 7 14:12:20 2006 From: dalias at aerifal.cx (Rich Felker) Date: Tue, 7 Nov 2006 17:12:20 -0500 Subject: Security hole in httpd? In-Reply-To: <200611071328.33740.rob@landley.net> References: <200611071328.33740.rob@landley.net> Message-ID: <20061107221220.GD4171@brightrain.aerifal.cx> On Tue, Nov 07, 2006 at 01:28:33PM -0500, Rob Landley wrote: > Somebody on IRC was a bit concerned about the security hole in httpd: > > http://bugs.busybox.net/view.php?id=1008 While this is a stupid vuln that should never have been introduced to begin with, the severity is..... well if you have passwords stored in a world-readable file and expect any degree of security you're fooling yourself. :) Rich From rob at landley.net Tue Nov 7 13:48:09 2006 From: rob at landley.net (Rob Landley) Date: Tue, 7 Nov 2006 16:48:09 -0500 Subject: Custom initrd using busybox In-Reply-To: References: <20061106002007.GC24095@nsk.no-ip.org> Message-ID: <200611071648.09849.rob@landley.net> On Monday 06 November 2006 3:07 pm, Moot Account wrote: > Please pardon a newbie. My question is: what's the _difference_ > between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz The difference is that this is the BusyBox mailing list, and the buildroot mailing list is buildroot at uclibc.org. Your question is about buildroot, not busybox. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Tue Nov 7 13:50:45 2006 From: rob at landley.net (Rob Landley) Date: Tue, 7 Nov 2006 16:50:45 -0500 Subject: BASH issue In-Reply-To: <20486.1162855648@brightstareng.com> References: <20486.1162855648@brightstareng.com> Message-ID: <200611071650.45499.rob@landley.net> On Monday 06 November 2006 6:27 pm, Paul Fox wrote: > > > > Hi everyone, > > > > So I am trying to build a JVM on a PPC 405EP board using BusyBox v 1.2.1 . > > The config files for this JVM use bash and from what I have seen on search > > results , BusyBox does not have Bash.However, I read somewhere that there is > > a shell called BBSH that would be a smaller version of BASH. Is that true > > and if so, what features is BBSH missing and how could I get it (my current > > version of BusyBox does not have it)? > > bbsh is under development still, by rob landley. No, it isn't. I'm doing a new shell for toybox, but I'm not working on the version in busybox anymore after Bruce took all the fun out of it. I'd recommend just removing the one in busybox; it's fairly useless and I'm not adding to it. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Tue Nov 7 13:54:06 2006 From: rob at landley.net (Rob Landley) Date: Tue, 7 Nov 2006 16:54:06 -0500 Subject: Chargen patch In-Reply-To: <23904.1162914083@brightstareng.com> References: <23904.1162914083@brightstareng.com> Message-ID: <200611071654.06379.rob@landley.net> On Tuesday 07 November 2006 10:41 am, Paul Fox wrote: > unsigned char buf[1024]; > > memset(buf, ch, sizeof(buf)); > > while (nr >= sizeof(buf)) { > write(1, buf, sizeof(buf)); Not that it matters, but I think you want some variant of full_write() out of libbb. (Or perhaps xwrite(), if there is one.) Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From rob at landley.net Tue Nov 7 13:57:03 2006 From: rob at landley.net (Rob Landley) Date: Tue, 7 Nov 2006 16:57:03 -0500 Subject: italian keyboard In-Reply-To: <4550C560.5060306@axelsw.it> References: <4550C560.5060306@axelsw.it> Message-ID: <200611071657.03764.rob@landley.net> On Tuesday 07 November 2006 12:41 pm, Roberto Bielli wrote: > Hi, > > i'm evaluating the choice to build an embedded system with linux on an > Industrial Controller. > I have busybox 1.2.2 and i'd like to build an italian keyboard for busybox. Keyboard's controlled either by your kernel or x11, not by busybox. We do load keyboard info into the kernel after boot (look at the "setkeycodes" applet, I think) but I've never played with it. Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From ldoolitt at recycle.lbl.gov Tue Nov 7 14:04:21 2006 From: ldoolitt at recycle.lbl.gov (ldoolitt at recycle.lbl.gov) Date: Tue, 7 Nov 2006 14:04:21 -0800 Subject: Security hole in httpd? In-Reply-To: <20061107221220.GD4171@brightrain.aerifal.cx> References: <200611071328.33740.rob@landley.net> <20061107221220.GD4171@brightrain.aerifal.cx> Message-ID: <20061107220421.GA2935@recycle.lbl.gov> On Tue, Nov 07, 2006 at 05:12:20PM -0500, Rich Felker wrote: > On Tue, Nov 07, 2006 at 01:28:33PM -0500, Rob Landley wrote: > > Somebody on IRC was a bit concerned about the security hole in httpd: > > http://bugs.busybox.net/view.php?id=1008 > > While this is a stupid vuln that should never have been introduced to > begin with, the severity is..... well if you have passwords stored in > a world-readable file and expect any degree of security you're fooling > yourself. :) My take on this subject, dating from over seven years ago: http://archive.cert.uni-stuttgart.de/archive/bugtraq/1999/04/msg00121.html - Larry From pgf at brightstareng.com Tue Nov 7 14:06:26 2006 From: pgf at brightstareng.com (Paul Fox) Date: Tue, 07 Nov 2006 17:06:26 -0500 Subject: Chargen patch In-Reply-To: rob's message of Tue, 07 Nov 2006 16:54:06 -0500. <200611071654.06379.rob@landley.net> Message-ID: <9360.1162937186@brightstareng.com> > On Tuesday 07 November 2006 10:41 am, Paul Fox wrote: > > unsigned char buf[1024]; > > > > memset(buf, ch, sizeof(buf)); > > > > while (nr >= sizeof(buf)) { > > write(1, buf, sizeof(buf)); > > Not that it matters, but I think you want some variant of full_write() out of > libbb. (Or perhaps xwrite(), if there is one.) this was written in the spirit of an untested programming tutorial, not as code that should be commited to the tree. paul =--------------------- paul fox, pgf at brightstareng.com From vda.linux at googlemail.com Mon Nov 6 17:53:30 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Tue, 7 Nov 2006 02:53:30 +0100 Subject: ash backticks busted in 1.2.2.1 In-Reply-To: <78a54e1b0611051841y4aa04cfeyc1f653164b50d512@mail.gmail.com> References: <20061101182547.GX95055@og.latency.net> <20061105215215.GA2841@rahul.net> <78a54e1b0611051841y4aa04cfeyc1f653164b50d512@mail.gmail.com> Message-ID: <200611070253.30714.vda.linux@googlemail.com> On Monday 06 November 2006 03:41, Jason Schoon wrote: > On 11/5/06, Bennett Todd wrote: > > > > 2006-11-01T22:33:36 Bennett Todd: > > > I'll try rebuilding 1.2.2.1 on my home uclibc-based distro (in > > > a few days, I'm afraid), and will send another note if I can > > > reproduce the problem there, otherwise we'll happily blame it on > > > glibc. > > > > Just recompiled, noticed something odd. It printed: > > > > LINK busybox_unstripped > > /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:21:2: > > warning: #warning Static linking against glibc produces buggy executables > > /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:22:2: > > warning: #warning See sources.redhat.com/bugzilla/show_bug.cgi?id=3400 > > /var/tmp/bpmbuild.28871/build/busybox-1.2.2.1/applets/applets.c:23:2: > > warning: #warning Note that glibc is utterly unsuitable for static linking > > anyway. > > > > This despite the fact that the chroot jail where I built it has no > > glibc. > > > Agreed, I don't believe the check for toolchain is being done correctly. I > get this warning when I cross-compile using my uclibc toolchain to do a > static build as well. The check is just: #if ENABLE_STATIC && defined(__GLIBC__) So, does uclibc define __GLIBC__ (it well might be forced to, due to some bug-for-bug compatibility needs)? If it is so, then please try #if ENABLE_STATIC && (defined(__GLIBC__) && !defined(__UCLIBC__)) instead, and let me know. -- vda From Michele.Sanges at otomelara.it Wed Nov 8 01:04:49 2006 From: Michele.Sanges at otomelara.it (Sanges Michele) Date: Wed, 8 Nov 2006 10:04:49 +0100 Subject: R: italian keyboard Message-ID: > -----Messaggio originale----- > Da: busybox-bounces at busybox.net > [mailto:busybox-bounces at busybox.net]Per > conto di Roberto Bielli > Inviato: marted? 7 novembre 2006 18.42 > A: busybox at busybox.net > Oggetto: italian keyboard > > > Hi, > > i'm evaluating the choice to build an embedded system with > linux on an > Industrial Controller. > I have busybox 1.2.2 and i'd like to build an italian > keyboard for busybox. > > How i can make it ? > > Thanks > > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > Hi Roberto, - make a binary file correspondent to you keyboard, by means the dumpkmap utility: dumpkmap > kmap_it.bin - load the keyboard map in your init script: loadkmap < kmap_it.bin Best regards. Ing. Michele Sanges Sviluppo Software Servizi Progettazione Elettronica OTO Melara S.p.A. Via Valdilocchi, 15 19136 LA SPEZIA Tel: +39 0187 582683 From vda.linux at googlemail.com Wed Nov 8 16:03:10 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Thu, 9 Nov 2006 01:03:10 +0100 Subject: ash backticks busted in 1.2.2.1 In-Reply-To: <20061107145018.GA28058@rahul.net> References: <20061101182547.GX95055@og.latency.net> <200611070253.30714.vda.linux@googlemail.com> <20061107145018.GA28058@rahul.net> Message-ID: <200611090103.10567.vda.linux@googlemail.com> On Tuesday 07 November 2006 15:50, Bennett Todd wrote: > 2006-11-07T01:53:30 Denis Vlasenko: > > then please try > > > > #if ENABLE_STATIC && (defined(__GLIBC__) && !defined(__UCLIBC__)) > > > > instead, and let me know. > > Dropping the extra close-parens, the attached patch built in my > uClibc Bent Linux w/o producing the warning message. Applied, thanks -- vda From vda.linux at googlemail.com Wed Nov 8 16:05:40 2006 From: vda.linux at googlemail.com (Denis Vlasenko) Date: Thu, 9 Nov 2006 01:05:40 +0100 Subject: Security hole in httpd? In-Reply-To: <200611071328.33740.rob@landley.net> References: <200611071328.33740.rob@landley.net> Message-ID: <200611090105.40188.vda.linux@googlemail.com> On Tuesday 07 November 2006 19:28, Rob Landley wrote: > Somebody on IRC was a bit concerned about the security hole in httpd: > > http://bugs.busybox.net/view.php?id=1008 > > Rob Was a bit busy this week. Will take a look tomorrow. Honest. 01:04 here, start working tomorrow (today?) at 07:00. Never hesitate to remind me, though! :) -- vda From KokHow.Teh at infineon.com Wed Nov 8 23:58:48 2006 From: KokHow.Teh at infineon.com (KokHow.Teh at infineon.com) Date: Thu, 9 Nov 2006 15:58:48 +0800 Subject: Busybox-1.2.2.1: No rule to make target ... Blkid error Message-ID: <5049F8BE55F36348A315EFBE6CF343868AB964@sinse301.ap.infineon.com> Hi; I just downloaded busybox-1.2.2.1 and encounter this error when building the source: make[1]: *** No rule to make target `|/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid', needed by `/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid/blkid_getsize.o'. Stop. make: *** [_all] Error 2 [tehkok at linux01 busybox-1.2.2.1 44]$ Any insight is appreciated. Thanks. Regards, KH From rep.nop at aon.at Thu Nov 9 01:48:00 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu, 9 Nov 2006 10:48:00 +0100 Subject: svn commit: trunk/busybox/applets In-Reply-To: <20061109000013.646A84858F@busybox.net> References: <20061109000013.646A84858F@busybox.net> Message-ID: <20061109094800.GB28949@aon.at> On Wed, Nov 08, 2006 at 04:00:13PM -0800, vda at busybox.net wrote: >Author: vda >Date: 2006-11-08 16:00:12 -0800 (Wed, 08 Nov 2006) >--- trunk/busybox/applets/applets.c 2006-11-07 20:50:21 UTC (rev 16521) >+++ trunk/busybox/applets/applets.c 2006-11-09 00:00:12 UTC (rev 16522) >@@ -17,7 +17,8 @@ > #include > #include > >-#if ENABLE_STATIC && defined(__GLIBC__) >+/* Apparently uclibc defines __GLIBC__ (compat trick?). Oh well. */ >+#if ENABLE_STATIC && defined(__GLIBC__) && !defined(__UCLIBC__) > #warning Static linking against glibc produces buggy executables To make that valid C, please do -> #warning (glibc doesn't cope well with ld --gc-sections). +> #warning (glibc does not cope well with ld --gc-sections). > #warning See sources.redhat.com/bugzilla/show_bug.cgi?id=3400 thanks, From rep.nop at aon.at Thu Nov 9 01:55:22 2006 From: rep.nop at aon.at (Bernhard Fischer) Date: Thu, 9 Nov 2006 10:55:22 +0100 Subject: Busybox-1.2.2.1: No rule to make target ... Blkid error In-Reply-To: <5049F8BE55F36348A315EFBE6CF343868AB964@sinse301.ap.infineon.com> References: <5049F8BE55F36348A315EFBE6CF343868AB964@sinse301.ap.infineon.com> Message-ID: <20061109095522.GA29635@aon.at> On Thu, Nov 09, 2006 at 03:58:48PM +0800, KokHow.Teh at infineon.com wrote: >Hi; > I just downloaded busybox-1.2.2.1 and encounter this error when >building the source: Your version of make may be too old. You need 3.8x or later, IIRC. Please confirm, thanks > > >make[1]: *** No rule to make target >`|/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid', needed by >`/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid/blkid_getsize.o'. Stop. >make: *** [_all] Error 2 >[tehkok at linux01 busybox-1.2.2.1 44]$ > > Any insight is appreciated. Thanks. From rob at landley.net Thu Nov 9 10:54:42 2006 From: rob at landley.net (Rob Landley) Date: Thu, 9 Nov 2006 13:54:42 -0500 Subject: Busybox-1.2.2.1: No rule to make target ... Blkid error In-Reply-To: <5049F8BE55F36348A315EFBE6CF343868AB964@sinse301.ap.infineon.com> References: <5049F8BE55F36348A315EFBE6CF343868AB964@sinse301.ap.infineon.com> Message-ID: <200611091354.43153.rob@landley.net> On Thursday 09 November 2006 2:58 am, KokHow.Teh at infineon.com wrote: > Hi; > I just downloaded busybox-1.2.2.1 and encounter this error when > building the source: > > > make[1]: *** No rule to make target > `|/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid', needed by > `/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid/blkid_getsize.o'. Stop. > make: *** [_all] Error 2 > [tehkok at linux01 busybox-1.2.2.1 44]$ When it was added to BusyBox, the people who wrote the makefiles didn't care about backwards compatability. It won't build on Linux versions older than about 3 years. I kept meaning to do something about it (the whole of the e2fsprogs directory is crap and needs a complete rewrite, actually), but I'm not good with makefiles... Rob -- "Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away." - Antoine de Saint-Exupery From carmen.badea at gmail.com Thu Nov 9 13:34:21 2006 From: carmen.badea at gmail.com (Carmen Badea) Date: Thu, 9 Nov 2006 13:34:21 -0800 Subject: BASH issue Message-ID: <953603a60611091334m427849e4rac04557b0fccd6ce@mail.gmail.com> Hello everyone, Thanks for your replies. So now I have this CD of development tools that are supposed to work with my board and BASH is among them. I have tried to install it using the rpm command in the BusyBox v1.2.1 and this is what I get: /home/carmen # ./busybox rpm -i bash-ppc_4xx-3.0-31_1.ppc.rpm rpm: Cannot create symlink from ./bin/sh to 'bash': File exists 10206 blocks rpm: unknown group name: root After this I checked the /bin directory and now there is a file called "bash" in the directory, which when I try to run it, gives me this error: /bin # bash bash: error while loading shared libraries: libtermcap.so.2: cannot open shared object file: No such file or directory Any ideas as to why this is happening and how I could fix it? I apologize if I am asking some obvious questions.I am no Linux expert... thank you, Carmen ---------- Forwarded message ---------- From: Rob Landley To: busybox at busybox.net Date: Tue, 7 Nov 2006 16:50:45 -0500 Subject: Re: BASH issue On Monday 06 November 2006 6:27 pm, Paul Fox wrote: > > > > Hi everyone, > > > > So I am trying to build a JVM on a PPC 405EP board using BusyBox v 1.2.1 . > > The config files for this JVM use bash and from what I have seen on search > > results , BusyBox does not have Bash.However, I read somewhere that there is > > a shell called BBSH that would be a smaller version of BASH. Is that true > > and if so, what features is BBSH missing and how could I get it (my current > > version of BusyBox does not have it)? > > bbsh is under development still, by rob landley. No, it isn't. I'm doing a new shell for toybox, but I'm not working on the version in busybox anymore after Bruce took all the fun out of it. I'd recommend just removing the one in busybox; it's fairly useless and I'm not adding to it. Rob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061109/1964610d/attachment.html From strange at nsk.no-ip.org Thu Nov 9 14:25:59 2006 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 9 Nov 2006 22:25:59 +0000 Subject: BASH issue In-Reply-To: <953603a60611091334m427849e4rac04557b0fccd6ce@mail.gmail.com> References: <953603a60611091334m427849e4rac04557b0fccd6ce@mail.gmail.com> Message-ID: <20061109222559.GC11526@nsk.no-ip.org> On Thu, Nov 09, 2006 at 01:34:21PM -0800, Carmen Badea wrote: > /bin # bash > bash: error while loading shared libraries: libtermcap.so.2: cannot open > shared object file: No such file or directory The error is self-explanatory. You're missing libtermcap.so.2 (a library). There should be another rpm named libtermcap-*. AFAIK, busybox's rpm doesn't check for dependencies when installing rpms, so you'll have to manually check them. -- lfr 0/0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://busybox.net/lists/busybox/attachments/20061109/874572cd/attachment.pgp From KokHow.Teh at infineon.com Sun Nov 12 17:25:47 2006 From: KokHow.Teh at infineon.com (KokHow.Teh at infineon.com) Date: Mon, 13 Nov 2006 09:25:47 +0800 Subject: Busybox-1.2.2.1: No rule to make target ... Blkid error In-Reply-To: <20061109095522.GA29635@aon.at> Message-ID: <5049F8BE55F36348A315EFBE6CF34386915281@sinse301.ap.infineon.com> Hi; On Thu, Nov 09, 2006 at 03:58:48PM +0800, KokHow.Teh at infineon.com wrote: >>Hi; >> I just downloaded busybox-1.2.2.1 and encounter this error when >>building the source: >Your version of make may be too old. You need 3.8x or later, IIRC. >Please confirm, >thanks My `make` version is 3.79.1. I take out all e2fsprogs applets and busybox-1.2.2.1 builds without an error. Upgrading `make` and its dependencies is a non-trivial job especially when I am using RedHat 9.0 which is more than 3 years old. This should be easier with Debian system since the package manager automatically checks, downloads, upgrades and updates the dependencies for you.... Thanks. >> >> >>make[1]: *** No rule to make target >>`|/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid', needed by >>`/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid/blkid_getsize.o'. Stop. >>make: *** [_all] Error 2 >>[tehkok at linux01 busybox-1.2.2.1 44]$ >> >> Any insight is appreciated. Thanks. From wharms at bfs.de Wed Nov 15 03:06:25 2006 From: wharms at bfs.de (walter harms) Date: Wed, 15 Nov 2006 12:06:25 +0100 Subject: Busybox-1.2.2.1: No rule to make target ... Blkid error In-Reply-To: <5049F8BE55F36348A315EFBE6CF34386915281@sinse301.ap.infineon.com> References: <5049F8BE55F36348A315EFBE6CF34386915281@sinse301.ap.infineon.com> Message-ID: <455AF4B1.2010103@bfs.de> Upgrading make is simple. - you grab a copy of the source - configure/make/ (copy the original make) / make install - ready I doubt that you will find a RPM for on old RH re, wh KokHow.Teh at infineon.com wrote: > Hi; > > On Thu, Nov 09, 2006 at 03:58:48PM +0800, KokHow.Teh at infineon.com wrote: >>> Hi; >>> I just downloaded busybox-1.2.2.1 and encounter this error when >>> building the source: > >> Your version of make may be too old. You need 3.8x or later, IIRC. >> Please confirm, >> thanks > > My `make` version is 3.79.1. I take out all e2fsprogs applets and > busybox-1.2.2.1 builds without an error. > Upgrading `make` and its dependencies is a non-trivial job especially > when I am using RedHat 9.0 which is more than 3 years old. This should > be easier with Debian system since the package manager automatically > checks, downloads, upgrades and updates the dependencies for you.... > > Thanks. > >>> >>> make[1]: *** No rule to make target >>> `|/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid', needed by >>> `/misc/tehkok/busybox-1.2.2.1/e2fsprogs/blkid/blkid_getsize.o'. Stop. >>> make: *** [_all] Error 2 >>> [tehkok at linux01 busybox-1.2.2.1 44]$ >>> >>> Any insight is appreciated. Thanks. > _______________________________________________ > busybox mailing list > busybox at busybox.net > http://busybox.net/cgi-bin/mailman/listinfo/busybox > > > From yh at bizmail.com.au Wed Nov 15 02:51:58 2006 From: yh at bizmail.com.au (yh at bizmail.com.au) Date: Wed, 15 Nov 2006 21:51:58 +1100 Subject: tar: Invalid tar magic Message-ID: <455AF14E.8010103@bizmail.com.au> Hi, I downloaded a gzip file from a window machine to an ARM system which running busybox. Then I've got following error after running tar -zxf config.tar.gz on ARM system. I've also tried to run the same file "tar -zxf config.tar.gz" on my linux box (FC5), there was no error at all. Could anyone explain what was wrong with the busybox command? tar: Invalid tar magic Thank you. Jim From erik at hovland.org Wed Nov 15 07:13:50 2006 From: erik at hovland.org (Erik Hovland) Date: Wed, 15 Nov 2006 07:13:50 -0800 Subject: tar: Invalid tar magic In-Reply-To: <455AF14E.8010103@bizmail.com.au> References: <455AF14E.8010103@bizmail.com.au> Message-ID: <20061115151350.GC19302@hovland.org> On Wed, Nov 15, 2006 at 09:51:58PM +1100, yh at bizmail.com.au wrote: > Hi, > > I downloaded a gzip file from a window machine to an ARM system which > running busybox. Then I've got following error after running tar -zxf > config.tar.gz on ARM system. I've also tried to run the same file "tar > -zxf config.tar.gz" on my linux box (FC5), there was no error at all. > Could anyone explain what was wrong with the busybox command? > > tar: Invalid tar magic It means that tar looked into the tar header of the tar file for a 4 byte entry that is the 'magic'. It should say something like 'utar'. I am not exactly sure about that - look in the tar.c file in busybox's source tree. Since it isn't right, it tanks. You could probably fix the problem by unzipping the file and then using an editor that can work in binary (emacs, vi, etc.) and editing the header so it has the right bytes in the magic. At least if it isn't busybox's fault. If it is busybox's fault, well, um, I don't know what to do. E -- Erik Hovland mail: erik at hovland.org web: http://hovland.org/ PGP/GPG public key available on request From tmike at recipes4linux.com Wed Nov 15 09:22:19 2006 From: tmike at recipes4linux.com (T Michael Turney) Date: Wed, 15 Nov 2006 09:22:19 -0800 Subject: syslogd running on cramfs root Message-ID: Hi folks, My apologies if this is in the archives, I looked and didn't find a hit. Problem: We have an embedded system with a relatively small root filesystem (cramfs), the bulk of which are busybox commands. We want to start using syslogd, which seems to want to use /dev/log as the socket to communicate with. /dev is on cramfs, so it is read-only. If we make the root filesystem with /dev/log already created as a socket, syslogd errors out with the "Address in use" errno. The only solution we have come up with is to modify _PATH_LOG and point it to /tmp/log or something like this. We are wondering how other folks with a cramfs root filesystem have solved this problem. Cheers, T.mike From floydpink at gmail.com Wed Nov 15 10:38:09 2006 From: floydpink at gmail.com (Jason Schoon) Date: Wed, 15 Nov 2006 12:38:09 -0600 Subject: syslogd running on cramfs root In-Reply-To: References: Message-ID: <78a54e1b0611151038u499c136atbd1095d9008abe4@mail.gmail.com> On 11/15/06, T Michael Turney wrote: > > > Hi folks, > My apologies if this is in the archives, I looked and > didn't find a hit. > > Problem: > We have an embedded system with a relatively small > root filesystem (cramfs), the bulk of which are busybox commands. > > We want to start using syslogd, which seems to want to > use /dev/log as the socket to communicate with. > > /dev is on cramfs, so it is read-only. > > If we make the root filesystem with /dev/log already > created as a socket, syslogd errors out with the > "Address in use" errno. > > The only solution we have come up with is to modify _PATH_LOG > and point it to /tmp/log or something like this. > > We are wondering how other folks with a cramfs root filesystem > have solved this problem. > Cheers, > T.mike > Create a symlink of /dev/log to something like /tmp/.log out in a ram filesystem? That's what we have done in the past. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://busybox.net/lists/busybox/attachments/20061115/676a5692/a