maemo.org - Talk - [Announce] Enhanced BusyBox package

maemo.org - Talk (https://talk.maemo.org/index.php)

- Maemo 5 / Fremantle (https://talk.maemo.org/forumdisplay.php?f=40)

- - [Announce] Enhanced BusyBox package (https://talk.maemo.org/showthread.php?t=72801)

Re: [Announce] Enhanced BusyBox package

Quote:

Originally Posted by Rob1n (Post 1128449)

On mine, the initial shell (from running X Terminal or via ssh) reports "-sh" as $0 and has TMPDIR set to /var/tmp. Running "sh" to start a new shell reports "sh" as $0 and has no TMPDIR set though.

Yeah, that is exactly what I am talking about.
I described the way to test it a little wrong.

How I tested it: my default shell is bash. From there I opened an sh shell. You guys are probably starting directly in sh.

So please all do the test again: This time: start a new shell in x-terminal (by typing sh). In the latest version of busybox TMPDIR is not set. In the previous version it is.

Sorry for not describing it accuratly in the first place...

Re: [Announce] Enhanced BusyBox package

TMPDIR is set in /etc/profile

with Busybox 1.19.3power1 (*not* the recently updated version) TMPDIR is set correctly when opening X-Terminal (login shell, -sh).

How are you starting bash? If bash doesn't think it's a login shell it might not load /etc/profile. When you run "sh" (Busybox) from bash (or from -sh) TMPDIR is not (or should not be) set again.

If you want bash to read /etc/profile you need "bash --login".

Re: [Announce] Enhanced BusyBox package

Quote:

Originally Posted by reinob (Post 1128484)

I have bash as a default login shell. It has no relation to this issue, I am sure of that. I have had bash as default shell for ages and it never was a problem. It sets TMPDIR regardless of the busybox version. Starting an application like cssu customizer from the menu will have no relation with your default login shell. It is busybox that does not pass TMPDIR to it's own nested shell.

Re: [Announce] Enhanced BusyBox package

@ade....

could you tell me again step by step to fixed this problem???
your step before this is quite confusing...i try it plenty of time still the same bug on TC...

Re: [Announce] Enhanced BusyBox package

Quote:

Originally Posted by pusak gaoq (Post 1128525)

@ade....

could you tell me again step by step to fixed this problem???
your step before this is quite confusing...i try it plenty of time still the same bug on TC...

If you are not interested in reproducing this problem, but just want it fixed for now by reverting to the previous version:

Code:

root

apt-get install busybox-power=1.19.3power1

Re: [Announce] Enhanced BusyBox package

Quote:

Originally Posted by reinob (Post 1127582)

@iDont,

I assume you enabled the option for dropping privs when not needed, right?

Yep, grep for SUID in debian/config/config.busybox

Code:

[sbox-FREMANTLE_ARMEL: ~] > cat busybox/busybox-power/debian/config/config.busybox | grep SUID

CONFIG_FEATURE_SUID=y

CONFIG_FEATURE_SUID_CONFIG=y

CONFIG_FEATURE_SUID_CONFIG_QUIET=y

Quote:

Originally Posted by SeT (Post 1127919)

hi))
In "ls" output russian characters shows as ????, how to fix it?
On default BusyBox all good

Upstream BusyBox has a feature to check what language you have set in your environment variables (CONFIG_FEATURE_CHECK_UNICODE_IN_ENV). It's a good thing to respect these variables, at least by default (i.e. why would you want application XYZ to disrespect your system-wide settings when the user hasn't specifically told the application to do so?). For that reason is this feature enabled in busybox-power, with the result that if your locale isn't (for example) en_EN.UTF8 instead of en_EN, you won't have Unicode support enabled. This is most likely the case on your device.

However, I'll disable CONFIG_FEATURE_CHECK_UNICODE_IN_ENV in the upcoming busybox-power build (see Update 3 in this post)

Quote:

Originally Posted by ade (Post 1128415)

IDon't,

I'm experiencing something that looks like some bug in busybox-power_1.19.3power2. But it is strange I have heard no one else about it.
Yesterday I noticed Python apps started losing their skin/buttons.

I traced it down to this:
For some reason, TMPDIR is not set (or unset) in the user shell (it is still set in the root shell).
Because it is not set, python starts looking in /tmp for the sapwood-engine entry (/tmp/sapwood-:0.0), but is is running in /var/tmp. First exporting TMPDIR to /var/tmp before starting solves it for that session.

When I reverted back to busybox-power_1.19.3power1, TMPDIR was set again. Upgraded to busybox-power_1.19.3power2 again, and TMPDIR was gone.
Setting the export in /etc/profile or ~/.profile does not work. The problem does not occur in the bash shell.

