New Busybox compile not quite behaving itself..?

[mikewalsh]

Morning, gang.

Amongst a kennels of around a dozen Pups, I run jrb's 'lite' spin on Barry's old Quirky64 'April' 7.0.1. I liked it so much, it's long since become my 'daily driver'. This has been 'upgraded' with Fossapup64's default k5.4.53, along with the matching fdrv & zdrv (of course).

Now; a query. Using a test 'clone' of Quirky, I've compiled the latest version of Busybox (v1.35.0), using the re-named kernel_sources package from Fossa, and Quirky's original devX (converted from the original .pet to an SFS) which adds a number of commands the original default version didn't have. A surprisingly easy process, if I'm honest.

Code: Select all

make defconfig
make
make install

.....is all it takes, and compiles/installs it with the 'default' configuration (everything enabled).

It's all behaving itself very nicely, with one weird exception. When clicking on the drive icons, they mount, as expected, but the respective ROX window fails to open. It flashes up for a split second, then it's gone again.

It's still perfectly possible to access it via the filesystem, using /mnt.......but I wondered if any of you guys might have an idea what's going on here? I'm kinda wondering if one of the new links has overwritten something from the original. Or maybe some of the 'instructions' have changed in the newer release?

I vaguely recall having the same issue with another Pup I tested quite a while ago. I know I fixed it there, but my memory is getting like a sieve, and I simply don't remember what I did!

Any ideas? Thought, pointers, suggestions......all will be gratefully received, as always.

TIA.

Mike.

[Burunduk]

The busybox 1.35 works without a problem here on Fossapup64. It's a precompiled binary I've downloaded from busybox.net and put in place the old one. I don't know what could be wrong with the version you've compiled. But you've run make install. The command tries to install not only the binary but also the bunch of symlinks to it. It is possible that some of the full blown utilities in your system got overwritten by the symlinks. Maybe not, but it's worth to check.

[ozsouth]

It is possible that some of the full blown utilities in your system got overwritten by the symlinks

@mikewalsh - the above (and vice-versa) is exactly what happened to me, so I took the same path as in @Burunduk 's post.

Some of the dramas I had are in post linked below (& few following it):
https://forum.puppylinux.com/viewtopic. ... 1b2#p61637

[mikewalsh]

@ozsouth ;-

Heh. Y'know, that was the first step I took.....looking for the pre-compiled binaries. But all the links I found took me to the same download page.....where, whatever you clicked on, all that came up was a page of incomprehensible squiggles & gibberish.

The source code page DID yield downloads, so I thought, "Ah, what the hell; let's go for it". I was gobsmacked by just how easily it DID compile with the default (everything enabled) config.

There wasn't much point merely replacing the binary. It would still only have the exact same links, so the additional new commands - some 30-odd 'extras' - would have all had to be added in separately afterwards. And it doesn't give you the listings for all the link locations until AFTER its installed them!

Mike.

[wiak]

I agree with the other posters regarding likely issue - symlinks needing fixed (or new compiled binary missing some busybox applet that was in the previous one).

What I usually do when switching to a new version of busybox is to first of all check all the applets that were in the old one, by saving that detail to a text file (list of applets is output if busybox command is given on its own), like so:

cd to where the busybox binary you are trying is, then:

(old version)

Code: Select all

./busybox > /root/appletsORIG.txt

then for new installed version from directory it is in:

Code: Select all

./busybox > /root/appletsNEW.txt

Then you can compare any difference between the two busybox applet sets simply using diff like this:

Code: Select all

diff /root/appletsORIG.txt /root/appletsNEW.txt

which just shows the difference of course.

Even if you have already replaced the previous busybox, if you still have a copy of it you can do the above assuming it the original a static compiled busybox (i.e. statically linked), which it probably was. Can check if statically linked with file command:

Code: Select all

file ./busybox

and that will tell you (also ldd ./busybox would tell you not a dynamic executable if its static...).

As far as creating the symlinks for an installed busybox, you can use a command provided by busybox itself (but be careful you don't mess up the way fossapup has installed the links since, as you know, Puppy often has its own filesystem hierarchy ways of doing things that the following might break... I don't know:

https://unix.stackexchange.com/question ... -stand-for

Code: Select all

busybox --install -s .

Hope I got that right; been a long time since I did it that way. williams2 also wrote about same method, so you can check that: https://forum.puppylinux.com/viewtopic. ... 735#p61735

or alternative simple loop method where all symbolic links end up in same directory as busybox executable itself:

cd to where busybox executable is (e.g. /usr/bin or maybe /bin depending where it is on your system)

Code: Select all

for i in `./busybox --list`; do ln -s busybox $i; done

[peebee]

https://github.com/puppylinux-woof-CE/w ... ds/busybox

https://github.com/puppylinux-woof-CE/w ... ymlinks.sh

[mikewalsh]

@wiak :-

Interesting you should say about static compilation, Will. I notice - from looking through all of PhilB's Pups- that he, at least, has dynamically linked all of his busybox binaries. I've no idea if that's "normal" for this item, or not.

Thanks for the pointers about 'diff', BTW.

Nah, this was just summat of an experiment....."on the spur of the moment", as it were. It surprised me just how easily it DID compile; I loaded the kernel_sources SFS as well as the devX, but I don't think the former was in fact needed.

Curiosity killed the cat, mate! In my case, more like may kill my Puppies if I'm not careful. At least I've gained enough wisdom to try all this stuff with copies these days.....in years gone by, enthusiasm would have got the better of me, and I wouldn't have taken enough care.....

Though I'm still puzzled by the disappearing ROX windows when mounting drives from their desktop icons...

Mike.

[rockedge]

symlinks needing fixed (or new compiled binary missing some busybox applet that was in the previous one).

I ran into this in a Fossapup64 using the WDLGO_UbuntuFocal64 mini-apt/dpkg SFS package that adds the APT package manager to Fossapup64. Once in a while running a full system upgrade, apt update & apt upgrade, there is an update to systemd compoments that wipe out the Puppy Linux needed busybox symlinks to poweroff or reboot and replaced those with systemd symlinks.

This causes the Fossapup64 to not be able to reboot or shutdown cleanly. For this case example, I have a tiny script that replaces the systemd symlinks with Puppy's busybox applets and sysmlinks. I do this by prevoiusly inserting into the Fossapup64 rootfs SFS backup copies of the needed components for Puppy to perform reboots and shutdowns cleanly. The script just replaces the systemd stuff with the Puppy backups.

All of this occurs in /sbin