DSM-G600, DNS-3xx and NSA-220 Hack Forum

Interesting because this is what I get:

root@raider:/# find /ffp/ -name "*bash*"
/ffp/var/packages/bash-3.2-3
/ffp/share/man/man1/bash.1
/ffp/share/man/man1/bashbug.1
/ffp/share/info/bash.info
/ffp/bin/bash
/ffp/bin/bashbug

root@raider:/# cat /ffp/var/packages/bash-3.2-3
./ffp/share
./ffp/share/man
./ffp/share/man/man1
./ffp/share/man/man1/bash.1
./ffp/share/man/man1/bashbug.1
./ffp/share/info
./ffp/share/info/bash.info
./ffp/share/info/dir
./ffp/bin
./ffp/bin/bash
./ffp/bin/bashbug

root@raider:/# funpkg -r bash
Removing package bash-3.2-3 ...

find /ffp/ -name "*bash*"
/ffp/share/man/man1/bash.1
/ffp/share/man/man1/bashbug.1
/ffp/share/info/bash.info
/ffp/bin/bash
/ffp/bin/bashbug

root@raider:/# cat /ffp/var/packages/bash-3.2-3
cat: can't open '/ffp/var/packages/bash-3.2-3': No such file or directory

So as you can see it is NOT working fine for me.
Not clear why though... I'm stumped...

Actually, problem is more general - uniq seems to only be looking at the first letter in the line...
For example:
root@raider:/# echo -e "ab\nac" | uniq
ab

It is as if the default is uniq -w 1

In fact substituting "uniq -w 100" in funpkg fixes the problem.

So my issue is definitely with uniq....

I'm surprised that such a basic Unix function would be broken. Can you verify that I am not doing something stupid?

Also, is there a more recent version of busybox available?

If not you may want to adjust the script (and any others in funplug) to use 'uniq -w <big number>' since the 'funpkg' is about as fundamental as you can get and not everybody has coreutils installed.
uniq is also used in several other shell scripts.

Alternatively, let me know what you suggest...

I don't think it's a busybox bug, but a problem with uclibc.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(int argc, char **argv)
{
        printf("%d\n", strncmp("aa", "ab", -1));
        exit(0);
}

behaves differently on my glibc/i386 and uclibc/arm systems.

puterboy wrote:

Can you verify that I am not doing something stupid?

A new uclibc package is coming soon ( http://www.uclibc.org/lists/uclibc/2008 … 20134.html ).

This may be a dumb/obvious question but what is the best way to update an existing fun_plug installation.
Can I just type: funpkg -u fun_plug.tgz or do I need to start from scratch by placing fun_plug.tgz in /mnt/HD_a2, reboot and let the system reinstall the entire /ffp heirarchy?

fonz wrote:

puterboy wrote:

This may be a dumb/obvious question but what is the best way to update an existing fun_plug installation.
Can I just type: funpkg -u fun_plug.tgz or do I need to start from scratch by placing fun_plug.tgz in /mnt/HD_a2, reboot and let the system reinstall the entire /ffp heirarchy?

ffp is a collection of packages. You can install, upgrade and remove packages with funpkg. fun_plug.tgz is nothing more than files from a selected set of packages, so if you upgrade the packages, there's no need to get a new fun_plug.tgz (you cannot do funpkg -u fun_plug.tgz - it's not a funpkg archive).
Of course, you can also just drop a new fun_plug.tgz to Volume_1 and reboot. The fun_plug script will unpack the archive as usual and install new files.

I'm still a bit confused then...
In my /ffp/var/packages folder, I seem to have a package named fun_plug-0.5-08_08_31 (along with some other packages that were automagically installed and a couple that I installed myself). Also, fun_plug seems to be the package that contains the ulibc library since it is the only package that returned results when I grepped "grep -i uclibc.

So, I'm still left with the question of how do I upgrade uclibc (or more generally any of the files contained in /ffp/var/packages/fun_plug-0.5-08_08_31 other than having to "drop a new fun_plug.tgz to Volume_1 and reboot". I guess I'm confused about why fun_plug appears in /ffp/var/packages if it is not a funpkg archive as the other members of the directory seem to be.

That makes sense...
But as a purist and a minimalist, how does one upgrade a reduced installation consisting of maybe just fun_plug and a few other choice packages?

I know how to upgrade the other packages that I have explicitly installed (or that were dragged in along with fun_plug) but it seems like you are saying that there is no simple, clean way of upgrading just fun_plug itself.

I know I must be sounding stupid here but am I missing something?

I am resisting reinstalling fun_plug.tgz at /mnt/HD_a2 because that would presumably overwrite any changes to my current installation and may even require reinstallation of the other packages I have installed along with redoing any config changes I have made since presumably fun_plug.tgz would overwrite subsequent changes.


