headers
Denis Vlasenko | 1 Nov 2006 01:04

Re: Where did "make help" go?

On Tuesday 31 October 2006 19:15, Rob Landley wrote:
> make -C /home/landley/busybox/tesht/busybox O=/home/landley/busybox/tesht/woot 
> help
> make[2]: *** No rule to make target `help'.  Stop.
> make[1]: *** [help] Error 2
> make: *** [help] Error 2
> 
> Rob

Fixed. Sorry.

diff -urpN busybox.2/Makefile busybox.3/Makefile
--- busybox.2/Makefile  2006-10-27 11:05:29.000000000 +0200
+++ busybox.3/Makefile  2006-11-01 01:02:38.000000000 +0100
 <at>  <at>  -988,7 +988,7  <at>  <at>  rpm: FORCE
 boards := $(wildcard $(srctree)/arch/$(ARCH)/configs/*_defconfig)
 boards := $(notdir $(boards))

--include Makefile.help
+-include $(srctree)/Makefile.help

 # Documentation targets
 # ---------------------------------------------------------------------------
 <at>  <at>  -1282,7 +1282,7  <at>  <at>  endif     # skip-makefile
 PHONY += FORCE
 FORCE:

--include Makefile.custom
+-include $(srctree)/Makefile.custom
(Continue reading)

Permalink | Reply | 0 comments |
headers
Denis Vlasenko | 1 Nov 2006 01:11

Re: [PATCH] - allow specification of alternate inittab files

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 = 0; envp_init[i]; i++) {
                        if (i == MAX_INIT_ENVS) {
                                panic_later = "Too many boot env vars at `%s'";
(Continue reading)

Permalink | Reply | 6 comments |
headers
Rob Landley | 1 Nov 2006 01:04

Re: building busybox with a different uclibc to the toolchain version

On Tuesday 31 October 2006 5:28 pm, David Daney wrote:

> > 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?
> > 
> 
> Signal 11 is SIGSEGV.  That it is happening in init is unfortunate as 
> that makes it rather difficult to debug.

http://busybox.net/FAQ.html#init

In this case, you can also try a different busybox applet instead of 
init.  "echo" would be a good one if you just want to see if you're getting 
an expected result.  Then I'd try ls, or a command shell.

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
Permalink | Reply | 0 comments |
headers
Stuart Hughes | 1 Nov 2006 11:00
Favicon

Re: building busybox with a different uclibc to the toolchain version

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:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bernhard Fischer | 1 Nov 2006 12:49
Picon

Re: svn commit: trunk/busybox: libbb shell

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)
> <at>  <at>  -2,19 +2,19  <at>  <at> 
> #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);
(Continue reading)

Permalink | Reply | 3 comments |
headers
B Thomas | 1 Nov 2006 16:08
Picon

Re: [PATCH] - allow specification of alternate inittab files

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 <bjthomas3 <at> gmail.com> 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 <vda.linux <at> googlemail.com > 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 = 0; envp_init[i]; i++) {
                        if (i == MAX_INIT_ENVS) {
                                panic_later = "Too many boot env vars at `%s'";
                                panic_param = param;
                        }
                        if (!strncmp(param, envp_init[i], val - param))
                                break;
                }
....

So you do not need to parse /proc/commandline
--
vda


Attachment (bbinit.patch): text/x-patch, 892 bytes
_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Permalink | Reply | 4 comments |
headers
Jason Schoon | 1 Nov 2006 16:19
Picon

Re: [PATCH] - allow specification of alternate inittab files

On 11/1/06, B Thomas <bjthomas3 <at> gmail.com> 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.
_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Permalink | Reply | 3 comments |
headers
Stuart Hughes | 1 Nov 2006 16:58
Favicon

Re: building busybox with a different uclibc to the toolchain version

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
Permalink | Reply | 0 comments |
headers
Rob Landley | 1 Nov 2006 17:15

Re: building busybox with a different uclibc to the toolchain version

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
Permalink | Reply | 0 comments |
headers
B Thomas | 1 Nov 2006 17:35
Picon

Re: [PATCH] - allow specification of alternate inittab files

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 <floydpink <at> gmail.com> wrote:
On 11/1/06, B Thomas <bjthomas3 <at> gmail.com> 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.

_______________________________________________
busybox mailing list
busybox <at> busybox.net
http://busybox.net/cgi-bin/mailman/listinfo/busybox
Permalink | Reply | 2 comments |

Gmane