piknew

I answered you already, but you have asked the same question again... If something is not clear you have to point "what" exactly should be elaborated.

Without compiling - is there any way to compile just module? I have just "server" release. If I am abl to run the driver then the rest should not be a problem (wpa_applicant etc.). I see also a lot of discussion if sources are OK or not OK (so basically would be goo to post git URL with the most up-to-dated source which is OK). Then some part related that driver will be included in package (from apt.armbian repository). Is dis available already?

If you have it on SD then put card in SD Card reader and make an backup (by for example Win32DiskImager). If you have it on emmc then you may use script from this thread. Of course you must boot your device from SD card (it can be fresh Armbian, with pv tool installed and enabled authorization by public key). BTW. I think I will adjust my script to support also "local" image storage (not only by SSH). "local" == locally mounted file system.

Is the driver already included in 5.20? I have: root@PKBACKUP:~# lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 003: ID 148f:7601 Ralink Technology, Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@PKBACKUP:~# dmesg | tail -20 [ 6.211410] systemd[1]: Started Journal Service. [ 6.832513] rtc-ds1307 0-0068: rtc core: registered ds1307 as rtc1 [ 6.832534] rtc-ds1307 0-0068: 56 bytes nvram [ 6.832571] i2c i2c-0: new_device: Instantiated device ds1307 at 0x68 [ 7.116108] systemd-udevd[183]: starting version 215 [ 7.951116] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro [ 8.148795] Adding 131068k swap on /var/swap. Priority:-1 extents:2 across:139260k SS [ 9.686287] systemd-journald[167]: Received request to flush runtime journal from PID 1 [ 9.960815] gmac0: probed [ 9.961142] gmac0 gmac0: eth0: eth0: PHY ID 00441400 at 0 IRQ poll (gmac0-0:00) [ 14.960222] PHY: gmac0-0:00 - Link is Up - 100/Full [ 20.100021] eth0: no IPv6 routers present [ 147.996252] ehci_irq: highspeed device connect [ 148.260115] usb 2-1: new high-speed USB device number 2 using sunxi-ehci [ 829.218316] ehci_irq: highspeed device disconnect [ 829.218529] usb 2-1: USB disconnect, device number 2 [ 829.221336] ehci_irq: highspeed device connect [ 829.285464] ehci_irq: highspeed device disconnect [ 832.369997] ehci_irq: highspeed device connect [ 832.640115] usb 2-1: new high-speed USB device number 3 using sunxi-ehci root@PKBACKUP:~#

Thanks. pigz is much more efficient, it is using all cores: I have updated my script to use pigz (and pbzip2) if available (over standard gzip and bzip2). See last commit (rev.17) : https://code.online-mp.pl/svn/public/backup_block_device/trunk/

Can you please take a look at (lines 106-148) and suggest if everything is optimal (i see that in your test you are using -9 which requires a lot of cpu)? svn co https://code.online-mp.pl/svn/public/backup_block_device/trunk/backup_block_device Additional question is related to 7z - I have 7z, 7za. I noticed that sometimes you have been using 7zr. Why so? admin@PKSERVER:~$ which 7z /usr/bin/7z admin@PKSERVER:~$ which 7za /usr/bin/7za admin@PKSERVER:~$ which 7zr admin@PKSERVER:~$ ll /usr/bin/7z* -rwxr-xr-x 1 root root 40 Jun 8 18:07 /usr/bin/7za -rwxr-xr-x 1 root root 39 Jun 8 18:07 /usr/bin/7z admin@PKSERVER:~$ apt list | grep 7z WARNING: apt does not have a stable CLI interface yet. Use with caution in scripts. p7zip/stable,stable 9.20.1~dfsg.1-4.1+deb8u2 armhf p7zip-full/stable,stable,now 9.20.1~dfsg.1-4.1+deb8u2 armhf [installed] p7zip-rar/stable 9.20.1~ds.1-3 armhf admin@PKSERVER:~$ To clarify - are command lines compatible between 7z, 7za & 7zr? An it would be (please note last -so): 7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on -si -so

Can you see my first post? Because I am not trying to solve anything. I wanted to share my script to make backup of block device - maybe somebody wants to use it (which I specified in my post). Last post - I share other tool which I am using to backup NAS for many months without any problems (the purpose and way of working is totally different). Now discussion goes far far away from main topic (and I see from your posts that it started to focus on backup as general). And I have use cases for which my tools are covering in 100%: 1. Backup of block device for easy migration and /or restore 2. Backup execute on filesystem with some features which eg. rsync does not have. Again: I am not having any issues with these tools I have written and want to share to community. Of course I am glad to hear anything that may be worth to have function or even - that there is some bug . No, NTFS is destination. When you try to backup files from ext2/3/4 to NTFS you will encounter problems with eg.: NTFS streams and some other entities which are not allowed or have different meaning on each filesystem. So, I have external USB HDD (2TB) which I am using as backup device for some important data from my NAS. I didn't wanted to format it (I mean external drive) as ext2/3/4 because I can easy insert it to any Windows machine and then I will have immediate access to any of stored files. Additionally I didn't want that some system files are backed up (so this is the reason exclude options have been implemented). Additionally I would like to have some "grace period" if by coincidence user deletes file from NAS (backup tool will delete this file as well but after some grace period defined by [-c cleanup_wait]). This is short story...

Source code is here (anonymous access to browse code, I can grant rw if needed to somebody, just send PM to me): https://code.online-mp.pl/svn/public/ BTW & OT: additionally I put code of my own tool "backup". I designed and writtten it to support my requirements about backup from NAS to external drives. The process is stateful eg. sqlite is used to keep internal state of backup. I am running it for more than 1 year (3 times a day). [/share/USBDisk1/logs] # /share/MD0_DATA/backup/backup backup, version: [0.1.0], build: [Sep 13 2016 10:33:55], usage: backup [-h] - display this help message backup <options> - parameters as specified below: <-f config_file> - (required, single) - list of source <-> destination directories for synchronization <-d database_path> - (required, single) - path to database file (sqlite3) which will be used as information storage [-l log_dir] - (optional, single) - path to directory where log file will be written (default is empty = log to stdout/stderr) [-L log_level] - (optional, single) - logging level, one of: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL (default is NOTICE) [-p pid_file] - (optional, single) - path to file which will be created with process identifier of backup operation [-X exclude_dir] - (optional, multiple) - name of directory to be skipped during synchronization [-x exclude_file] - (optional, multiple) - name of file to be skipped during synchronization [-M check_meta] - (optional, single) - flag (bitmask) to specify additional checking for file comparison (1 - by mode, 2 - by owner's uid, 4 - by owner's gid; default is 0 = no check) [-c cleanup_wait] - (optional, single) - determine after how many backup sessions files or directories will be deleted from destination (default is 0 = immediate) [-T file_system] - (optional, single) - enable compatibility for specified file system (available options: NTFS) And some logs... I am executing it from NAS [/share/USBDisk1/logs] # head -30 backup.20160923.110005.13573.log 2016-09-23|11:00:11|554474|13573|NOTICE|Starting application [backup] (version: [0.1.0], build: [Sep 13 2016 10:33:55], PID = [13573]) 2016-09-23|11:00:11|554901|13573|NOTICE|Using executable [/share/MD0_DATA/backup/backup] 2016-09-23|11:00:11|555059|13573|NOTICE|Using logger level [NOTICE] (2) and logger [/share/USBDisk1/logs/backup.20160923.110005.13573.log] 2016-09-23|11:00:11|556175|13573|NOTICE|Using PID file: [/share/USBDisk1/temp/backup.pid] 2016-09-23|11:00:11|556366|13573|NOTICE|Setting up of file and directory creation mask (umask) to [000], previous umask = [022] 2016-09-23|11:00:11|570426|13573|NOTICE|Using database (v3.14.2): [/share/USBDisk1/misc/backup.dat] 2016-09-23|11:00:11|570659|13573|NOTICE|Using configuration file: [/share/USBDisk1/conf/backup.cfg] 2016-09-23|11:00:11|570859|13573|NOTICE|Using destination directory create depth level: 2 [create] 2016-09-23|11:00:11|571050|13573|NOTICE|Excluding directory name: [.upload_cache] 2016-09-23|11:00:11|571187|13573|NOTICE|Excluding directory name: [.Qsync] 2016-09-23|11:00:11|571320|13573|NOTICE|Excluding directory name: [.@__thumb] 2016-09-23|11:00:11|571452|13573|NOTICE|Excluding directory name: [@Recycle] 2016-09-23|11:00:11|571581|13573|NOTICE|Excluding file name: [Thumbs.db] 2016-09-23|11:00:11|571708|13573|NOTICE|Excluding file name: [.bash_history] 2016-09-23|11:00:11|571851|13573|NOTICE|Using check meta flag [0] (check by mode = no, check by owner's uid = no, check by owner's gid = no) 2016-09-23|11:00:11|572016|13573|NOTICE|Using clean-up wait of value: 12 [postponed clean-up] 2016-09-23|11:00:11|572158|13573|NOTICE|Using compatibility for [NTFS] file system 2016-09-23|11:00:11|572342|13573|NOTICE|Using TEMP database directory: [/share/USBDisk1/misc] 2016-09-23|11:00:11|572556|13573|NOTICE|Successfully connected to TEMP database 2016-09-23|11:00:11|573079|13573|NOTICE|Successfully connected to [/share/USBDisk1/misc/backup.dat] database 2016-09-23|11:00:21|095328|13573|NOTICE|Using session identifier [1801] 2016-09-23|11:00:21|338993|13573|NOTICE|Synchronization of [/mnt/HDA_ROOT/.config] => [/share/USBDisk1/data/backup/scheduled/etc/config] is started 2016-09-23|11:00:21|405905|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [.] 2016-09-23|11:00:21|453484|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [license] 2016-09-23|11:00:21|464243|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [license/.lc] 2016-09-23|11:00:21|485333|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [license/.gnupg] 2016-09-23|11:00:21|487405|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [license/.req] 2016-09-23|11:00:21|498122|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [.hd_info] 2016-09-23|11:00:21|521208|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [php.d] 2016-09-23|11:00:21|537634|13573|NOTICE|Scanning: BASE = [/mnt/HDA_ROOT/.config], PATH = [cloudconnector]

New version can be downloaded (please see first post). I had some issues related to 7z compression, but I guess xz will be the same (lzma). Additionally please see results of backup test for all? compression methods. I have executed tests on Orange Pi PC (100MBit ethernet): nfo.zip logs.zip Result files: root@PKSERVER:/data/temp# ll 543550200b0e340000cd* -rw-r--r-- 1 root root 15523119104 Sep 22 19:19 543550200b0e340000cd_2016-09-22_1474563274.img -rw-r--r-- 1 root root 1678 Sep 22 19:19 543550200b0e340000cd_2016-09-22_1474563274.nfo -rw-r--r-- 1 root root 1029735811 Sep 22 19:52 543550200b0e340000cd_2016-09-22_1474565396.img.gz -rw-r--r-- 1 root root 1678 Sep 22 19:52 543550200b0e340000cd_2016-09-22_1474565396.nfo -rw-r--r-- 1 root root 962251987 Sep 22 20:48 543550200b0e340000cd_2016-09-22_1474567109.img.bz2 -rw-r--r-- 1 root root 1678 Sep 22 20:48 543550200b0e340000cd_2016-09-22_1474567109.nfo I guess the best choice is still gzip. If you select none then bottleneck is speed of network. For bzip2 is is somehow acceptable, but xz... forget..., the timing was unacceptable (and I have interrupted this test). 549MiB 0:16:18 [ 746KiB/s] [====> ] 3% ETA 7:02:56

This is result of command date +%s - so... seconds since 1970-01-01 00:00:00 UTC. As I wanted to differentiate files even if I create a few backups during one day. In my case: root@PKSERVER:~# date --date='@1474302693' Mon Sep 19 18:31:33 CEST 2016 Original compressing method is gzip (deflate) - so based on the resulting file it is quite difficult to determine size of "file inside". Currently you must fully "gunzip" the archive to get size of data. I will follow tkraiser's advices and maybe modify the script to use other compressing methods. I acknowledge your point (but still I guess that fo SBCs there is too much to mention about RAIDs/LVMs etc. - if you have configuration like this then definitely you should use other, dedicated method of backup, not simple interactive script). Basically it would be quite simple to create additional .nfo file with some other details that can be gathered during the process and may be helpful when eg. mounting image file later or when trying to restore image on other block device.

For "slices and overlays" I have no experience (so you may elaborate). What I can guess that overlay file must exist on mounted rw block device (or any other rw device/network). The script has very precise purpose - create an image of unmounted block device (disk with partitions). Here is an example that loop devices with partitions will not be visible: root@PKSERVER:/data/temp/device# ll total 7696 -rw-r--r-- 1 root root 268435456 Sep 21 11:08 block_device.img root@PKSERVER:/data/temp/device# losetup -f -P block_device.img root@PKSERVER:/data/temp/device# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 115.5G 0 disk └─sda1 8:1 1 115.5G 0 part /data loop0 7:0 0 256M 0 loop └─loop0p1 259:0 0 252.9M 0 loop mmcblk0boot0 179:16 0 4M 1 disk mmcblk0boot1 179:32 0 4M 1 disk mmcblk0 179:0 0 14.6G 0 disk └─mmcblk0p1 179:1 0 14.4G 0 part / root@PKSERVER:/data/temp/device# backup_block_device.sh List of block devices: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 115.5G 0 disk └─sda1 8:1 1 115.5G 0 part /data loop0 7:0 0 256M 0 loop └─loop0p1 259:0 0 252.9M 0 loop mmcblk0boot0 179:16 0 4M 1 disk mmcblk0boot1 179:32 0 4M 1 disk mmcblk0 179:0 0 14.6G 0 disk └─mmcblk0p1 179:1 0 14.4G 0 part / No devices available! root@PKSERVER:/data/temp/device# fdisk -lu /dev/loop0 Disk /dev/loop0: 256 MiB, 268435456 bytes, 524288 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x66d10c8d Device Boot Start End Sectors Size Id Type /dev/loop0p1 2048 520000 517953 252.9M 83 Linux root@PKSERVER:/data/temp/device#

1. right. But I think it is quite simply to use. I guess additional README file shall be enough... 2. right. But I guess when you backup block device then you know what are you doing. However, script for restore would be quite good here (see also point 4). 3. hmm, maybe like this? File "1435503102ce64000028_2016-09-19_1474302693.img.gz" is my backup which I have created last time. root@PKSERVER:/data/backup-image# (gunzip -c 1435503102ce64000028_2016-09-19_1474302693.img.gz 2>/dev/null | dd bs=512 skip=0 count=1 of=temp) && fdisk -lu temp && rm temp 1+0 records in 1+0 records out 512 bytes (512 copied, 0.00436383 s, 117 kB/s Disk temp: 512 B, 512 bytes, 1 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x576a94d9 Device Boot Start End Sectors Size Id Type temp1 2048 30230303 30228256 14.4G 83 Linux root@PKSERVER:/data/backup-image# 4. actually it is very easy. The same - ssh, gunzip and dd with pipe...

I guess it is not so compatible? admin@PKSERVER:~$ ssh -c arcfour localhost no matching cipher found: client arcfour server aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com admin@PKSERVER:~$ I think it would be better to leave "negotiation" (some algorithms should match).

Hi, if anybody would like to use - please see attached script for backup of block devices. I used it when executing backup for topics: http://forum.armbian.com/index.php/topic/2073-orange-pi-plus-2e-upgrade-to-520/and http://forum.armbian.com/index.php/topic/1681-migrate-from-orange-pi-plus-2-to-orange-pi-plus-2e/ Requirement: dd, gzip, ssh client (I guess they should be available by default on every system) lsblk, mount (should be available on every system) pv tool; you may install it "apt-get install pv" Script is identifying list of available block devices. The condition is that it should be block device with at least one partition and it cannot be mounted at the moment of script execution. When user chooses block device to backup then script will ask for some parameters of receiving system (please notice, that you may leave defaults or enter own. Defaults (if needed can be changed in related conf file). So, script is getting stream of data by dd, then passing to pv tool to display progress, then pipe to gzip and pipe to ssh session as specified by parameters. Remark: even if ssh is used to transfer stream of data there is NO SECURITY related to it. Because of options: -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null I am wondering that maybe this one in unnecessary (I haven't tested it, tests have been execute only with private/public key authentication). -o PasswordAuthentication=no The default name of archive contains date and processor serial id or hostname if previous is not available. I have tested this script only or Orange Pi Plus 2, Orange Pi PC and Orange Pi Plus 2E. Please feel free to use it. backup_block_device.tar.gz V1 - initial version. backup_block_device-v1.tar.gz V2: Added choice of compression methods: none, gzip, bzip2, xz NFO file is created together with image. backup_block_device-v2.tar.gz Script is also available here: https://code.online-mp.pl/svn/public/backup_block_device/trunk/