Would a better/cleaner alternative for me be to write a script that does something like the following:
1. 'tar xvzf fun_plug.tgx var/packages'  in temp directory <newpackages>
2. Examine the contents of <temp>/var/packages
       A. For all PKG in <newpackages> != funpkg-<new version>
           If version number of PKG has changed and it is greater than the version in /ffp/var/packages, run subroutine analogous to upgradepkg()
           to effectively upgrade the package
                  i.e.  funpkg - r <PKG>
                        tar xvzf funpkg-<new version> --files-from <newpackages>/PKG
                        cp <newpackages>/PKG /ffp/var/packages
       B. For all FILE in <temp>/var/packages/funpkg-<new version>
              If FILE is referenced in another package in /ffp/var/packages, do nothing (since it will be updated with that package)
              Othewise, untar the file from <temp> to /ffp
      C. For all FILE in /var/packages/funpkg-<old version>
             If FILE is not listed in any of the packages in <temp>/var/packages or in any of the non fun-pkg packages in /ffp/var/packages,
                  then erase FILE from /ffp since it is no longer needed
      D. Update the entry in /var/run/packages to funpkg-<new version>
              i.e.    rm /ffp/var/packages/funpkg-<old version>
                       cp  <newpackages>/funpkg-<new version> /ffp/var/packages

In a sense, the above algorithm (if correct) would allow funpkg to be treated as an upgradeable archive.

Maybe I'm being a bit obsessive-compulsive here, but I like to keep my setups very clean and updateable

Thanks Fonz. I think that looks like a good path to follow (for me).
However, I still seem to be missing something.
None of the packages that you mention above are listed in /var/packages (presumably because they are part of fun_plug-0.5) but conversely the following packages were automagically installed when I installed fun_plug-0.5-zzzz:
           
less-418-3
rcorder-cvs-4
busybox-1.11.2-1
lighttpd-1.4.19-4
rsync-3.0.3-1
lsof-4.80-1
shadow-4.1.2.1-1
dialog-1.1-3
man-1.6e-3
strace-4.5.16-3
dns323-utils-0.7.176-2
mediatomb-0.11.0-5
ffp-scripts-0.5-17
nfs-utils-1.1.0-4
unfs3-0.9.20-4   
ntp-4.2.4p4-4           
usbutils-0.73-1
funpkg-0.5-1
openssh-5.1p1-1
groff-1.19.2-3
portmap-6.0-4

So,
1. Is it correct to say that fun_plug-0.5-zzz consists entirely of the union of the packages that you list in your posting and the packages that are explicitly added to /ffp/var/packages and listed above?
2. If so, what is the logic for explicitly listing some of the packages but not others?
   i.e. what is the difference between the packages that you list (and whose files appear in fun_plug-0.5-zzz vs. the packages that are explicitly listed in /ffp/var/packages?

Interesting....
First, I apologize if I am annoying you, but I really am trying to understand the fun_plug system as best as possible.

I was just doing my own 'diffing' and it seems that there are libraries in the first block that are not included in fun_plug either. So while I'm sure using the individual packages you mention will work, it does not seem to give me an equivalent minimalist build that fun_plug does.

This leads me to the following suggestion:

Is there any reason not to also build a stripped down version of fun_plug-0.5 (say called something like fun_plug_base) that is in true package format and has ALL the files that belong to just the partial packages that are included in the fun_plug but not in the full packages that are included in fun_plug (Plus perhaps a single file manifest that lists all the full packages that are included in the normal fun_plug but excluded from this stripped down version)

Then it seems that one could always upgrade (or even install) by doing the following:
- Upgrading fun_plug_base
- Upgrading the individual full packages listed in the fun_plug_base manifest

Conversely the full fun_plug would then literally just be a single tar file that simply combines the contents of fun_plug_base and the individual packages listed in the the manifest.

To my engineering mind, this seems like a very simple, clean and understandable solution but maybe I am missing something....

fonz wrote:

puterboy wrote:

2. If so, what is the logic for explicitly listing some of the packages but not others?
   i.e. what is the difference between the packages that you list (and whose files appear in fun_plug-0.5-zzz vs. the packages that are explicitly listed in /ffp/var/packages?

2. all files from the packages listed in /ffp/var/packages are installed. programs and libraries are installed from the first block of packages above, only libraries from the second block. because they are not installed completely, they are not listed in /ffp/var/packages but make up the special fun_plug-0.5 package.

I think maybe I misunderstood your use of "libraries" because when I do a diff of the files in your first block against fun_plug.tgz I get a whole slew of /ffp/lib files but I assume maybe that those are compile-time libraries while you were talking about run-time libraries.

Similarly, the second block has a whole slew off /ffp/lib and /ffp/libexec files.

If that is the basis of my misunderstanding then all is good.

puterboy wrote:

In a future release, one could take this idea a step further by converting fun_plug.tgz into a "super" tar file consisting of the following
   fun_plug-base.tgz (consisting of all the partial package files)
   less-418-3.tgz
   rcorder-cvs-4.tgz
   ... and all the other complete packages that are included in the current fun_plug.tgz

Just to clarify, the logic of this approach is that fun_plug.tgz would then be a tar file consisting solely of true packages. The first step would then be to untar the wrapper and then install the individual packages (by untarring them).

puterboy wrote:

(this is similar to what Fedora does where it often has a runtime package and a companion -lib package).

Actually, I think Fedora labels them with a -devel suffix (not -lib). Sorry