Re: [Announce] Enhanced BusyBox package
 

This is a known problem, you can safely ignore it. Everything will still work exactly as expected.

Re: [Announce] Enhanced BusyBox package
 

Just a little unpleasant if you don't know what keys to press :)

Again, thanks a lot. I have learned a few things today.

Will do a little more research, but will probable choose for a restore backup from backup menu. That backup will we be quite old, but I afterwards I hope to rsync more recent data from my PC to my N900.

Re: [Announce] Enhanced BusyBox package
 

Yeah, I see. Well, "t" + "any key to continue" is for starting a root shell (if you want to remove "modprobe fbcon" again ;))

I'm glad to hear that :). Feel free to contact me by PM if you need to know something anytime.

I would first try what I suggested before: adding a multitude of sleep commands in the boot process (and continue to add more as you'll get closer to the failing command) to find out exactly where it is failing. To be honest, I'm very curious myself what causes the reboot loop. Anyway, good luck restoring.

Re: [Announce] Enhanced BusyBox package
 

Oops, perhaps I have been a little premature in restoring rootfs seeing your advice to use the sleep command.

Anyway, I did a rootfs restore (no optfs) and the phone boots fine now. I might do some extra rsync of the rootfs to make it more up-to-date. And then: installing your new busybox of course :D

Re: [Announce] Enhanced BusyBox package
 

Second attempt for install...

All looks good, TMPDIR is parsed as expected and for example ping is executable as user.

So I would say: thumbs up for your well designed solution and an upload to the repo!

edit:
found the reason for my initial reboot loop: just before installing busybox, I replaced /usr/bin/camera-ui, but forgot to make it executable again. And camera-ui is loaded on boot...

Re: [Announce] Enhanced BusyBox package
 

I'm not sure if this bug belongs here at all, but I have no better idea, what may cause it - so, if I'm going to talk silly things here, just say a word:

Yesterday, I left my Phone with some things opened, and due to battery being low, BME shut device down. For reasons unknown, something went bad, and my /dev/mmcblk0p2 went FCKD'ed totally, bringing device (for the first time, I must admit) to state of not being able to go past five dots.

I've opened backupmenu and recovery console, ensured that /dev/mmcblk0p2 is unmounted (just in case) and started fsck.ext4 (I use ext4 for home). fsck detected 3 wrong inodes and "unexpected inconsistency", so I was forced to run it manually, assuming "yes" to repair questions, as there were literally hundreds of them.

After passing stage 1 and 2 of fsck'ing (in fact, at this point, it was
e2fsck if I recall correctly), my showstopper bug manifested itself:

Any further attempts resulted in fsck segfaulting in exact same moment. In desperation, I also tried fsck.ext3 and even fsck.ext2, but they segfaulted in exactly same stage too. As You may presume, it left my partition in such state, that device *was* bootable, but acted like with totally empty /dev/mmcblk0p2 - You can imagine rest, I ended up restoring optFS from backup.

---

So, as I have said, I have no idea if fsck is related to busybox-power at all, but it seems it fails totally, when more advanced repair operations are required, Sorry, if it is not related here - in such case, please give me a hint about correct place, and I'll repost story there.

/Estel

Re: [Announce] Enhanced BusyBox package
 

Yup, I've had on-device fsck pop a vein on my phone (albeit in a less critical situation). Probably related to running low on memory.

Re: [Announce] Enhanced BusyBox package
 

fsck is not a part of busybox, so in that way it is not the right place here.

Did you run the fsck using the N900? Then maybe it was an option to do the fsck from a linux PC, using backup menu USB mass storage mode on N900.

Re: [Announce] Enhanced BusyBox package
 

Thanks for comments - Yea, I was doing it on device itself - as I described, from backupmenu recovery root terminal. Unfortunately, I'm on a trip, so I don't have access to any linuxbox (even via liveCD).

Anyway, if fsck isn't by any means tied to changes made by busybox-power, it seems unrelated here, so sorry iDont.

/Estel

Re: [Announce] Enhanced BusyBox package
 

Hmm, it's still probably a valid concern for the Maemo community.

We're running an ancient version of e2fsprogs (1.41.3/2008 Oct 12) which is 12 stable versions behind the latest version (1.42/2011 Nov 29).

e2fsprogs-power tiem?

Re: [Announce] Enhanced BusyBox package
 

That made me chuckle :o

For now it's busybox-power time, well, uhm, tiem. A new release has been pushed to the auto builder. It incorporates the patch posted earlier and got synced up hotfixes for BusyBox 1.19.3.