I see that you have duplicated package: ii linux-u-boot-orangepiplus-default 5.20 armhf Uboot loader 2016.09 ii linux-u-boot-orangepiplus2e-default 5.20 armhf Uboot loader 2016.09 Why you have orangepiplus2e if you are using orangepiplus? My platform is orangepiplus2e but I originally used orangepiplus packages. In this topic tkaiser suggested me to: install correct packages and then remove invalid ones. I changed the order (pls see posts above). But I do not know what may be the result of "install" then "remove" (maybe there is some kind of conflict resulting in segmentation fault?)... BTW. State of packages on my orangepiplus2e is as following: admin@PKSERVER:~$ dpkg -l | egrep "armbian| linux-" ii armbian-hostapd 5.14 armhf Patched hostapd ii armbian-tools 5.14 armhf Armbian tools, sunxi, temper ii linux-firmware-image-sun8i 5.20 armhf Linux kernel firmware, version 3.4.112-sun8i ii linux-headers-sun8i 5.20 armhf Linux kernel headers for 3.4.112-sun8i on armhf ii linux-image-sun8i 5.20 armhf Linux kernel, version 3.4.112-sun8i ii linux-jessie-root-orangepiplus2e 5.20 armhf Armbian tweaks for jessie on orangepiplus2e (default branch) ii linux-libc-dev:armhf 3.16.36-1+deb8u1 armhf Linux support headers for userspace development ii linux-u-boot-orangepiplus2e-default 5.20 armhf Uboot loader 2016.09

Thanks. My problem with connecting to device was related to ISP... I did (first purge, then install): root@PKSERVER:~# apt-get purge linux-u-boot-orangepiplus-default linux-jessie-root-orangepiplus Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: linux-jessie-root-orangepiplus* linux-u-boot-orangepiplus-default* 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. After this operation, 2,048 B disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 64831 files and directories currently installed.) Removing linux-jessie-root-orangepiplus (5.20) ... Purging configuration files for linux-jessie-root-orangepiplus (5.20) ... dpkg: warning: while removing linux-jessie-root-orangepiplus, directory '/usr/lib/nand-sata-install' not empty so not removed dpkg: warning: while removing linux-jessie-root-orangepiplus, directory '/usr/local/bin' not empty so not removed Removing linux-u-boot-orangepiplus-default (5.20) ... Processing triggers for initramfs-tools (0.120+deb8u2) ... update-initramfs: Generating /boot/initrd.img-3.4.112-sun8i Processing triggers for systemd (215-17+deb8u5) ... root@PKSERVER:~# apt-get install linux-u-boot-orangepiplus2e-default linux-jessie-root-orangepiplus2e Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: linux-jessie-root-orangepiplus2e linux-u-boot-orangepiplus2e-default 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 514 kB of archives. After this operation, 2,048 B of additional disk space will be used. WARNING: The following packages cannot be authenticated! linux-jessie-root-orangepiplus2e linux-u-boot-orangepiplus2e-default Install these packages without verification? [y/N] y Get:1 http://apt.armbian.com/ jessie/main linux-jessie-root-orangepiplus2e armhf 5.20 [357 kB] Get:2 http://apt.armbian.com/ jessie/main linux-u-boot-orangepiplus2e-default armhf 5.20 [156 kB] Fetched 514 kB in 0s (649 kB/s) Selecting previously unselected package linux-jessie-root-orangepiplus2e. (Reading database ... 64743 files and directories currently installed.) Preparing to unpack .../linux-jessie-root-orangepiplus2e_5.20_armhf.deb ... Unpacking linux-jessie-root-orangepiplus2e (5.20) ... Selecting previously unselected package linux-u-boot-orangepiplus2e-default. Preparing to unpack .../linux-u-boot-orangepiplus2e-default_5.20_armhf.deb ... Unpacking linux-u-boot-orangepiplus2e-default (5.20) ... Processing triggers for initramfs-tools (0.120+deb8u2) ... update-initramfs: Generating /boot/initrd.img-3.4.112-sun8i Processing triggers for systemd (215-17+deb8u5) ... Setting up linux-jessie-root-orangepiplus2e (5.20) ... Setting up linux-u-boot-orangepiplus2e-default (5.20) ... Processing triggers for initramfs-tools (0.120+deb8u2) ... update-initramfs: Generating /boot/initrd.img-3.4.112-sun8i root@PKSERVER:~# head /etc/armbian.txt -------------------------------------------------------------------------------- Title: Armbian 5.20 Orangepiplus2e Debian jessie default Kernel: Linux 3.4.112 Build date: 15.09.2016 Authors: http://www.armbian.com/authors Sources: http://github.com/igorpecovnik/lib Support: http://forum.armbian.com/ Changelog: http://www.armbian.com/logbook/ Documantation: http://docs.armbian.com/ -------------------------------------------------------------------------------- root@PKSERVER:~# head /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=orangepiplus2e BOARD_NAME="Orange Pi+ 2E" VERSION=5.20 LINUXFAMILY=sun8i BRANCH=default ARCH=arm root@PKSERVER:~# It seems to be OK. Thanks.

