Jump to content

Talkabout

Members
  • Posts

    11
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Device is RockPI as mentioned above. Your statement means that if I create a small partition, put only the /boot folder there and then export it via "dd" to an image file, restoring that to an SD should give me the ability to boot correctly?
  2. hm..., possible but not very nice Thanks for the hint! So with Armbian the boot partition and ext4 root partition are basically the same? And the bootloader simply points to the /boot folder? Bye
  3. My requirement is a little bit different: I would like to include this "boot image creation" into my backup process as an automatic action. Maybe the solution is to - create temporary partition - copy /boot to that partition - install boot loader on this partition => this is something I do not know how to do it - create img out of this partition The problem is I am not really into the whole "boot thing" that is why I am asking for help (or maybe some howtos). is the above process the best option? Thanks!
  4. I am using RockPI. While rsyncing the file system all the folder (including /boot) are backed up, but to restore a damaged sd card currently I would need to install stock armbian and modify the boot files in order to boot from nfs root. I would like to simplify this process by creating a small "img" file that I can restore easily on sd card failure. Is there any way to do that? Thanks!
  5. these files are loaded from sd card, this is why I would like to backup them as an image file to be able to quickly restore them.
  6. Hi guys, I am currently working on backing up my armbian installation. Following situation: boot: sd card file system: nfs root backing up the file system is not an issue, there I am using a rsync logic that transfers only changed files, which works great. The problem is with the boot files. In case of sd card failure I need an image that I can quickly restore to a new sd card, without the whole file system, as it is on nfs root and backed up differently. Now my question is: what is the best way to create an image file with only the boot logic? On Raspbian this is simple, as the boot device is a fat32 partition, but on Armbian there is no separate partition I can use for that. Help is much appreciated! Thanks! Bye
  7. HI all, the issue was related to one of my network cables. After applying a different one the issue was gone. Thanks to everybody who took the time to think about it! Bye
  8. Hi guys, I recently bought a Rock PI 4 and installed Armbian Buster with kernel 5.4.6. The os is booting fine but I am facing major performance issues when trying to download from the internet. I have also a Raspberry Pi 4 connected to the same switch (via LAN) and when I execute the following command curl -L http://speedtest.belwue.net/1G > /dev/null I am getting download speed of approx 8MB/s on my Raspberry but only 2MB/s on my Rock PI 4. From connection side and rooting there is no difference. While using the same Armbian version on my Rock64 I am getting the same speed as my Raspberry Pi. Is this a known problem with the Rock PI 4 or am I missing something important? I also tried other kernel versions but the problem persists. One thing to mention: I tried the same command with a local webserver (same network, same switch) and there I was able to get download speeds of about 60MB/s, so it seems to not being an issue with the LAN port itself. Any ideas? Thanks! Bye
  9. Thank you very much, pointing to the "sndbuf/rcvbuf" values was the key. After changing those the throughput showed "normal" values again. Bye
  10. Hi guys, I have recently bought a Rock64 to improve the performance of my VPN gateway. First tests look very promising as you can see here: root@rock64:~# openssl speed -evp aes-128-cbc -elapsed You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 15394610 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 12591175 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6719021 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2448108 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 352617 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 177668 aes-128-cbc's in 3.00s OpenSSL 1.1.1d 10 Sep 2019 built on: Sat Oct 12 19:56:43 2019 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-H2OJIf/openssl-1.1.1d=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 82379.18k 268611.73k 573356.46k 835620.86k 962879.49k 970304.17k root@rock64:~# openvpn --genkey --secret /tmp/secret root@rock64:~# time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc Sat Dec 14 10:26:40 2019 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode real 0m4.978s user 0m4.945s sys 0m0.032s Unfortunately when executing a simple curl, the throughput is very low: root@rock64:~# curl -L https://speed.hetzner.de/1GB.bin > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 2 1000M 2 29.9M 0 0 2090k 0 0:08:09 0:00:14 0:07:55 3106k When using Ubuntu 18.04 Bionic I am reaching speeds of 8,4MByte/s. I have checked the openvpn process and it seems that it is only using 25% of CPU, whereas when using in Ubuntu it is using 50-60%. What are the differences here and why is Armbian limiting the process to 25%? Thanks! Bye
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines