infinity

As far as I understood it, the script is responsible to get the Trim feature working on the OS. But the usb3.1 to SATA converter itself got the TRIM feature thanks to the firmware update. In my opinion it's the most important that the hardware itself (the cable) supports TRIM in the first place. The other thing is the OS, which is not the responsibility of the USB2SATA adaptor. I mean... the OS issue counts for all the cables and JMS578 as well as all the ASM1351. But if the cable won't ever support it, because the manufacturer does decide not to provide a respective firmware (with trim support enabled), then the best OS cannot change anything about this fact. So apparently JMS578 and ASM1351 are good choices. I will give the ASM1351 a shot, as the benchmarks are quite encouraging. Without this script, JMS578 wouldn't have working TRIM either, or not?

Yep, I agree that it actually might make no noticable difference. Though I'd like to maximize the chances to have a good setup. Found this blog here: http://salutepc.altervista.org/ssd-on-usb-3-0-3-1-with-trim-support-windows-linux.html He has almost the same setup as I have (or would like to have): - Samsung 850 EVO - StarTech.com USB312SAT3CB - Windows and probably Ubuntu based Rock64 System He also confirms working Trim and the numbers seem quite solid. So I think that startech thingy looks like a solid choice

Wow, thanks for both hints! Real crap, that they advertise it wrongly as JMS578 based. After doing some research I think I will give the Startech USB312SAT3CB a shot. It is based on a ASM1351 USB3.1 Gen2 controller, which (as some other little reviews show) apparently performs better than JMS578 and it has firmware support as well as Trim support added by a Startech firmware. It's a bit more expensive, but I think I can give it a try and see whether it is okay or not. Perhaps I'll make another order of the ROCK64, then I can directly add their JMS578 based USB3toSATA converter to have it as well.

Thank you very much once again @tkaiser! I'm a bit disappointed by the high consumption and simply hoped that there are alternatives. Sure the additional SATA 3.0 PHY is present and need its power to function, thogh usually an SSD does consume less than 50mW in idle, where I expect an SATA PHY to be present as well on the SSD motherboard. Anyway, your hint about the possibility to upgrade firmware etc. is a real advantage in favour of JMS chips. Any pros and cons for JMS567 vs JMS578 ? I assume I would do nothing wrong bying one like this: ORICO Adapter USB 3.0 zu SATA, USB 3.0 Konverter Kabel für SATA III 2.5 Zoll Festplatte HDD und SSD (claiming to be JMS578 based) By the way: Found this mini review, where the ASMedia chips seem to be way better performance wise: https://superuser.com/questions/1059492/usb3-to-sata-adapter-performance EDIT Apparently ASM1351 does a huge leap in random write performance compared to the others. Perhaps I should go for it and look how it is. I assume UASP is supported by recent/relevant Linux kernels for ASM1351? Would be interesting to see how it performs on a ROCK64 with current 4.4.77 ARMBian nightly.

This is a great review! Quite helpful for me, as I have kind of the same usecase in my mind. The JMS578 power consumption is quite a showstopper. Do you happen to know whether asm1153e or asm1351 may be good alternatives? Looks like these chips do support UASP as well. Perhaps the power consumption would be lower on those? Or does anybody know whether other issues (like missing drivers; no hdparm support etc) might affect the suitability of the ASMedia chips as small USB3 NAS/backup-device usecase?

Thanks @Xaliusand @TonyMac32 @Xalius Speaking about the odroid Adaptor. I read that the rock64 eMMC may be compatible to Odroids eMMC, but cannot find any definitive proof. Now you mention it as well, so may I ask which odroid you refer to? There are, as far as I know, at least two different Odroid eMMCs specifications: one line-up works only with the odroid Cy models (info mentioned on product page). And the other only with Odroid Xy and Uy models. May I ask which odroid you own?

I wonder how you guys write to eMMC. Is it shipped with an eMMC-to-MicrsoSD adaptor, like the Hardkernel eMMCs? Also I'd like to know whether the board has a heatsink mounted? SOC wise it is comparable to Odroid C2, but all the pictures of ROCK64 are without heatsink, although the SOC is apparently running at 1.5GHz, just like the Odroid C2. Is it perhaps a shrunk process node, thus dissipating less heat (than Odroid C2)?