Hmm, just a few minutes ago my OPI+2E stopped responding (my opened session has frozen, new cannot be established)... So, I will be able to execute as above when I return from work and reset device "by hand" Just a question - I should use "remove" as you have suggested? Or can be "purge" (in case there is any config file which I do not want to be left as residual)? For procedure of backup I have dedicated SD card with my script to make backup over the network to NAS.

admin@PKSERVER:~$ dpkg -l | egrep "armbian| linux-" ii armbian-hostapd 5.14 armhf Patched hostapd ii armbian-tools 5.14 armhf Armbian tools, sunxi, temper ii linux-firmware-image-sun8i 5.20 armhf Linux kernel firmware, version 3.4.112-sun8i ii linux-headers-sun8i 5.20 armhf Linux kernel headers for 3.4.112-sun8i on armhf ii linux-image-sun8i 5.20 armhf Linux kernel, version 3.4.112-sun8i ii linux-jessie-root-orangepiplus 5.20 armhf Armbian tweaks for jessie on orangepiplus (default branch) ii linux-libc-dev:armhf 3.16.36-1+deb8u1 armhf Linux support headers for userspace development ii linux-u-boot-orangepiplus-default 5.20 armhf Uboot loader 2016.09 admin@PKSERVER:~$ /var/log/armhwinfo.log is uploaded to: http://sprunge.us/LJBP BTW. I edited post above and attached armhwinfo.log before and after upgrade.