I've skipped pushing busybox-power 1.19.3power2 to Maemo's extras, because it didn't play nice with the root shell functionality in BackupMenu. Busybox-power 1.19.3power4 will be pushed to extras-testing tomorrow, but that'll unfortunately require everyone to re-vote it up again (for good reasons though). Please submit this new release to some more testing than usual as the incorporated patch is relatively invasive. I'm not expecting any issues however :).

Re: [Announce] Enhanced BusyBox package
 

I have been using the patched version from the moment it was released and I have seen no issues. So I have all the confidence in upcoming 1.19.3power4 release.

Re: [Announce] Enhanced BusyBox package
 

Add.: sorry for the off-topic rant!

There's really something broken in Maemo. I can just now accept a reboot loop just because some binary that is completely unnecessary for booting is not marked as executable.

*THIS* would be something worth a CSSU!

Re: [Announce] Enhanced BusyBox package
 

I'm not sure I want to update. I actually prefer having a std. /bin/busybox and a suid /bin/busybox_root.

I mean, if using PING (among others) requires root priviledges, why should busybox bypass this? we can all use sudo when required.

Apparently there are good security reasons why TMPDIR and other env. vars are not inherited from suid binaries, and this is the standard behaviour in glibc, i.e. not considered a bug. I don't see why busybox also has to bypass this behaviour.

Aside from personal opinions or preferences, are there any *actual* problems caused by (1) having a separate suid busybox_root, and (2) leaving the TMPDIR behaviour as it is/was?

Would be happy to get an answer to the last question. Otherwise I might just stay with 1.19.3-power1, or do my own busybox, or get rid of busybox completely.

Re: [Announce] Enhanced BusyBox package
 

I'm sorry for being an off-topic bastard, but I just laughed out loud and probably woke up the neighbours. :p

Re: [Announce] Enhanced BusyBox package
 

Unfortunately, that's enabled for some sort of convenience reason by Nokia. The solution, of course, is to enable r-d mode.

Re: [Announce] Enhanced BusyBox package
 

Installed last busybox-power, got reboot loop.
When I turn on N900, white screen appears, several seconds after it just turns off.

Enabling rd mode doesn't help.

I have (had) installed backupmenu-multiboot, but it's not starting by opening slide any more.

Is there any way to edit rootfs from PC? rescue-kernel from meego, I can start terminal but can't do anything to roots.

Can I somehow start backupmenu from PC with flasher?

Or should I just reflash rootfs and restore it from backup (I made some modifitions (customizations) after last backup, and I will get backup only at Monday, so I search for all other solutions)?

Re: [Announce] Enhanced BusyBox package
 

using RescueOS, You need to mount rootfs somewhere (from terminal), before being able to make any changes.

I can't imagine, how installing busybox may be related to multiboot disappearance.

/Estel

// Edit

I'm also using backupmenu-multiboot (although, backupmenu component manually updated to latest one + tweaked to support ext4 /home - shouldn't matter, in this case) and update went without problems, rebooted many times since that.

So, it's worksforme.

Re: [Announce] Enhanced BusyBox package
 

I don't know, maybe my problem isn't related to busybox.
Reboot occured while I installed upgrade today (busybox and espeak), after that phone don't start.
Thanks for RescueOS, I'll try it right now.

Re: [Announce] Enhanced BusyBox package
 

Big thanks for prompting RescueOS, I fixed phone without reflashing.
I had 0-sized /bin/busybox. Accidental reboot appeared in wrong time.

What is the reason of reboot I don't know, maybe enabled SR or ramzswap.

I think it was watchdog. 4Mb deb installs on my phone 15-20 minutes. (hildon-desktop starts to update menus from desktop-files, I have installed many-many programs)

Re: [Announce] Enhanced BusyBox package
 