@tkaiser Damn, thats really impressive! This thingy looks like it is going to bring load of fun for little NAS and server applications. Obviosly not comparable to Synology or similar, but it's also not meant to compete with such devices. Great great, thanks for these tests! It's a shame that pine64 is the only distributor, hence it won't push into the market like Rapsberry and Odroid C2 (in case that LibreELEC support vor ROCK64 will ever come to a usable stage). On the other hand... ROCK64 board seems to initiate software development as a pioneer, so many other manufacturers may come with RK3328 boards then. Just like Odroid C2 started the S905/S905x/S912 boom.

Seeing these USB benchmarks: Is anything known about USB3-Hub support? Since the board has only one USB3 port, It'd be interesting to know what happens if you add an USB3 Hub to connect more than one device. Also wondering what would happen with UAS support if such a hub-setup is possible.

@tkaiser Yep I understood it the way you meant it I was just too lazy to explain that I would buy the 3A for high power and also the usb2barrel adaptor that pine64 offers for being able to use any usb phone charger at home. This way i could also connect any 1A to 2A phone charger that I have at home. Thank you very much!

@tkaiser Thanks for these suggestions! So the 3A psu and an additional usb2barrel adaptor would be a good choice. EDIT I'm just concerned a bit about the quality of the usb2barrel adaptor cable that pine64 sells. In terms of awg standard. I'd perhaps need somewhen to extend it to 2m, which most probably wouldn't work then.

Hi there, since the pre-order is open now, I'm wondering whether somebody has already had a look at the power consumption? I'm asking because I cannot decide between 2GB and 4GB version, since I don't know how significant the increase of power consumption might be to the 4GB version. My intention is to use the board as a seafile 24/7 miniserver with an SSD. Currently a BananaPi does this task. Any thoughts about this would be very appreciated

@tkaiserMan these numbers are absolutely awesome! Thanks for this first test to get an idea of this little piece of gold. I'm really looking forward to it to replace my current banana Pi (gigabit LAN and SATA) as my Seafile Cloud Server. Your thoughts about RAM sound sane. I guess 2GB will be enough for seafile and perhaps NAS altogether. What do you think about the capability to install armhf (instead of aarch64) software? Currently the Seafile server and some other stuff is mostly rpi2/3 compatible, which means it is armhf. I don't see any downside so far compared to aarch64. Ram usage is also lower with 32bit. I guess armhf stuff will be working on ROCK64 as well? In terms of USB3: As usb3 is specified to have a quite high capability of power supply... how would that be taken account by the ROCK64 board design? Any idea what the board might lift? I thought about bying a simple USB3toSATA bridge with UASP support and power a Crucial MX300 256GB without an external power supply (just leaving it away). Such an SSD should not consume too much, so I hope that the Rock64 USB3 port could handle it directly. Does anybody have something to say about the points I mentioned? On Topic: Somehow I totally feel you developers. You want to restrict development to worthy boards, which would also increase the quality of development for those few boards, because work is more focused. On the other hand I see boards like my old banana Pi and I really think that it would've never become what it is and as usable as it is without all your effort (which certainly started without much discussion before). From a user perspective it is a very hard topic that you discuss here. Obviously everybody in the community wants as much as possible. Unfortunately new builds/initial support matures after quite some time and then comes the breakthrough (which - sometimes - cannot be anticipated). Somehow it would also be a shame if nobody would even try to establish some initial support, thus nobody would know what the board is capable of :/. I really don't want to be in your situation to decide how this can be handled in the future. I'm just very thankful and happy that ARMBian was founded some years ago and that it became such a name in the ARM business About the ROCK64: One thing is clear: In my optinion the ROCK64 should be supported, as it combines so many good things. The interest is there, quite a few developers are working on it already, apparently. The more interesting is that two totally independent interest groups (ARMBian=Server/Cli aim and then the LibreELEC=Multimedia) show real interest and have put some effort already into it. This can push it very far and both camps can benefit one another. Really really great to see this!

Lupus! Nice!! Seems to work Well... this implicates that most are affected by this issue (if updated from Armbian <=v5.0), but most don't notice, because they didn't set up a mailer in their system. Thank you very much Lupus

Ah okay, didn't know that :/. I really don't understand much about all this linux stuff, that is why I'm so dependent on this community . Thank you very much

aaaah thanks for all the answers so there is even a program called logotate it the system . This sounds all good, so it should be enough if I do a cronjob every morning (?): /etc/cron.daily/log2ram #!/bin/sh #save logs from ramdisk to harddrive: service log2ram restart

Thank you for your explanations As I am no coder, I'm still not sure how the script actually handles the logs. I understand that the logs are going to your created ramdisk (of the ramdisk-size specified with SIZE paramter), but when are they written do SD card finally? What triggers the writing to SD-Card? A full ramdisk, or a specific time? Or is your script meant to be always holding the logs in Ramdisk, thus losing all logs after a reboot. If this is the case, what happens if your "SIZE=25M" is full with logs? Does Ram2Log delete then the oldest logs according to a rotating principle?

Hi there! Just noticed a couple of days ago that you managed to provide armbian for the Odroid C2 . As I'm pretty happy with using armbian on my banana PI, I'm glad to see that the powerful C2 also went into your hands! Mainline Kernel Support: The last couple of weeks there was apparently significant progress with mainline kernel support (Kernel 4.7 seems to be working): http://forum.odroid.com/viewtopic.php?f=135&t=22708#p152459 MMC support seems to be in testing phase: http://forum.odroid.com/viewtopic.php?f=135&t=22717#p153372 Ethernet is not throttled anymore: http://forum.odroid.com/viewtopic.php?f=135&t=22717#p154447 u-boot enhancement Another developer (Kwiboo from LibreELEC and OpenPHT projects) is working on the u-boot for Odroid C2: He has integrated power on and off via IR Remote and CEC (which makes this one of the first SBCs which is capable of this): https://github.com/hardkernel/u-boot/issues/26#issuecomment-239628530 But he also could use some help with u-boot, as powering down the 3V3 line is broken in all u-boot versions for Odroid C2: http://forum.odroid.com/viewtopic.php?f=139&t=23073#p155601 So if somebody has experience with u-boot and has the skills and willingness to contribute, you could contact kwiboo at forum.odroid.com or Git. I'm sure he'll be very thankful for any Input

Oh I thought Ram2Log from the linked post was some kind of working package. Nevermind, I can try it myself then Actually it is obviously better to not add such things by default, as everybody can choose then to use it or not. Was looking a bit around in RamLog documentation and found a report command: root@bananapi:~# more /var/log/ramlog Aug 07 06:36:23 Restarting ramlog = saving logs to hdd: [ OK ] Aug 08 06:42:36 Restarting ramlog = saving logs to hdd: [ OK ] Aug 08 16:37:30 Saving logs to hdd: [ OK ] Aug 08 16:37:30 Stopping ramlog: [ OK ] Aug 08 16:38:24 Starting ramlog-tmpfs 2.0.0: Error: /var/log is in use... [fail] Aug 08 16:38:25 The list of open files: (You need to close below daemons if you want to start/stop ramlo g manually) COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME lsusb 1537 root 1w REG 179,1 20448 2168 /var/log/armhwinfo.log Aug 08 16:38:25 Test result: ramlog cannot be started or stopped at the moment. Aug 08 17:01:38 ramlog: Cannot find shutdown flag file. [warning] Aug 08 17:01:38 Stopping ramlog: Error: ramlog is not running [fail] Aug 08 17:02:29 Starting ramlog-tmpfs 2.0.0: Error: /var/log is in use... [fail] Aug 08 17:02:30 The list of open files: (You need to close below daemons if you want to start/stop ramlo g manually) COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME lsusb 1533 root 1w REG 179,1 47278 2168 /var/log/armhwinfo.log Aug 08 17:02:30 Test result: ramlog cannot be started or stopped at the moment. Aug 09 06:53:23 Error: ramlog is not running... [fail] Aug 10 06:48:01 Error: ramlog is not running... [fail] Aug 11 06:43:18 Error: ramlog is not running... [fail] Aug 11 18:36:06 ramlog: Cannot find shutdown flag file. [warning] Aug 11 18:36:06 Stopping ramlog: Error: ramlog is not running [fail] Aug 11 18:36:47 Starting ramlog-tmpfs 2.0.0: Error: /var/log is in use... [fail] Aug 11 18:36:48 The list of open files: (You need to close below daemons if you want to start/stop ramlo g manually) COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME lsusb 1540 root 1w REG 179,1 20064 2287 /var/log/armhwinfo.log Aug 11 18:36:48 Test result: ramlog cannot be started or stopped at the moment. Aug 11 18:41:42 Error: ramlog is not running... [fail] Aug 11 18:41:49 Starting ramlog-tmpfs 2.0.0: Error: /var/log is in use... [fail] So the reason is lsusb if I'm not wrong? How come? This definitely occured the first time after the last apt-get upgrade. System is working properly besides this error message with Ramlog. Did not notice anything suspicious. root@bananapi:~# systemctl status Failed to get D-Bus connection: Unknown error -1 root@bananapi:~# systemctl --failed Failed to get D-Bus connection: Unknown error -1 root@bananapi:~# So in my case systemd is actually disabled. Strange... As I am coming from 4.81 for sure (perhaps even 5.00). I think I should set up this system from scratch with a new prebuilt image. Is there something new on the horizon to wait for? Any fundamental changes in ARMbian (e.g. like systemd on or off)

