telinit in current snapshot
I am attempting to cross-compile an SH4 version of the current snapshot for a satellite set top box. All other tools work fine, but attempts to restart init from a telnet session (ie init 4: sleep 8: enigma2 ) fail with a 'init must be PID1' message. I do have a 'ln -sf /bin/busybox /bin/telinit' link, but issuing a telinit command returns 'applet not found' The command works fine on version 18.5 on my mipsel boxes so presumably I've got a wrong setting in make menuconfig. Please advise. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Hi Tito ! Had to modify the script a little Doesn't matter. The gawk check was just for comparison. # use prefered applet feature awk awk -f w.awk w.txt This is the one still failing on my side :-( Did you use my configuration to compile your Busybox binary? Which gcc and glibc versions? Nearly same configuration worked for month (not to say years). After some updates gcc, glibc, etc. I stumbled on this trouble I've not seen before. So what has gone wrong? How to fix? My problem: It is on a Notebook. Not installed/designed for development purposes. So I do have only limited capabilities. So again, how to fix this trouble? Thx for help Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Am 11.08.2012 11:23, schrieb Harald Becker: Hi Tito ! Had to modify the script a little Doesn't matter. The gawk check was just for comparison. # use prefered applet feature awk awk -f w.awk w.txt This is the one still failing on my side :-( Did you use my configuration to compile your Busybox binary? Which gcc and glibc versions? Nearly same configuration worked for month (not to say years). After some updates gcc, glibc, etc. I stumbled on this trouble I've not seen before. So what has gone wrong? How to fix? My problem: It is on a Notebook. Not installed/designed for development purposes. So I do have only limited capabilities. So again, how to fix this trouble? Thx for help Harald perhaps you can create a busybox with awk only ? If that still causes a problem try to remove all options via menu_config just to narrow the search. There is a good chance that you can nail the option. re, wh ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Hi Walter ! perhaps you can create a busybox with awk only ? That wont't help. If Busybox awk is called direct or via symlink it works correct. The problem arrise with the standalone/preferred applet feature. Which I really want to work, as Busybox sit on a System with most GNU utilities installed. I can't add symlinks to Busybox for every applet as this would overwrite the installed utilities. Despite those installed utilities I like to use Busybox for shell scripts. Those scripts shall use the Busybox applets, not the installed GNU utilities. This all worked before but suddenly (after some updates) stopped to work with the given glibc detected failure. If that still causes a problem try to remove all options via menu_config just to narrow the search. There is a good chance that you can nail the option. The options in question are those two. Shell standalone feature and the exec prefer applet feature. Disabling those result in using the installed GNU utility from within the scripts, which usually works fine. But that's not what I want. So nailing the Busybox option doesn't solve the problem. I nailed it already to this special Busybox feature, before asking for help. ... and it is not only awk. Other applet fail the same way, if called as applet from Busybox ash scripts. Detected this after writing the first message, but added note on repost. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
On 11.08.2012 14:03, Harald Becker wrote: Hi Walter ! perhaps you can create a busybox with awk only ? That wont't help. If Busybox awk is called direct or via symlink it works correct. The problem arrise with the standalone/preferred applet feature. Which I really want to work, as Busybox sit on a System with most GNU utilities installed. I can't add symlinks to Busybox for every applet as this would overwrite the installed utilities. Despite those installed utilities I like to use Busybox for shell scripts. Those scripts shall use the Busybox applets, not the installed GNU utilities. PATH=/busybox:$PATH ./busybox.shell.script where /busybox contains (sym)links for all busybox applets. Just a data point, not anything to add about the bug in question. /mjt ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Hi Michael ! PATH=/busybox:$PATH ./busybox.shell.script where /busybox contains (sym)links for all busybox applets. Sure, it is possible to create a directory with all the symlinks to Busybox ... but that's definitely not what I want. I used this prefer applet feature for a long time within my scripts and just want it back working. I'm not looking for a hack to avoid the problem. In addition: I have 12 different chroot environments on my disk with all different setups. Adding a directory means adding directory to each setup. Much work. Not so kind this hack. The prefer applet feature allows me to install just a Busybox binary in every setup and all scripts link directly to Busybox sh. Within those scripts the applets in the Busybox binary shall be used. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Am 11.08.2012 12:36, schrieb Harald Becker: Hi Michael ! PATH=/busybox:$PATH ./busybox.shell.script where /busybox contains (sym)links for all busybox applets. Sure, it is possible to create a directory with all the symlinks to Busybox ... but that's definitely not what I want. I used this prefer applet feature for a long time within my scripts and just want it back working. I'm not looking for a hack to avoid the problem. In addition: I have 12 different chroot environments on my disk with all different setups. Adding a directory means adding directory to each setup. Much work. Not so kind this hack. The prefer applet feature allows me to install just a Busybox binary in every setup and all scripts link directly to Busybox sh. Within those scripts the applets in the Busybox binary shall be used. I have no idea about your environment, but i had a similar problem some time ago and found mount --bind handy. re, wh ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Hi Tito ! GNU C Library (Debian EGLIBC 2.11.3-3) stable release version 2.11.3, Compiled by GNU CC version 4.4.5. Compiled on a Linux 2.6.32 system on 2012-02-13. ./busybox BusyBox v1.21.0.git (2012-08-10 21:15:09 CEST) multi-call binary. BusyBox is copyrighted by many authors between 1998-2012. Ok, you definitely use older versions than I. As far as I know everything was fine on my side using comparable versions. Looks to me that this preferred applet feature depends on something which changed on newer gcc/glibc/kernel. ... but as all other software on this computer is build with this gcc and linked against this version of glibc, I do not like to mix up versions for Busybox only. I'm more interested to find the reason for failure and get it fixed. Did you recompile for the updated libc (maybe it is needed)? Fresh recompile of Busybox. Several times. I even grab snapshot of same date as your binary above ... recompile ... same kind of failure only displayed addresses in error dump differ. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
On Saturday 11 August 2012 18:20:29 Harald Becker wrote: Hi Tito ! GNU C Library (Debian EGLIBC 2.11.3-3) stable release version 2.11.3, Compiled by GNU CC version 4.4.5. Compiled on a Linux 2.6.32 system on 2012-02-13. ./busybox BusyBox v1.21.0.git (2012-08-10 21:15:09 CEST) multi-call binary. BusyBox is copyrighted by many authors between 1998-2012. Ok, you definitely use older versions than I. As far as I know everything was fine on my side using comparable versions. Looks to me that this preferred applet feature depends on something which changed on newer gcc/glibc/kernel. ... but as all other software on this computer is build with this gcc and linked against this version of glibc, I do not like to mix up versions for Busybox only. I'm more interested to find the reason for failure and get it fixed. Did you recompile for the updated libc (maybe it is needed)? Fresh recompile of Busybox. Several times. I even grab snapshot of same date as your binary above ... recompile ... same kind of failure only displayed addresses in error dump differ. Hi I think some strace or gdb or valgrind is needed to see what this memory refers to. Ciao, Tito -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Hi Walter ! I have no idea about your environment, but i had a similar problem some time ago and found mount --bind handy. My current system was the first approach to this vserver like installation. Over the time it summed up of over 100 active mount --bind ... and I'm planing to reorganize and reduce this amount of sometimes confusing binds ... the reason why I started to reorganize and streamline all controlling scripts ... that's why I stumbled about the current trouble with the preferred applet feature. ... but my actual question is not to file system structure and mounting. The problem is, a Busybox feature which worked for a long period of time started to fail in an unexpected manner. So there has to be something which changed. Usually anything within gcc, glibc or new kernel triggers this failure. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: Busybox awk throws glibc failure if using standalone/preferred applet feature
Hi All ! I think some strace or gdb or valgrind is needed to see what this memory refers to. As this machine is not installed for development those debugging aids are not available ... but I fiddled a bit and got strace running ... ... first result: Running the script via strace did not trigger the error and gives correct result! ... second result: Running the script as user root does not trigger the error and gives correct result! Digging into libbb/appletlib.c let to the assumption the bug depends on the suid feature of Busybox. Giving read access to /etc/busybox.conf for everybody allowed me to catch the bug with strace (w.out appended). [with simplified script, only failing awk call, all other stuff removed] Looks like the preferred applet feature triggers a permission violation for BB_SUID_DROP applets if not invoked by root (and no entry for applet in busybox.conf). Replacing xsetgid/xsetuid in appletlib.c with setresgid/setresuid changes behavior and gives Segmentation fault instead of glibc detected error. So my assumption is, we got some trouble depending on setting of uid (real, effective, saved). setuid works different if called as root or as normal user and may not set the effective/saved uid fields (as done when there is an entry in busybox.conf). Can anybody with libb knowledge look into this? -- Harald w.out Description: Binary data ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
