Active Topics
|
2011-11-30
, 09:05
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#182
|
Ahem. I have (until now) never felt the need of rebooting (normally I turn-off and then on).
Just for the sake of it, I just went to the terminal, and, as root, typed "reboot". And guess what. It rebooted just fine
NOTE: I mean, I first became root (no sudo reboot, no sudo gainroot and then reboot, I mean first "root", and then "reboot").
I have KP47, busybox-power (the one in extras-testing). No CSSU.
The only weird things I've noticed after rebooting is that the transitions seem to be extremely jerky. I open the dialer and it stops mid-rotation (but works). I close it and see only half of the desktop (but I can click on a (invisible) shortcut and it works).
In dmesg I get a lot of "HWRecoveryResetSGX: SGX Hardware Recovery triggered", so I guess rebooting doesn't properly initialize the GPU.
I'm shutting down now and turning on normally, just in case.
Last edited by reinob; 2011-11-30 at 09:07. Reason: s/kernel-power/busybox-power/
Just for the sake of it, I just went to the terminal, and, as root, typed "reboot". And guess what. It rebooted just fine
NOTE: I mean, I first became root (no sudo reboot, no sudo gainroot and then reboot, I mean first "root", and then "reboot").
I have KP47, busybox-power (the one in extras-testing). No CSSU.
The only weird things I've noticed after rebooting is that the transitions seem to be extremely jerky. I open the dialer and it stops mid-rotation (but works). I close it and see only half of the desktop (but I can click on a (invisible) shortcut and it works).
In dmesg I get a lot of "HWRecoveryResetSGX: SGX Hardware Recovery triggered", so I guess rebooting doesn't properly initialize the GPU.
I'm shutting down now and turning on normally, just in case.
Last edited by reinob; 2011-11-30 at 09:07. Reason: s/kernel-power/busybox-power/
| The Following User Says Thank You to reinob For This Useful Post: | ||
|
|
2011-11-30
, 09:40
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#183
|
Hmm.. reading https://bugs.maemo.org/show_bug.cgi?id=7017 it appears that, at least for one user, the problem was with undervolting, which I also do ("standard" LV).
Maybe I'll try setting it back to std. voltage and reboot again. But most likely not today (I'm "on-call" today, so to speak).
Maybe I'll try setting it back to std. voltage and reboot again. But most likely not today (I'm "on-call" today, so to speak).
|
|
2011-12-11
, 12:46
|
|
Posts: 1,100 |
Thanked: 2,797 times |
Joined on Apr 2011
@ Netherlands
|
#184
|
@IDont:
Any thoughts on how to proceed with the "TMPDIR" issue?
I have been following the bugreport at busybox.net, and glibc is blamed for for this behaviour. Their only suggestion for a workaround is two busybox binaries. Maybe not the most elegant solution...
Today I adapted a script of mine which needed to ping to check a connection. As I did not want to run it as root, I decided to install Iputils-ping for now, replacing the busybox ping.
Last edited by ade; 2011-12-11 at 12:50.
Any thoughts on how to proceed with the "TMPDIR" issue?
I have been following the bugreport at busybox.net, and glibc is blamed for for this behaviour. Their only suggestion for a workaround is two busybox binaries. Maybe not the most elegant solution...
Today I adapted a script of mine which needed to ping to check a connection. As I did not want to run it as root, I decided to install Iputils-ping for now, replacing the busybox ping.
Last edited by ade; 2011-12-11 at 12:50.
|
|
2011-12-11
, 19:25
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#185
|
Originally Posted by ade
We used to do just that, but -for obvious reasons- having two different binaries caused some issues with software that assumed everything was provided by the main (i.e. default) BusyBox binary. I'm very time constrained lately, but I'm hoping to have some solution ready in the upcoming week. I'll try out some possible solutions I've been thinking of, but I'm not sure yet whether they'll work or not.
@IDont:
Any thoughts on how to proceed with the "TMPDIR" issue?
I have been following the bugreport at busybox.net, and glibc is blamed for for this behaviour. Their only suggestion for a workaround is two busybox binaries. Maybe not the most elegant solution...
Today I adapted a script of mine which needed to ping to check a connection. As I did not want to run it as root, I decided to install Iputils-ping for now, replacing the busybox ping.
What would work for sure is reverting the commit that merged the binaries back together and duplicate some 'SUID applets', but that's more like a last resort solution.
Originally Posted by ade
That's probably the easiest solution if you're dependent on running ping as a non-root user for now. You could also download an earlier version of busybox-power and use busybox_root's ping applet, if disk space is a concern to you.
Today I adapted a script of mine which needed to ping to check a connection. As I did not want to run it as root, I decided to install Iputils-ping for now, replacing the busybox ping.
|
|
2011-12-19
, 21:04
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#186
|
Back with an update: I've been experimenting with some workarounds I had thought of last week. Unfortunately, they did not work. I had some hope in creating logic to temporarily store TMPDIR in another variable, but that didn't work out too well.
I can think of three other solutions that would work for sure:
-Parse a simple key-value configuration file (e.g. /etc/environment) to set default environment variables when they're not already set
-Split busybox back into busybox and busybox_root and duplicate some 'SUID' applets.
-Hard-code TMPDIR in BusyBox' main(), which completely defies the meaning of "variable", and thus won't be done
It looks like I'll have another busy week ahead of me, but I'm pretty optimistic to have something working this week.
I can think of three other solutions that would work for sure:
-Parse a simple key-value configuration file (e.g. /etc/environment) to set default environment variables when they're not already set
-Split busybox back into busybox and busybox_root and duplicate some 'SUID' applets.
-Hard-code TMPDIR in BusyBox' main(), which completely defies the meaning of "variable", and thus won't be done
It looks like I'll have another busy week ahead of me, but I'm pretty optimistic to have something working this week.
| The Following 7 Users Say Thank You to iDont For This Useful Post: | ||
|
|
2011-12-24
, 10:32
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#187
|
There's a special build of busybox-power 1.19.3power3 up at our garage page. It installs /etc/environment and parses it prior to applet launch. This file contains simple key-value entries to set environment variables.
Environment variables are only loaded if they're not already set; user/system set variables take precedence over the configuration file (launching "foo" with "TMPDIR=/bar foo" makes TMPDIR not get loaded from the configuration file).
Lastly, /bin/busybox is setuid again in this build, which made eglibc drop e.g. TMPDIR in the first place
.
Please test this build and report back any issues you encounter. The build can be found here: https://garage.maemo.org/frs/shownot...elease_id=4754. The parser will be included in busybox-power 1.19.3power4 if no bugs are found.
I've attached the created patch to this post. The introduced load_env_vars() function is based on the already existing parse_config_file() function, so I'm not expecting too much issues. However, as always, feedback is highly appreciated.
Environment variables are only loaded if they're not already set; user/system set variables take precedence over the configuration file (launching "foo" with "TMPDIR=/bar foo" makes TMPDIR not get loaded from the configuration file).
Lastly, /bin/busybox is setuid again in this build, which made eglibc drop e.g. TMPDIR in the first place
.Please test this build and report back any issues you encounter. The build can be found here: https://garage.maemo.org/frs/shownot...elease_id=4754. The parser will be included in busybox-power 1.19.3power4 if no bugs are found.
I've attached the created patch to this post. The introduced load_env_vars() function is based on the already existing parse_config_file() function, so I'm not expecting too much issues. However, as always, feedback is highly appreciated.
|
|
2011-12-24
, 12:30
|
|
Posts: 1,100 |
Thanked: 2,797 times |
Joined on Apr 2011
@ Netherlands
|
#188
|
Originally Posted by iDont
I ended up in a reboot loop after manually installing the deb file and rebooting. No idea if I did something wrong, or if it's an issue of the package
There's a special build of busybox-power 1.19.3power3 up at our garage page. It installs /etc/environment and parses it prior to applet launch. This file contains simple key-value entries to set environment variables.
Environment variables are only loaded if they're not already set; user/system set variables take precedence over the configuration file (launching "foo" with "TMPDIR=/bar foo" makes TMPDIR not get loaded from the configuration file).
Lastly, /bin/busybox is setuid again in this build, which made eglibc drop e.g. TMPDIR in the first place
Please test this build and report back any issues you encounter. The build can be found here: https://garage.maemo.org/frs/shownot...elease_id=4754. The parser will be included in busybox-power 1.19.3power4 if no bugs are found.
I've attached the created patch to this post. The introduced load_env_vars() function is based on the already existing parse_config_file() function, so I'm not expecting too much issues. However, as always, feedback is highly appreciated.
|
|
2011-12-24
, 12:36
|
|
Posts: 268 |
Thanked: 1,053 times |
Joined on May 2010
@ The Netherlands
|
#189
|
Originally Posted by ade
Hmm, I check all debs before uploading, plus wget them after uploading to check them again. It is working here :-/
I ended up in a reboot loop after manually installing the deb file and rebooting. No idea if I did something wrong, or if it's an issue of the package
Do you happen to have a framebuffer enabled? How soon after the Nokia screen did it reboot?
Edit: Also, did you notice anything out of the ordinary after installing the deb?
| The Following User Says Thank You to iDont For This Useful Post: | ||
|
|
2011-12-24
, 12:43
|
|
Posts: 1,100 |
Thanked: 2,797 times |
Joined on Apr 2011
@ Netherlands
|
#190
|
After installing all looked good (ping worked as user, no error messages). Just to be sure I decided to reboot for a final check.
Not aware that I have framebuffer enabled, but I do have installed backup menu.
In the root console of backup menu see the new busybox:
BusyBox v1.19.3 (Debian 1.19.3power3~envparser) built-in shell (ash)
Not aware that I have framebuffer enabled, but I do have installed backup menu.
In the root console of backup menu see the new busybox:
BusyBox v1.19.3 (Debian 1.19.3power3~envparser) built-in shell (ash)
| The Following User Says Thank You to ade For This Useful Post: | ||
since i'm using CSSU with busybox-power & KP49 same problem but this time it got a little different....
using x-term it will reboot sometime...if using power button (add reboot button) successful reboot is at 80%...if i use the shutdown button successful shutdown will be at 50% while another 50% it just auto-reboot....
My Phone Evolution : Nokia 3650-Nokia 6600-Nokia 6630-Motorola Rizr-Sony P1i-Nokia E63-Nokia X3-Samsung E980-Iphone 2G-Sony W595-Nokia E71-Nokia 5800-Nokia N900-HTC Hero-Xperia Mini Pro