I like your tool. Could you tell a bit more about the way it works? There is a size of 40MB. Does that mean that logs are written to disk as soon as 40MB of logs are collected, or is this just the size of Ramdisk? Is it possible that Ram2Log writes the logs every day at a specific time out of this ramdisk?

Thanks for your replies So.... I know for sure it was Jessie terminal version with Vanilla Kernel (now called Jessie Server) I'm not sure which version-number exactly, but either it was v4.81 / 28.12.2015 or... v5.00 / 12.2.2016 According to my notes I setup this system on 10. February 2016, so it must have been v4.81, which I must have updated (apt-get upgrade) to v5.00 some days later. Then a month ago again and on monday the last time. Ramlog was working till monday. Actually I'm just a bit confused, no panic here on my side As I'm not a experienced Linux user I'm not sure now whether my system has systemd enabled or not. I thought it is disabled, because I had the exact same problem back in february: http://forum.armbian.com/index.php/topic/342-dbus-error-when-using-systemctl/http://forum.armbian.com/index.php/topic/342-dbus-error-when-using-systemctl/ and because Igors reply in #2 of the mentioned thread was that systemd was disabled, I was satisfied with this answer. Now I'm confused as it turns out that systemd was apparently enabled haha. My rsyslog is this: #! /bin/sh ### BEGIN INIT INFO # Provides: rsyslog # Required-Start: $remote_fs $time ramlog # Required-Stop: umountnfs $time ramlog # X-Stop-After: sendsigs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: enhanced syslogd # Description: Rsyslog is an enhanced multi-threaded syslogd. # It is quite compatible to stock sysklogd and can be # used as a drop-in replacement. ### END INIT INFO # # Author: Michael Biebl <biebl@debian.org> # # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/sbin:/usr/sbin:/bin:/usr/bin DESC="enhanced syslogd" NAME=rsyslog RSYSLOGD=rsyslogd DAEMON=/usr/sbin/rsyslogd PIDFILE=/var/run/rsyslogd.pid SCRIPTNAME=/etc/init.d/$NAME # Exit if the package is not installed [ -x "$DAEMON" ] || exit 0 # Read configuration variable file if it is present [ -r /etc/default/$NAME ] && . /etc/default/$NAME # Define LSB log_* functions. . /lib/lsb/init-functions do_start() { # Return # 0 if daemon has been started # 1 if daemon was already running # other if daemon could not be started or a failure occured start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- $RSYSLOGD_OPTIONS } do_stop() { # Return # 0 if daemon has been stopped # 1 if daemon was already stopped # other if daemon could not be stopped or a failure occurred start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --exec $DAEMON } # # Tell rsyslogd to close all open files # do_rotate() { start-stop-daemon --stop --signal HUP --quiet --pidfile $PIDFILE --exec $DAEMON } create_xconsole() { XCONSOLE=/dev/xconsole if [ "$(uname -s)" != "Linux" ]; then XCONSOLE=/run/xconsole ln -sf $XCONSOLE /dev/xconsole fi if [ ! -e $XCONSOLE ]; then mknod -m 640 $XCONSOLE p chown root:adm $XCONSOLE [ -x /sbin/restorecon ] && /sbin/restorecon $XCONSOLE fi } sendsigs_omit() { OMITDIR=/run/sendsigs.omit.d mkdir -p $OMITDIR ln -sf $PIDFILE $OMITDIR/rsyslog } case "$1" in start) log_daemon_msg "Starting $DESC" "$RSYSLOGD" create_xconsole do_start case "$?" in 0) sendsigs_omit log_end_msg 0 ;; 1) log_progress_msg "already started" log_end_msg 0 ;; *) log_end_msg 1 ;; esac ;; stop) log_daemon_msg "Stopping $DESC" "$RSYSLOGD" do_stop case "$?" in 0) log_end_msg 0 ;; 1) log_progress_msg "already stopped" log_end_msg 0 ;; *) log_end_msg 1 ;; esac ;; rotate) log_daemon_msg "Closing open files" "$RSYSLOGD" do_rotate log_end_msg $? ;; restart|force-reload) $0 stop $0 start ;; status) status_of_proc -p $PIDFILE $DAEMON $RSYSLOGD && exit 0 || exit $? ;; *) echo "Usage: $SCRIPTNAME {start|stop|rotate|restart|force-reload|status}" >&2 exit 3 ;; esac : As ramlog is mentioned there, this means that rsyslog was not modified due to an update, right? So I'm still wondering why ramlog fails since monday. Well I was actually happy you had ramlog integrated, but on the other hand I don't mind if it's not there anymore. But it is apparently installed and it worked 4 days ago for half a year, so I'm curious what might break it. Perhaps it's something serious and this is just the first symptom. Looking at the posted rsyslog it is apparently not modified, as ramlog is mentioned in there. So something else might be the reason for breaking ramlog function since monday. Does that mean that systemd is enabled now or not? I'm a bit confused (not experienced in Linux unfortunately) Clearly not the case here. This setup was never wheezy, nor did I ever make apt-get dist-upgrade. My thoughts: Perhaps everybody, who is coming from 4.81 or 5.00 originally, has this errormessage that I mentioned in my opening post, but most don't notice, because they don't have a mailer daemon installed on their system? I mean... I also wouldn't notice this if my system didn't send me this email since I installed sSMTP for fail2ban back then. I did not setup those status messages intentionally, they just came after sSMTP installation. I kind of began to like to see these daily mails, because they showed me that the server is running properly. My further questions: How can I make sure systemd is running properly? Is Ramlog still integrated / enabled in current v5.16 / 5.7.2016 release, if I make a v5.16 fresh install? Assuming I uninstall ramlog via http://forum.armbian.com/index.php/topic/342-dbus-error-when-using-systemctl/#entry8104, how bad is this for the SD-Card then? Do you have any bad experience? I mean... it's clear that sd-cards don't like frequent writes... but is this really a big issue then? Are there any plans to implement Ram2Log instead of ramlog in the future? I saw that Ram2Log is working on filesize basis (40MB I think is default there): Which value would be better for a SD-Card on ARMbian, 2MB? I can't imagine that logs can collect 40MB within 24 hours or so. If I'd leave Ram2Log at 40MB, then logs would be written within half a year or so?

I've done a apt-get upgrade on my banana PI running ARMBian. Since then I get every morning this error message via email: /etc/cron.daily/ramlog: Error: ramlog is not running... failed! run-parts: /etc/cron.daily/ramlog exited with return code 110 In release history I can't find any recent changes regarding ramlog. Whats wrong? If I invoke the cron-command manually in SSH, i get this: root@bananapi:~# /etc/init.d/ramlog restart [FAIL] Error: ramlog is not running... failed! If I do simply a start instead of restart, I get this: root@bananapi:~# /etc/init.d/ramlog start [FAIL] Starting ramlog-tmpfs 2.0Error: /var/log is in use... failed! The list of open files: (You need to close below daemons if you want to start/stop ramlog manually) COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rsyslogd 1661 root 2w REG 179,1 41119 2362 /var/log/syslog rsyslogd 1661 root 4w REG 179,1 174185 2296 /var/log/kern.log rsyslogd 1661 root 5w REG 179,1 894 3414 /var/log/debug rsyslogd 1661 root 6w REG 179,1 238312 2420 /var/log/messages rsyslogd 1661 root 7w REG 179,1 15976 2161 /var/log/daemon.log rsyslogd 1661 root 8w REG 179,1 30531 2193 /var/log/auth.log rsyslogd 1661 root 9w REG 179,1 6745 2414 /var/log/mail.log rsyslogd 1661 root 10w REG 179,1 6745 2292 /var/log/mail.info nmbd 1905 root 2w REG 179,1 407 128011 /var/log/samba/log.nmbd nmbd 1905 root 8w REG 179,1 407 128011 /var/log/samba/log.nmbd memcached 1963 memcache 1w REG 179,1 0 2331 /var/log/memcached.log memcached 1963 memcache 2w REG 179,1 0 2331 /var/log/memcached.log nginx 2056 root 2w REG 179,1 1170 256440 /var/log/nginx/error.log nginx 2056 root 4w REG 179,1 1170 256440 /var/log/nginx/error.log nginx 2056 root 5w REG 179,1 56626 256020 /var/log/nginx/seahub.access.log nginx 2056 root 6w REG 179,1 590 256058 /var/log/nginx/seahub.error.log nginx 2058 www-data 2w REG 179,1 1170 256440 /var/log/nginx/error.log nginx 2058 www-data 4w REG 179,1 1170 256440 /var/log/nginx/error.log nginx 2058 www-data 5w REG 179,1 56626 256020 /var/log/nginx/seahub.access.log nginx 2058 www-data 6w REG 179,1 590 256058 /var/log/nginx/seahub.error.log nginx 2060 www-data 2w REG 179,1 1170 256440 /var/log/nginx/error.log nginx 2060 www-data 4w REG 179,1 1170 256440 /var/log/nginx/error.log nginx 2060 www-data 5w REG 179,1 56626 256020 /var/log/nginx/seahub.access.log nginx 2060 www-data 6w REG 179,1 590 256058 /var/log/nginx/seahub.error.log fail2ban- 2338 root 5w REG 179,1 7506 2290 /var/log/fail2ban.log smbd 2343 root 2w REG 179,1 63978 128030 /var/log/samba/log.smbd smbd 2343 root 8w REG 179,1 63978 128030 /var/log/samba/log.smbd smbd 2370 root 2w REG 179,1 63978 128030 /var/log/samba/log.smbd smbd 2370 root 13w REG 179,1 63978 128030 /var/log/samba/log.smbd Test result: ramlog cannot be started or stopped at the moment. Why did this work 3 days ago before the update? Also: While checking out the forum for this issue I've seen this post from azlux http://forum.armbian.com/index.php/topic/753-where-is-ramlog/?p=13172 Could it be possible to integrate it as per default instead of ramlog into ARMbian in future releases? Another Question: Is SystemD now activated in ARMBian? Release history from v4.81 / 28.12.2015 implies it is activated. I'm confused, as Ramlog was the reason for keeping SystemD deactivated in ARMBian, right? I updated ARMBian some months ago, thus Systemd has been working on my system for some months without my notice, but ramlog worked also, so I'm a bit confused how that could work with activated systemd until last monday

For the record: This advice is absolutely awesome Thank you soooo much!! I did not know how simulating an installation was possible and was frustrated everytime when I screwed my testing system... Solving my original question: using apt-cache policy and apt-cache policy nginx showed me the current pin-priority and after adding my prefered repo I could follow whether this would be considered or not. And then I just needed to setup a corresponding preferences file: Package: * Pin: release a=unstable Pin-Priority: 400 Package: *nginx* Pin: release a=unstable Pin-Priority: 600 Package: *mariadb-server* Pin: release a=unstable Pin-Priority: 600 First part lowers the priority for the whole unstable repo. The other two sections raise priority specificly for nginx and mariadb. Of course I ran into dependency problems with mariadb-server, but thats another story. Anyways... with your -s parameter I was able to see what is going to happen, thus solving everything I needed. Thanks again zador.blood.stained

Thanks again! My Banana has also ARM v7, thatswhy I'm looking on armhf on raspbian repo . As this is fully compatible and I also made the experience that it worked better that unstable branch of debian repo, I am aware of this argument. Anyway, I will look deeper into your link, but on first sight it is nothing new compared to the stuff I tried to explain here. I think I just lack a bit of knowledge respecitvely experience to get it working. Thanks anyway