Hi, I just want to inform that probably there is a problem with correct detection of platform. Originally I had everything set for Orange Pi Plus 2E. However, after upgrade avery file is related to Orange Plus (2) - not 2E: Previously in any mentioned file there was orangepiplus2e identifier. Please see also dpkg.log: 2016-09-19 11:00:20 startup archives unpack 2016-09-19 11:00:21 upgrade linux-firmware-image-sun8i:armhf 5.16 5.20 2016-09-19 11:00:21 status half-configured linux-firmware-image-sun8i:armhf 5.16 2016-09-19 11:00:21 status unpacked linux-firmware-image-sun8i:armhf 5.16 2016-09-19 11:00:21 status half-installed linux-firmware-image-sun8i:armhf 5.16 2016-09-19 11:00:21 status half-installed linux-firmware-image-sun8i:armhf 5.16 2016-09-19 11:00:21 status unpacked linux-firmware-image-sun8i:armhf 5.20 2016-09-19 11:00:21 status unpacked linux-firmware-image-sun8i:armhf 5.20 2016-09-19 11:00:21 upgrade linux-headers-sun8i:armhf 5.16 5.20 2016-09-19 11:00:21 status half-configured linux-headers-sun8i:armhf 5.16 2016-09-19 11:00:21 status unpacked linux-headers-sun8i:armhf 5.16 2016-09-19 11:00:21 status half-installed linux-headers-sun8i:armhf 5.16 2016-09-19 11:00:37 status half-installed linux-headers-sun8i:armhf 5.16 2016-09-19 11:00:37 status unpacked linux-headers-sun8i:armhf 5.20 2016-09-19 11:00:38 status unpacked linux-headers-sun8i:armhf 5.20 2016-09-19 11:00:42 upgrade linux-image-sun8i:armhf 5.16 5.20 2016-09-19 11:00:42 status half-configured linux-image-sun8i:armhf 5.16 2016-09-19 11:00:42 status unpacked linux-image-sun8i:armhf 5.16 2016-09-19 11:00:42 status half-installed linux-image-sun8i:armhf 5.16 2016-09-19 11:00:59 status half-installed linux-image-sun8i:armhf 5.16 2016-09-19 11:01:00 status unpacked linux-image-sun8i:armhf 5.20 2016-09-19 11:01:00 status unpacked linux-image-sun8i:armhf 5.20 2016-09-19 11:01:00 upgrade linux-jessie-root-orangepiplus:armhf 5.16 5.20 2016-09-19 11:01:00 status triggers-pending initramfs-tools:all 0.120+deb8u2 2016-09-19 11:01:00 status triggers-awaited linux-jessie-root-orangepiplus:armhf 5.16 2016-09-19 11:01:00 status half-configured linux-jessie-root-orangepiplus:armhf 5.16 2016-09-19 11:01:00 status unpacked linux-jessie-root-orangepiplus:armhf 5.16 2016-09-19 11:01:00 status half-installed linux-jessie-root-orangepiplus:armhf 5.16 2016-09-19 11:01:00 status triggers-pending systemd:armhf 215-17+deb8u5 2016-09-19 11:01:01 status half-installed linux-jessie-root-orangepiplus:armhf 5.16 2016-09-19 11:01:01 status unpacked linux-jessie-root-orangepiplus:armhf 5.20 2016-09-19 11:01:01 status unpacked linux-jessie-root-orangepiplus:armhf 5.20 2016-09-19 11:01:01 upgrade linux-u-boot-orangepiplus-default:armhf 5.16 5.20 2016-09-19 11:01:01 status half-configured linux-u-boot-orangepiplus-default:armhf 5.16 2016-09-19 11:01:01 status unpacked linux-u-boot-orangepiplus-default:armhf 5.16 2016-09-19 11:01:01 status half-installed linux-u-boot-orangepiplus-default:armhf 5.16 2016-09-19 11:01:01 status half-installed linux-u-boot-orangepiplus-default:armhf 5.16 2016-09-19 11:01:01 status unpacked linux-u-boot-orangepiplus-default:armhf 5.20 2016-09-19 11:01:01 status unpacked linux-u-boot-orangepiplus-default:armhf 5.20 2016-09-19 11:01:01 trigproc initramfs-tools:all 0.120+deb8u2 <none> 2016-09-19 11:01:01 status half-configured initramfs-tools:all 0.120+deb8u2 2016-09-19 11:01:12 status installed initramfs-tools:all 0.120+deb8u2 2016-09-19 11:01:12 trigproc systemd:armhf 215-17+deb8u5 <none> 2016-09-19 11:01:12 status half-configured systemd:armhf 215-17+deb8u5 2016-09-19 11:01:14 status installed systemd:armhf 215-17+deb8u5 2016-09-19 11:01:14 startup packages configure 2016-09-19 11:01:14 configure linux-firmware-image-sun8i:armhf 5.20 <none> 2016-09-19 11:01:14 status unpacked linux-firmware-image-sun8i:armhf 5.20 2016-09-19 11:01:14 status half-configured linux-firmware-image-sun8i:armhf 5.20 2016-09-19 11:01:14 status installed linux-firmware-image-sun8i:armhf 5.20 2016-09-19 11:01:14 configure linux-headers-sun8i:armhf 5.20 <none> 2016-09-19 11:01:14 status unpacked linux-headers-sun8i:armhf 5.20 2016-09-19 11:01:14 status half-configured linux-headers-sun8i:armhf 5.20 2016-09-19 11:02:00 status installed linux-headers-sun8i:armhf 5.20 2016-09-19 11:02:00 configure linux-image-sun8i:armhf 5.20 <none> 2016-09-19 11:02:00 status unpacked linux-image-sun8i:armhf 5.20 2016-09-19 11:02:00 status half-configured linux-image-sun8i:armhf 5.20 2016-09-19 11:02:12 status installed linux-image-sun8i:armhf 5.20 2016-09-19 11:02:12 configure linux-jessie-root-orangepiplus:armhf 5.20 <none> 2016-09-19 11:02:12 status triggers-pending initramfs-tools:all 0.120+deb8u2 2016-09-19 11:02:12 status unpacked linux-jessie-root-orangepiplus:armhf 5.20 2016-09-19 11:02:12 status unpacked linux-jessie-root-orangepiplus:armhf 5.20 2016-09-19 11:02:12 status half-configured linux-jessie-root-orangepiplus:armhf 5.20 2016-09-19 11:02:14 status triggers-awaited linux-jessie-root-orangepiplus:armhf 5.20 2016-09-19 11:02:14 configure linux-u-boot-orangepiplus-default:armhf 5.20 <none> 2016-09-19 11:02:14 status unpacked linux-u-boot-orangepiplus-default:armhf 5.20 2016-09-19 11:02:14 status half-configured linux-u-boot-orangepiplus-default:armhf 5.20 2016-09-19 11:02:14 status installed linux-u-boot-orangepiplus-default:armhf 5.20 2016-09-19 11:02:14 trigproc initramfs-tools:all 0.120+deb8u2 <none> 2016-09-19 11:02:14 status half-configured initramfs-tools:all 0.120+deb8u2 2016-09-19 11:02:14 status installed linux-jessie-root-orangepiplus:armhf 5.20 2016-09-19 11:02:24 status installed initramfs-tools:all 0.120+deb8u2 2016-09-19 11:02:25 startup packages configure Please note that at some moment I have migrated from Orange Pi Plus 2 to Orange Pi Plus 2E ( see http://forum.armbian.com/index.php/topic/1681-migrate-from-orange-pi-plus-2-to-orange-pi-plus-2e/). Then I modified link in /boot to point to correct platform. Additionally I have copied armbian.txt and armbian-release files from original Orange Pi Plus 2e image. Is there any way to correct this "invalid" identifier situation or it is some kind of bug in upgrade scripts? Additionally I am attaching: armhwinfo.log.before_upgrade.gz armhwinfo.log.after_upgrade.gz

Hi, I am not sure but it maybe a bug in the script. After starting device from SD card (it is visible as /dev/mmcblk0 device) I have /etc/fstab as following: root@orangepiplus:/etc# cat fstab /dev/mmcblk0p1 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 /var/swap none swap sw 0 0 Then I run nand-sata-install script. It is working correctly, but later on it is modifying copied fstab file and content is as following (pls pay attention on /dev/mmcblk1p1): root@orangepiplus:/mnt/rootfs/etc# cat fstab /dev/mmcblk1p1 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 /var/swap none swap sw 0 0 In my opinion it should not be done like this, because after reboot (without SD) emmc (which is currently visible as /dev/mmcblk1) will be visible as /dev/mmcblk0. BTW. I corrected this value by myself. I remember that some time ago I had a problem as my filesystem get mounted only read-only. Not sure if this was the reason...

Does anybody know if GPIO outputs are pull-upped or pull-downed by default? I mean - what is initial GPIO level (low/high)? What is initial state (out or in)? These answers are important for choosing transistor type (NPN/PNP or N-MOS/P-MOS). if by default level is "high" - 3.3 V then NPN/N-MOS would be a choice (then related control application can switch off fan by setting "low"). If "low" - then PNP or P-MOS (related control application will switch off fan by setting "high"). The reason is that fan should be running even if related control program (application, shell script etc.) failed to run or was not started.

Process is done. Thank you all for support. admin@PKSERVER:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 115.5G 0 disk └─sda1 8:1 1 115.5G 0 part /data mmcblk0boot0 179:16 0 4M 1 disk mmcblk0boot1 179:32 0 4M 1 disk mmcblk0 179:0 0 14.6G 0 disk └─mmcblk0p1 179:1 0 14.4G 0 part / admin@PKSERVER:~$ cat /proc/partitions major minor #blocks name 179 0 15267840 mmcblk0 179 1 15114128 mmcblk0p1 179 32 4096 mmcblk0boot1 179 16 4096 mmcblk0boot0 8 0 121085952 sda 8 1 121084928 sda1 admin@PKSERVER:~$

Just for information, OPi+2E has the same size of eMMC as OPi+2 (number of blocks = 15267840): root@orangepiplus2e:~# cat /proc/partitions major minor #blocks name 179 0 15159296 mmcblk0 179 1 15158272 mmcblk0p1 179 16 15267840 mmcblk1 179 17 12806144 mmcblk1p1 179 18 16384 mmcblk1p2 179 19 1 mmcblk1p3 179 21 16384 mmcblk1p5 179 22 16384 mmcblk1p6 179 23 786432 mmcblk1p7 179 24 16384 mmcblk1p8 179 25 32768 mmcblk1p9 179 26 786432 mmcblk1p10 179 27 16384 mmcblk1p11 179 28 16384 mmcblk1p12 179 29 16384 mmcblk1p13 179 30 32768 mmcblk1p14 179 31 16384 mmcblk1p15 259 0 655360 mmcblk1p16 179 48 4096 mmcblk1boot1 179 32 4096 mmcblk1boot0

My OPi+2E has arrived so I will do migration. Just wondering about statement above. Does it mean that before cloning I need to adjust contents of /etc/modules (you mentioned that 2e platform is using different WiFi driver)? For my OPi+2 is is as following (8189es module): admin@PKSERVER:~$ cat /etc/modules # /etc/modules: kernel modules to load at boot time. # # This file contains the names of kernel modules that should be loaded # at boot time, one per line. Lines beginning with "#" are ignored. 8189es #gpio_sunxi #w1-sunxi #w1-gpio #w1-therm #gc2035 Should it be changed somehow for OPi+2e?

I am confused - in 1S configuration there is no way to balance anything... It must be at least 2S configuration. I wanted to clarify your statement that "charging in parallel is not good", because in my opinion you made a mistake (which I corrected by saying that probably you meant "in series"). But as I said my config is 1S I still got no argument that this is bad idea.