Edit: the issue is visable then a sh shell is opened in a existing shell. TMPDIR is not passed on to the next shell.

Thanks for reporting, launching sh from sh indeed doesn't carry TMPDIR over, I'm looking into it right now.

Update: for some reason the TMPDIR issue is caused by the SUID bit on /bin/busybox. Running "chmod u-s /bin/busybox" fixes the issue with the latest busybox-power. Looking into that now.

Update 2: looks like some upstream issue; on my notebook:

Code:

[dennis@i7-820qm ~]$ export TMPDIR=/tmp

[dennis@i7-820qm ~]$ busybox sh

$ echo $TMPDIR

/tmp

$ exit

[dennis@i7-820qm ~]$ sudo chmod u+s /bin/busybox

[dennis@i7-820qm ~]$ busybox sh

$ echo $TMPDIR



$ busybox | head -n1

BusyBox v1.19.2 (2011-10-16 17:27:24 UTC) multi-call binary.

Only $TMPDIR seems to be affected, $FOO does get carried over on my notebook.

Update 3: Busybox-power 1.19.3power3 has been pushed to the repositories.

It unsets the SUID bit on /bin/busybox as a temporary workaround until the TMPDIR issue has been fixed properly. At the moment it looks like the issue is an upstream bug. I'll report the bug at BusyBox' bugtracker in a day or so, I want to do some additional tests before submitting a report.
This also means that su, ping (and some other SUID-bit requiring applets) won't work as a non-root user anymore (which is also the case with the default BusyBox) until the TMPDIR issue has been resolved.

Lastly, CONFIG_FEATURE_CHECK_UNICODE_IN_ENV has been disabled in this new build. A while ago hxka asked me why CONFIG_FEATURE_CHECK_UNICODE_IN_ENV is turned on in busybox-power. I didn't want to disable for compatibility reasons. There appear to be zero issues however, except that Ctrl-Space will produce a question mark instead of a space when Unicode support is turned on (versus the stock BusyBox; BB-power with Unicode support turned off will print no character at all upon pressing Ctrl-Space).

Re: [Announce] Enhanced BusyBox package

idont, how to send you beer money?

Re: [Announce] Enhanced BusyBox package

Quote:

Originally Posted by vi_ (Post 1128620)

idont, how to send you beer money?

He wasn't willing to accept donations, last I asked him. Worth a second try though.

iDont: I haz money that I am obliged to give you - where you want?

Re: [Announce] Enhanced BusyBox package

Quote:

Originally Posted by iDont (Post 1128548)

At the moment it looks like the issue is an upstream bug. I'll report the bug at BusyBox' bugtracker in a day or so

The bugreport can be found here: https://bugs.busybox.net/show_bug.cgi?id=4544

Quote:

Originally Posted by vi_ (Post 1128620)

idont, how to send you beer money?

Thanks for the offer, really appreciate it. However, I don't accept donations for various reasons. You're free to buy and drink beers for me though ;).

Mentalist Traceur, ^ the same goes for you :).

Re: [Announce] Enhanced BusyBox package

// Edit
Confirmed, really busybox-power causes this bug!

iDont, there have been *unconfirmed* suggestions (although by quite knowledgeable person - freemangordon) that legendary "mysterious" bug with reboot/shutdown (when rebooting device, it actually reboots, then, at stage of Nokia logo, instantly turn itself off - doesn't happen during normal shutdown/powering up), may be caused by some bug in busybox-power.

I don't know if You follow (quite bloated) kp49 thread, but I've been trying to solve it with photologs of framebuffer output (was able to capture whole log of framebuffer from faulty startups), and freemangordon is trying to check WTF is going on.

So, maybe I'm talking about it too early, but, if You happen to have any ideas/stream of consciousness ;) of something in busybox-power, that may cause it, it would be helpful.

BTW, attaching photolog of fbcon output:

..."after" reboot, to point of restart (don't look @ my red notices, they turned out to be non-important):
http://lorienart.pl/cover/fmcon_reboot.jpg

Just before reboot, after invoking "reboot" in console:
http://lorienart.pl/cover/pre-restart.jpg
http://lorienart.pl/cover/pre-restart1.jpg

(Two little different versions, cause it seems to change between reboots - no idea why).

Again, sorry if it's total off-topic here, but lately, twice something "strange" turned out to be busybox-power bug - and no one suspected that - so, I think it's better to be safe than sorry, and pre-report it ;)

BTW, this bug is so ancient, that it would be most "epic" fail of tracing problem's origins, if it's really going to turn out as busybox-power related thing.

/Estel

// edit

Of course, in case anybody isn't sure, absolutely no accusing here.

// edit
confirmed, really busybox-power causes this bug!