FFP 0.7 OABI version vs EABI and slacker

[Wouter]

First of all thanks for all your hard work João. I have flashed Alt-F 0.1RC4 and I really love it and all it's possibilities. I do have some questions and issues though:

First, is there a specific reason why the OABI version of FFP 0.7 is used instead of the EABI version of FFP? The kernel seems to support the EABI/ARM toolchain so are there other reasons for using the OABI one?

I have replaced my FFP directory with the ARM version of FFP 0.7 and that seems to work just fine. The installed packages are shown correct. Only the installable packages are the old OARM versions can I change that somewhere myself? Or is there a possiblity to create an option in the WebUI to choose the ARM or the OABI version in the FFP install selection?

When I try to install some packages through slacker (both in the 0.7 OABI as the ARM version) it displays as in the attached screenshot. This makes it impossible to see which packages are displayed. I have been looking into this and saw that it may be due to using dropbear for SSH instead of bash (http://nas-tweaks.net/398/installing-and-uninstalling-packages-in-fonz-fun_plug-0-7/ see comments section and the comments of Coox). Therefore I installed the Alt-F package for bash but I don't know how to make sure that I use bash instead of dropbear for SSH. In the WebUI I had a look at the inetd setup screen and then the ssh configure options. But that only seems to refer to dropbear. Connecting through putty and then launching bash does not work unfortunately. Do you have any idea how I can fix this slacker issue? Thanks.

[João Cardoso]

On Thursday, July 31, 2014 3:34:53 PM UTC+1, Wouter wrote:

First of all thanks for all your hard work João. I have flashed Alt-F 0.1RC4 and I really love it and all it's possibilities. I do have some questions and issues though:

First, is there a specific reason why the OABI version of FFP 0.7 is used instead of the EABI version of FFP?

No. I don't follow or use ffp, I might have misread some post or instruction. Can you point me to the right fonz post about the recommended versions?
 

The kernel seems to support the EABI/ARM toolchain so are there other reasons for using the OABI one?

Yes Alt-F uses EABI and the kernel supports both.
 

I have replaced my FFP directory with the ARM version

I'm afraid that introducing another term, "ARM version", might lead to confusion. Your mean EABI?

of FFP 0.7 and that seems to work just fine. The installed packages are shown correct. Only the installable packages are the old OARM versions can I change that somewhere myself?

/usr/www/cgi-bin/ffp_packages.cgi and /usr/www/cgi-bin/ffp_packages_proc.cgi

If you change then for the correct ABI please send a patch.
 

Or is there a possiblity to create an option in the WebUI to choose the ARM or the OABI version in the FFP install selection?

It is possible, but I have enough work maintaining Alt-F...

I s any *inconvenient* using OABI? I'm thinking in people that has already ffp-0.7 installed, one has to think on the migration path problem.
 

When I try to install some packages through slacker (both in the 0.7 OABI as the ARM version) it displays as in the attached screenshot. This makes it impossible to see which packages are displayed. I have been looking into this and saw that it may be due to using dropbear for SSH instead of bash

hmmm, I would say it's a ncurses issue. I never used 0-7 neither slacker.
 

(http://nas-tweaks.net/398/installing-and-uninstalling-packages-in-fonz-fun_plug-0-7/ see comments section and the comments of Coox). Therefore I installed the Alt-F package for bash but I don't know how to make sure that I use bash instead of dropbear for SSH.

Services->Network->inetd configure->ssh/ssh_alt configure (the _alt is for ALTernative port)

The default is that openssh listen on port 2222, while dropbear listen on port 22, the default ssh port.

 

In the WebUI I had a look at the inetd setup screen and then the ssh configure options. But that only seems to refer to dropbear.

If you instal *Alt-F* openssh package more options will appear.

Connecting through putty and then launching bash does not work unfortunately. Do you have any idea how I can fix this slacker issue?

No. I noticed that also, and I remember that changing the TERM environment variable produced some differences, thus I though it was a ncurses issue. ncurses supports only a few minimum terminal types:
vt200
vt100
vt220
vt102
ansi
xterm-xfree86
xterm-color
xterm
linux

Try setting

export TERM=ansi

then try calling slaker; try it for each different terminal type supported.
I'm afraid that's all I can suggest.

 

Thanks.

[Wouter]

Thanks for your reply and you help. I will already comment/answer some of your questions inline in blue. Some other I need to dive into again.

On Friday, August 1, 2014 1:02:33 AM UTC+2, João Cardoso wrote:

On Thursday, July 31, 2014 3:34:53 PM UTC+1, Wouter wrote:

First of all thanks for all your hard work João. I have flashed Alt-F 0.1RC4 and I really love it and all it's possibilities. I do have some questions and issues though:

First, is there a specific reason why the OABI version of FFP 0.7 is used instead of the EABI version of FFP?

No. I don't follow or use ffp, I might have misread some post or instruction. Can you point me to the right fonz post about the recommended versions?

All posts from Fonz are pointing to the OABI version since the kernel of the normal firmware of the DNS323/CH3SNAS only support OABI. I used step 1 from the following post to determine if the EABI version could be used: http://forum.dsmg600.info/viewtopic.php?pid=45488

 

The kernel seems to support the EABI/ARM toolchain so are there other reasons for using the OABI one?

Yes Alt-F uses EABI and the kernel supports both.
 

I have replaced my FFP directory with the ARM version

I'm afraid that introducing another term, "ARM version", might lead to confusion. Your mean EABI?

Sorry for that, yes with the ARM version I meant EABI.

of FFP 0.7 and that seems to work just fine. The installed packages are shown correct. Only the installable packages are the old OARM versions can I change that somewhere myself?

/usr/www/cgi-bin/ffp_packages.cgi and /usr/www/cgi-bin/ffp_packages_proc.cgi

If you change then for the correct ABI please send a patch.

I will look into that, and of course if I make changes I will send you the patch.

 

Or is there a possiblity to create an option in the WebUI to choose the ARM or the OABI version in the FFP install selection?

It is possible, but I have enough work maintaining Alt-F...

Is any *inconvenient* using OABI? I'm thinking in people that has already ffp-0.7 installed, one has to think on the migration path problem.

The advantage of using the EABI version is that more recent packages are available and developed for it, since the more recent systems are supported and therefore these users with FFP are more active.
Next to that (thanks Mijzelf for explaining me this point) it is impossible to compile some important libraries (like uClibc) for OABI anymore. That is the reason why FFP 0.7 OABI uses an older uClibc than the ARM/EABI version of FFP.

 

When I try to install some packages through slacker (both in the 0.7 OABI as the ARM version) it displays as in the attached screenshot. This makes it impossible to see which packages are displayed. I have been looking into this and saw that it may be due to using dropbear for SSH instead of bash

hmmm, I would say it's a ncurses issue. I never used 0-7 neither slacker.
 

(http://nas-tweaks.net/398/installing-and-uninstalling-packages-in-fonz-fun_plug-0-7/ see comments section and the comments of Coox). Therefore I installed the Alt-F package for bash but I don't know how to make sure that I use bash instead of dropbear for SSH.

Services->Network->inetd configure->ssh/ssh_alt configure (the _alt is for ALTernative port)

The default is that openssh listen on port 2222, while dropbear listen on port 22, the default ssh port.

 

In the WebUI I had a look at the inetd setup screen and then the ssh configure options. But that only seems to refer to dropbear.

If you instal *Alt-F* openssh package more options will appear.

Did that and an extra option appears to listen for openssh on port 2222. When I login on that port it doesn't solve the issue with slacker either.

Connecting through putty and then launching bash does not work unfortunately. Do you have any idea how I can fix this slacker issue?

No. I noticed that also, and I remember that changing the TERM environment variable produced some differences, thus I though it was a ncurses issue. ncurses supports only a few minimum terminal types:
vt200
vt100
vt220
vt102
ansi
xterm-xfree86
xterm-color
xterm
linux

Try setting

export TERM=ansi

then try calling slaker; try it for each different terminal type supported.
I'm afraid that's all I can suggest.

Tried all different terminal types you named but unfortunately without success. Any other possible things I can try?

 

Thanks.

[Wouter]

Small update: I changed the login shell to bash by doing:

"chsh -s bash root" in the bash directory. Then after logging in Slacker displays normally. I can only login on port 2222 on port 22 it says password denied for root.

[João Cardoso]

On Friday, August 1, 2014 1:36:34 PM UTC+1, Wouter wrote:

Small update: I changed the login shell to bash by doing:

"chsh -s bash root" in the bash directory. Then after logging in Slacker displays normally. I can only login on port 2222 on port 22 it says password denied for root.

So you was right, it's not a ncurses but a openssh or bash issue. Still have to figure out which one.

What is the contents of /etc/shells? Is the path to bash /usr/bin/bash or /ffp/bin/bash? as "chsh" is a ffp command it might screw things.

In any case, what will happens if openssh or bash is not available? During a fsck, e.g.? or when disks are not available?  I don't think that's safe to change the root shell to some shell that might not be available.

What if you revert what you did and start bash after a normal login? either using openssh on port 2222 and dropbear on port 22?

Thanks.

[Wouter]

On Friday, August 1, 2014 4:45:59 PM UTC+2, João Cardoso wrote:

On Friday, August 1, 2014 1:36:34 PM UTC+1, Wouter wrote:

Small update: I changed the login shell to bash by doing:

"chsh -s bash root" in the bash directory. Then after logging in Slacker displays normally. I can only login on port 2222 on port 22 it says password denied for root.

So you was right, it's not a ncurses but a openssh or bash issue. Still have to figure out which one.

What is the contents of /etc/shells? Is the path to bash /usr/bin/bash or /ffp/bin/bash? as "chsh" is a ffp command it might screw things.

Contents of shells is :
/bin/sh
/usr/bin/bash

In any case, what will happens if openssh or bash is not available? During a fsck, e.g.? or when disks are not available?  I don't think that's safe to change the root shell to some shell that might not be available.

What if you revert what you did and start bash after a normal login? either using openssh on port 2222 and dropbear on port 22?

I used the instruction from http://dns323.kood.org/howto:ffp#shells. I only did the "chsh -s bash" part I did not run 'store-passwd.sh' to make the changes permanent. So I think I should be good after a reboot right? I did install the packages I wanted now so I can try again.

Thanks.

[João Cardoso]

On Friday, August 1, 2014 5:43:59 PM UTC+1, Wouter wrote:

On Friday, August 1, 2014 4:45:59 PM UTC+2, João Cardoso wrote:

On Friday, August 1, 2014 1:36:34 PM UTC+1, Wouter wrote:

Small update: I changed the login shell to bash by doing:

"chsh -s bash root" in the bash directory. Then after logging in Slacker displays normally. I can only login on port 2222 on port 22 it says password denied for root.

So you was right, it's not a ncurses but a openssh or bash issue. Still have to figure out which one.

What is the contents of /etc/shells? Is the path to bash /usr/bin/bash or /ffp/bin/bash? as "chsh" is a ffp command it might screw things.

Contents of shells is :
/bin/sh
/usr/bin/bash

That's OK...
and what is /etc/passwd root's shell entry?

root:x:0:0:root:/root:/usr/bin/bash

or

root:x:0:0:root:/root:/ffp/usr/bin/bash
 
I just edited mine to be /usr/bin/bash and could login as root using dropbear.

Again, I don't recommend changing root login shell to something other than /bin/sh, as it that might not be available on the system under certain circumstances , as you will not be able to login as root.

In any case, what will happens if openssh or bash is not available? During a fsck, e.g.? or when disks are not available?  I don't think that's safe to change the root shell to some shell that might not be available.

What if you revert what you did and start bash after a normal login? either using openssh on port 2222 and dropbear on port 22?

I used the instruction from http://dns323.kood.org/howto:ffp#shells. I only did the "chsh -s bash" part I did not run 'store-passwd.sh'

Don't do that (I mean, don't use store-passwd.sh). It is probably useless and probably dangerous as well.
Alt-F has its own method of storing configuration files on flash memory, use 'loadsave_settings' on its own to see its usage.
 

to make the changes permanent. So I think I should be good after a reboot right? I did install the packages I wanted now so I can try again.

Remember to not activate ffp services that might conflict with Alt-F services. It would be a mess.

As a last resort you have the recessed back reset button pressed for more than 10 and less than 20 seconds (make it 15), read the About leds and buttons wiki, recovery actions.
 

Thanks.

[Wouter]

Unfortunately I already rebooted and what you predicted happened. By setting it back to the sh shell I am unable to log into the box through shell anymore. Resetting the password of the webinterface does not help so I think I need to reset the box. Not really a problem since I like fiddling around with it. But therefore I could not check the contents of: /etc/passwd root's shell entry

Op vrijdag 1 augustus 2014 20:43:14 UTC+2 schreef João Cardoso:

On Friday, August 1, 2014 5:43:59 PM UTC+1, Wouter wrote:

On Friday, August 1, 2014 4:45:59 PM UTC+2, João Cardoso wrote:

On Friday, August 1, 2014 1:36:34 PM UTC+1, Wouter wrote:

Small update: I changed the login shell to bash by doing:

"chsh -s bash root" in the bash directory. Then after logging in Slacker displays normally. I can only login on port 2222 on port 22 it says password denied for root.

So you was right, it's not a ncurses but a openssh or bash issue. Still have to figure out which one.

What is the contents of /etc/shells? Is the path to bash /usr/bin/bash or /ffp/bin/bash? as "chsh" is a ffp command it might screw things.

Contents of shells is :
/bin/sh
/usr/bin/bash

That's OK...
and what is /etc/passwd root's shell entry?

root:x:0:0:root:/root:/usr/bin/bash

or

root:x:0:0:root:/root:/ffp/usr/bin/bash
 
I just edited mine to be /usr/bin/bash and could login as root using dropbear.

Again, I don't recommend changing root login shell to something other than /bin/sh, as it that might not be available on the system under certain circumstances , as you will not be able to login as root.

In any case, what will happens if openssh or bash is not available? During a fsck, e.g.? or when disks are not available?  I don't think that's safe to change the root shell to some shell that might not be available.

What if you revert what you did and start bash after a normal login? either using openssh on port 2222 and dropbear on port 22?

I used the instruction from http://dns323.kood.org/howto:ffp#shells. I only did the "chsh -s bash" part I did not run 'store-passwd.sh'

Don't do that (I mean, don't use store-passwd.sh). It is probably useless and probably dangerous as well.
Alt-F has its own method of storing configuration files on flash memory, use 'loadsave_settings' on its own to see its usage.
 

to make the changes permanent. So I think I should be good after a reboot right? I did install the packages I wanted now so I can try again.

Remember to not activate ffp services that might conflict with Alt-F services. It would be a mess.

As a last resort you have the recessed back reset button pressed for more than 10 and less than 20 seconds (make it 15), read the About leds and buttons wiki, recovery actions.
 

Thanks.

[João Cardoso]

On Saturday, August 2, 2014 12:25:55 PM UTC+1, Wouter wrote:

Unfortunately I already rebooted and what you predicted happened. By setting it back to the sh shell I am unable to log into the box through shell anymore. Resetting the password of the webinterface does not help so I think I need to reset the box.

Have you tried the soft recovery method depicted in the leds/button wiki?
 

Not really a problem since I like fiddling around with it. But therefore I could not check the contents of: /etc/passwd root's shell entry

But after recovering you can try to reproduce the issue (without rebooting). I would like to know if the slacker issue comes from bash or dropbear. From your previous experiences we already know that ncurses is not the culprit.

PS: be sure that you have /ffp at your PATH end, not beginning!

Thanks

[Wouter]

First attached are the two files for the webinterfaces edited for installing the 0.7 ARM (EABI) version. I have tested it by changing it in the files in flash memory with VI and afterwards installing from the webinterface. This gave no issues, also installing and uninstalling the php package gave no errors. As I said earlier for a clean install the 0.7 ARM (EABI) version is more efficient and there are much more packages and support for it. For your questions below see inline.

Op zaterdag 2 augustus 2014 16:02:37 UTC+2 schreef João Cardoso:

On Saturday, August 2, 2014 12:25:55 PM UTC+1, Wouter wrote:

Unfortunately I already rebooted and what you predicted happened. By setting it back to the sh shell I am unable to log into the box through shell anymore. Resetting the password of the webinterface does not help so I think I need to reset the box.

Have you tried the soft recovery method depicted in the leds/button wiki?

Yes tried that but when I restarted afterwards the webui started in the wizard so I went through that again. Second time it works now and I can login through telnet. Not anymore through ssh both dropbear and openssh give wrong password. When I changed the passwd file I got it working again.

 

Not really a problem since I like fiddling around with it. But therefore I could not check the contents of: /etc/passwd root's shell entry

But after recovering you can try to reproduce the issue (without rebooting). I would like to know if the slacker issue comes from bash or dropbear. From your previous experiences we already know that ncurses is not the culprit.

Finally I was able to figure it out. I think it has to do with the ffp version of bash.

When I set my shell to /mnt/sda2/ffp/bin/bash I am only able to log in using openssh. Dropbear gives access denied. When I update slacker with slacker -U and then display with slacker -a it works like it should.

In passwd the first line then says:
root:x:0:0:root:/root:/mnt/sda2/ffp/bin/bash (sda2 is where I have my FFP dir)

When I change shells to the normal bash (/usr/bin/bash) I can login on both dropbear and openssh. If I then directly do "slacker -a" it displays the packages in a readable way but different (more ugly) from when using the ffp/bash. But when I do slacker -U (Update package list) and then slacker -a (list all available packages) it is unreadable again using the alt-f bash. So I think it has to do with the way that the file is stored in combination with the bash version. When you do slacker -U it does/displays the following: 
Updating package lists...
fetch: rsync -q 'rsync://ffp.inreto.de/ffp/0.7/arm/packages/CHECKSUMS.md5' '/ffp/funpkg/cache/s'

Any ideas to get this working in a save and correct way? Thanks again.







 



 

[João Cardoso]

On Sunday, August 3, 2014 3:40:20 PM UTC+1, Wouter wrote:

First attached are the two files for the webinterfaces edited for installing the 0.7 ARM (EABI) version. I have tested it by changing it in the files in flash memory with VI and afterwards installing from the webinterface. This gave no issues, also installing and uninstalling the php package gave no errors.

Thanks, I will take a look at it (the best way for me to not forget it is for you to open a bug report at sourceforge tickets attaching the files -- can you please do also that? I would appreciate)

What will happens to current users with OABI?
What would you advise then to do?
Will an upgrade (overwriting) work? (will configuration files be lost?)
How can the ABI be detected on an already installed ffp, so as we can detect it and at least warn the user?
 

As I said earlier for a clean install the 0.7 ARM (EABI) version is more efficient and there are much more packages and support for it. For your questions below see inline.

Op zaterdag 2 augustus 2014 16:02:37 UTC+2 schreef João Cardoso:

On Saturday, August 2, 2014 12:25:55 PM UTC+1, Wouter wrote:

Unfortunately I already rebooted and what you predicted happened. By setting it back to the sh shell I am unable to log into the box through shell anymore. Resetting the password of the webinterface does not help so I think I need to reset the box.

Have you tried the soft recovery method depicted in the leds/button wiki?

Yes tried that but when I restarted afterwards the webui started in the wizard

It was not the "soft" recovery -- that just opens a password-less root telnet session on port 26. The more "harder" recovery clear all flash-saved settings and reboot, so the first login tour will run again.
 

so I went through that again. Second time it works now and I can login through telnet. Not anymore through ssh both dropbear and openssh give wrong password. When I changed the passwd file I got it working again.

 

Not really a problem since I like fiddling around with it. But therefore I could not check the contents of: /etc/passwd root's shell entry

But after recovering you can try to reproduce the issue (without rebooting). I would like to know if the slacker issue comes from bash or dropbear. From your previous experiences we already know that ncurses is not the culprit.

Finally I was able to figure it out. I think it has to do with the ffp version of bash.

When I set my shell to /mnt/sda2/ffp/bin/bash I am only able to log in using openssh. Dropbear gives access denied.

Have you added ffp bash path to /etc/shells?
What is the ownership of ffp bash? root:root?

 

When I update slacker with slacker -U and then display with slacker -a it works like it should.

What does the TERM variable says? echo $TERM?
 

In passwd the first line then says:
root:x:0:0:root:/root:/mnt/sda2/ffp/bin/bash (sda2 is where I have my FFP dir)

When I change shells to the normal bash (/usr/bin/bash) I can login on both dropbear and openssh.

Yes, the issue is /etc/shells.

If I then directly do "slacker -a" it displays the packages in a readable way but different (more ugly) from when using the ffp/bash.

most probably a different TERM, or at least a more complete terminal capabilities description is available when running under ffp. This is related to ncurses.
 

But when I do slacker -U (Update package list) and then slacker -a (list all available packages) it is unreadable again using the alt-f bash. So I think it has to do with the way that the file is stored in combination with the bash version. When you do slacker -U it does/displays the following: 
Updating package lists...
fetch: rsync -q 'rsync://ffp.inreto.de/ffp/0.7/arm/packages/CHECKSUMS.md5' '/ffp/funpkg/cache/s'

Any ideas to get this working in a save and correct way?

Well, the "correct" way is to not play with login shells, /etc/password, etc. Instead, do a normal dropbear/openssh login using /bin/sh, and then run a transitional script to work under ffp.

After login using ffp bash, where slacker runs OK, take a note of the TERM variable.
Then revert configuration to the normal /bin/sh, login again, do

export TERM=<the same term that worked before>
exec /ffp/bin/bash

this should put you almost in the same situation as a login straight to /ffp/bin/bash
By default ffp is set latter in PATH, so you might also need to put it ahead:

[root@DNS-323]# echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin:/ffp/bin:/ffp/sbin

[root@DNS-323]# export PATH=/ffp/bin:/ffp/sbin:/bin:/sbin:/usr/bin:/usr/sbin

[Wouter]

On Sunday, August 3, 2014 11:19:14 PM UTC+2, João Cardoso wrote:

On Sunday, August 3, 2014 3:40:20 PM UTC+1, Wouter wrote:

First attached are the two files for the webinterfaces edited for installing the 0.7 ARM (EABI) version. I have tested it by changing it in the files in flash memory with VI and afterwards installing from the webinterface. This gave no issues, also installing and uninstalling the php package gave no errors.

Thanks, I will take a look at it (the best way for me to not forget it is for you to open a bug report at sourceforge tickets attaching the files -- can you please do also that? I would appreciate)

Ok created a ticket in the bug report section with the files and the different version files.

What will happens to current users with OABI?

 I only changed the source that is used for the install and the source for the packages. So the rest of the install is the same as your previous files. If a folder with FFP is already found you do not get the option to install it. If it is OABI 0.7 you don't get the option to upgrade.

What would you advise then to do?

I would advise all users to go with the ARM version because more development and support on packages is done for that more current version.

Will an upgrade (overwriting) work? (will configuration files be lost?)

That is the same as with the other ffp versions.

How can the ABI be detected on an already installed ffp, so as we can detect it and at least warn the user?

Yes this can be found in the ffp-version file. I attached the three different ones to the bug report. There are two values: FFP_VERSION and FFP_ARCH. FFP version is 0.7.1 for OABI. For OARM and ARM it is 0.7.0. FFP_ARCH is oarm for oarm and oabi and is arm for arm. So with these two values you can define which version is used.

As I said earlier for a clean install the 0.7 ARM (EABI) version is more efficient and there are much more packages and support for it. For your questions below see inline.

Op zaterdag 2 augustus 2014 16:02:37 UTC+2 schreef João Cardoso:

On Saturday, August 2, 2014 12:25:55 PM UTC+1, Wouter wrote:

Unfortunately I already rebooted and what you predicted happened. By setting it back to the sh shell I am unable to log into the box through shell anymore. Resetting the password of the webinterface does not help so I think I need to reset the box.

Have you tried the soft recovery method depicted in the leds/button wiki?

Yes tried that but when I restarted afterwards the webui started in the wizard

It was not the "soft" recovery -- that just opens a password-less root telnet session on port 26. The more "harder" recovery clear all flash-saved settings and reboot, so the first login tour will run again.
 

so I went through that again. Second time it works now and I can login through telnet. Not anymore through ssh both dropbear and openssh give wrong password. When I changed the passwd file I got it working again.

 

Not really a problem since I like fiddling around with it. But therefore I could not check the contents of: /etc/passwd root's shell entry

But after recovering you can try to reproduce the issue (without rebooting). I would like to know if the slacker issue comes from bash or dropbear. From your previous experiences we already know that ncurses is not the culprit.

Finally I was able to figure it out. I think it has to do with the ffp version of bash.

When I set my shell to /mnt/sda2/ffp/bin/bash I am only able to log in using openssh. Dropbear gives access denied.

Have you added ffp bash path to /etc/shells?

No I did not do that.

What is the ownership of ffp bash? root:root?

Yes ownership of ffp bash is  root:root

 

When I update slacker with slacker -U and then display with slacker -a it works like it should.

What does the TERM variable says? echo $TERM?

TERM variable is linux

 

In passwd the first line then says:
root:x:0:0:root:/root:/mnt/sda2/ffp/bin/bash (sda2 is where I have my FFP dir)

When I change shells to the normal bash (/usr/bin/bash) I can login on both dropbear and openssh.

Yes, the issue is /etc/shells.

If I then directly do "slacker -a" it displays the packages in a readable way but different (more ugly) from when using the ffp/bash.

most probably a different TERM, or at least a more complete terminal capabilities description is available when running under ffp. This is related to ncurses.
 

But when I do slacker -U (Update package list) and then slacker -a (list all available packages) it is unreadable again using the alt-f bash. So I think it has to do with the way that the file is stored in combination with the bash version. When you do slacker -U it does/displays the following: 
Updating package lists...
fetch: rsync -q 'rsync://ffp.inreto.de/ffp/0.7/arm/packages/CHECKSUMS.md5' '/ffp/funpkg/cache/s'

Any ideas to get this working in a save and correct way?

Well, the "correct" way is to not play with login shells, /etc/password, etc. Instead, do a normal dropbear/openssh login using /bin/sh, and then run a transitional script to work under ffp.

After login using ffp bash, where slacker runs OK, take a note of the TERM variable.
Then revert configuration to the normal /bin/sh, login again, do

export TERM=<the same term that worked before>
exec /ffp/bin/bash

this should put you almost in the same situation as a login straight to /ffp/bin/bash
By default ffp is set latter in PATH, so you might also need to put it ahead:

[root@DNS-323]# echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin:/ffp/bin:/ffp/sbin

[root@DNS-323]# export PATH=/ffp/bin:/ffp/sbin:/bin:/sbin:/usr/bin:/usr/sbin

Ok that works now. So the solution is the following:

1. login on normal dropbear or openssh
2. exec /ffp/bin/bash
3. PATH=/ffp/sbin:/usr/sbin:/sbin:/ffp/bin:/usr/bin:/bin
4. slacker -U
5. slacker -a

And it now seems to work like it should. Thanks this one can be closed and I will add a small description in the FAQ on sourceforge on this.