Because it is common to make ping (and some others) setuid on a typical Linux installation. For example, Archlinux (which I'm using) has /bin/ping setuid root. Only thing is that we have BusyBox providing those typically setuid applications, which is perfectly fine since BusyBox supports automatically dropping privileges when they're not required.

The new patch doesn't make BusyBox bypass the behaviour; that can not be done by glibc' design. It only makes BusyBox parse a key-value list of variables, and set just those variables that are not already set. The list only contains TMPDIR by default.
There are no security implications with this behaviour AFAIK, as the environment variables are still not inherited and non-root users can't edit the key-value list of variables.

There shouldn't be any problems at all. However, applications can assume that all applets are provided by /bin/busybox, which will of course fail when an applet is moved to /bin/busybox_root (regardless of whether that applet is correctly symlinked to /bin/foo or not). This is currently the case with BackupMenu's root shell functionality.

Also, having one single binary is easier to maintain and cleaner in my opinion, which are the main reasons for taking the current approach to me.

Just a suggestion: if ping is the only setuid application you're using, you could just run `chmod u-s /bin/busybox` and install iputils-ping, that seems to be easier :).

By the way, lma also had a good idea regarding this topic: split busybox into busybox and busybox_root, and make busybox exec busybox_root when it is invoked with e.g. ping. I'll certainly look into that, but it might take a while before I'll get around to that (patches are welcome of course).

--

Edit: forgot to mention: busybox-power 1.19.3power4 should hit extras-testing in an hour or so. Please submit it to some serious testing!

Re: [Announce] Enhanced BusyBox package
 

iDont, could You check this:
http://talk.maemo.org/showthread.php?t=81613&page=4
...? It seems, that some things were changed in dd between stock busybox, and busybox-power. It wasn't tested by me, but people using busybox-power have problems with u-boot, where others are fine.

I'm sure Pali will incorporate some fix for that on u-boot side, but, maybe it's also something important for busybox to consider?

/Estel

Re: [Announce] Enhanced BusyBox package
 

It's just a flag that is not supported by the stock busybox nor busybox power and will result in an error in both cases. So I can't image that is was fine with people using the stock busybox. Errors where redirected to /dev/null in this case, so maybe not everybody saw the error.

Try some test commands if you are in any doubt.

Re: [Announce] Enhanced BusyBox package
 

Thanks, ade. It's just that after "half-year" unreported bug with backupmenu root console and busybox, I'm preferring to report early (and possibly wrong), rather than not reporting at all ;)

/Estel

Re: [Announce] Enhanced BusyBox package
 

i have updated busybox-power and i have no problems with stability nor multiboot

Re: [Announce] Enhanced BusyBox package
 

Why is the command "Free Rootfs" of desktop command execution widget not working when upgrading from stock busybox?

Re: [Announce] Enhanced BusyBox package
 

e2fsck-static from Wheezy does the job perfectly, segfaults at pass 3A on a damaged ext4 are gone.

I don't think it should be included in busybox-power

Re: [Announce] Enhanced BusyBox package
 

Thanks for the pointer. However, ade seems to be right on this one, i.e. not caused by busybox-power. I've notified pali about the unsupported parameters.

Thanks for reporting. That must be because we ignore the rootfs entry in df's output as per this commit. Next busybox-power release will have this fixed (*click*).

Re: [Announce] Enhanced BusyBox package
 

Beacuse the entry for rootfs reads "ubi0:rootfs"

So you need:

Does the stock busybox/df show only "rootfs"?

In any case, with:
it should work as long as "rootfs" appears in the first field.

Add.: cat /proc/mounts shows "rootfs" AND "ubi0:rootfs". Busybox/df skips "rootfs", but still shows "ubi0:rootfs", so as a workaround it's OK. Don't know why coreutils/df might want to skip rootfs. Doesn't make any sense to me..

Re: [Announce] Enhanced BusyBox package
 

Thanks for providing an alternative command, reinob :)

libbb/Config.src provides some insight:

Re: [Announce] Enhanced BusyBox package
 

Thanks iDont. You convinced me :), now I'm running power4 without any issues. Checked /etc/environment (was a bit surprised that it was included with the package/installation) and looks OK.

Cheers to you, and thanks again.

Re: [Announce] Enhanced BusyBox package
 

F'ing hate talk.maemo.org's quick reply box - why is it that if I use a normal make-a-new-post page and accidentally press back/forward or load a different page, a browser knows to save my text, but it can't do the same for the quick-reply?

Lost my post twice in a row just now.

Anyway, request: Please enable the ':p' command in vi in the next version of busybox-power - I'm one of those wierd people who use vi for everything, but because vi lacks proper support for the system-wide copy-paste buffer, the only way to get copy-paste going in vi is by opening multiple files using the same vi instance and being able to switch between them, or by reading in the entirety of another file into the one you're working with using the :r command (which is just painful for large files). The current busybox-power's vi has the :n command, which lets it go to the next file, but not the :p command to go to the previous file, and since it doesn't loop around, having only :n makes copasting code or w/e between files a much more convoluted endeavor.

On an unrelated note, although I haven't been on this forum in a while, I appreciate the regular busybox-power updates coming from you iDont.

Re: [Announce] Enhanced BusyBox package
 

All instances of ':p' in the last post are intended to be justand not smileys.

Re: [Announce] Enhanced BusyBox package
 

Been there. I've made a habit of typing pretty much all of my posts in a text editor prior to posting ;)

It looks like there's no support for : p in busybox' vi, so it can't be enabled. However, I've written a small patch to implement it. The patch is attached to this post and a precompiled deb can be found here. Please test it and let me know if you encounter any issues with it.

One question though: (I only have superficial knowledge of vi, so I could've done something wrong) : p doesn't make vi go back one file on my notebook either, so is this a standard command (at least in the latest release of vi)? I did found some cheat sheets referring to : p as "Go to previous file" though.

:rew is supported by busybox's vi, so you could use that as well.

Thank you :)

Re: [Announce] Enhanced BusyBox package
 

Hey, as another weird person who uses vi for everything, maybe I can suggest pulling down the full "vim" package -- I don't know if you're pressed for space or something, but having the full desktop version of vim at your beck and call is a wondrous thing. Not only can you switch between files with :n and :N, you can actually ":sp" split-screen to see multiple files at once. The thing is just ridiculously powerful. :) (I love being able to browse source code with syntax highlighting and all right on my phone...)

Re: [Announce] Enhanced BusyBox package
 

iDont, how do you manage to be so awesome? Explain.

Precompiled .deb downloaded and tested, seems to work perfectly in a short test I did.

You were also correct in that it would seem that my VirtualBox debian environment (where I do packaging for the maemo repositories and such) also has a vi that doesn't have a : p command.

Granted, vi there just works badly so on there I just use vim usually, so that vi may not be representative either.

At any rate, I just supposed full-featured vi must have it since some cheat sheets I found online included it.

Are you going to submit the : p patch upstream if it keeps proving stable, or incorporate it into the repo version of busybox-power, like you did with the history+ram patch (which, btw, was also awesome, and was one of my earlier clues as to how awesome you are)?

Since I now know from your post that there's a ':rew' command (what would I do without you, seriously) it's not as pressing of an issue for me, but the : p is certainly convenient as well.

Copernicus: I'm aware that vim exists for the N900, but it's just not simplistic enough, I guess. I almost didn't like ls's file coloring when busybox-power added it - took me a while to decide I liked it. There's also a part of me that likes vi over vim on principle, kinda like how I like C over C++. There's a certain charm in my mind to doing things a somewhat more primitive way. Another consideration for me is the inclusion of vi into busybox - I always keep the latest .debs of certain files on my N900s for quick restoration to minimal usability (which funny enough includes aircrack-ng suite and macchanger in my mind) after a reflash, which serves as another motive for sticking to vi. (Doubt you were interested in my little ramble about my psyche just now, but oh well.)

However, this split screen feature I did not know of, and it intrigues me. I'll look into it and consider it. Your recommendation may well lead me towards switching.

And nay, I don't have space issues - I have a haxed eMMC flasher image with a 9 GiB /opt partition that my N900s get treated to and I manually move and symlink a bunch of stuff out to opt (such as all the contents of the C library for gcc compiling on-device, etc).

Re: [Announce] Enhanced BusyBox package
 

Split screen is just the beginning! Full-fat vim pwns the **** out of busybox vi in every conceivable way.

Dang, maybe I should have called myself vim instead.

Re: [Announce] Enhanced BusyBox package
 

I don't know, although it's rather obvious that I am :p.

Great!

The patch will be be included in the next busybox-power release. And yes, I do have plans to submit it upstream. That's actually also why I asked if : p is a standard command ;). Anyhow, standard or not, I'll send it to the BusyBox mailing list anyway and leave it up to the BusyBox developers to decide whether they include it or not.

Edit: the patch has been included upstream!

Re: [Announce] Enhanced BusyBox package
 

I have had a strange problem with history in version 1.19.3power4.

I have now a file .ash_history that contains ordinary words (probably fron writing SMS or emails) separated by a question mark '?' and my useful history has been moved to a file .ash_history.3055.new. More that that, the words are placed in a way that are similar to a dictionary.

As in the current .ash_history appears the question mark, every time a try to CTRL+R any past command it tries to use the ordinary words from the current file.

To solve it, I just removed the bad file and replaced with the correct one, but I thought it would be worth to mention it here.

Edit: The file with .number was too old, it seems I have lost most of my command history.

Re: [Announce] Enhanced BusyBox package
 

Awesome @ : p now being accepted upstream, as well as it being in the latest update.

As for the post by ivgalvez, I had something like this happen - I did not investigate, I just had my N900 (old unstable one, not the one I bought from dr_frost_dk) randomly crash, and when it rebooted, instead of old commands, I had what appeared to be the contents of some system file as my shell history. I did figure out at the time what the file was, but now I don't recall. It was absolutely unrelated to either shell history, nor did it contain random words separated by ?s.

Idk what that was about, but a while later, after some new history had been written to the history file, it was once again replaced with the correct history, and I haven't had it happen again since.