piknew Posted July 25, 2016 Share Posted July 25, 2016 Hi, currently my small server is running under Armbian 5.16 on Orange Pi Plus 2 board. It is using eMMC as root fs. I am expecting to get Orange Pi Plus 2E to be delivered shortly. The question is if following procedure will be OK to migrate server between boards: before: stop services etc. 1. insert SD card (16GB) when system is running. eMMC is visible as /dev/mmcblk0, SD card will appear as /dev/mmcblk1. 2. use nand-sata-install to copy system to SD Card. 3. mount /dev/mmcblk1 under some mount point, for example /mnt 4. verify, if /mnt/etc/fstab is valid: /dev/mmcblk0p1 / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 5. modify link: cd /mnt/boot && rm script.bin && ln -s bin/orangepiplus2e.bin script.bin (* currently it is link to bin/orangepiplus.bin). 6. umount /mnt remove SD Card and insert to new 2E device. It should boot without problems??? If yes - use nand-sata-install to copy system to eMMC (procedure very similar to above). Link to comment Share on other sites More sharing options...
tkaiser Posted July 25, 2016 Share Posted July 25, 2016 I would first check whether eMMC on Plus 2E is at least the same size as on Plus 2. Since if this is the case you can migrate way faster and more reliable if you have 2 SD cards lying around. So please check the output of grep mmcblk /proc/partitions and compare the size of eMMC devices shown. If count of blocks is the same or higher on Plus 2E you're save. Simply burn Armbian for OPi Plus 2E on 2 SD cards. On the Plus 2 all you do is then: cd /boot && ln -sf bin/orangepiplus2e.bin script.bin && shutdown -h now Then boot both boards from SD card and transfer the whole contents of /dev/mmcblk1 through the network: From OPi Plus 2E you do ssh root@plus2 "dd if=/dev/mmcblk1 bs=1M | gzip -c" | gunzip -c | dd of=/dev/mmcblk1 Then shut the board down, remove SD card, power on and enjoy the migrated installation. The nand-sata-install approach might also work but this means two times cloning a live installation which is known to NOT work in case you have databases running or stuff like that (simply use 'lsof' to get an idea how many open files your installation currently has. All of them are prone to change/mismatch when cloning a live installation as we do it with the nand-sata-install script) Link to comment Share on other sites More sharing options...
piknew Posted July 25, 2016 Author Share Posted July 25, 2016 From OPi Plus 2E you do ssh root@plus2 "dd if=/dev/mmcblk1 bs=1M | gzip -c" | gunzip -c | dd of=/dev/mmcblk1 Then shut the board down, remove SD card, power on and enjoy the migrated installation. The nand-sata-install approach might also work but this means two times cloning a live installation which is known to NOT work in case you have databases running or stuff like that (simply use 'lsof' to get an idea how many open files your installation currently has. All of them are prone to change/mismatch when cloning a live installation as we do it with the nand-sata-install script) Thank you. Your way is much simpler. For running databases etc. actually I wanted to "stop services etc." (it is not 100% efficient, then lsof would be good to determine if any of important live-data is still under some processing/activity). But cloning offline system is much much better and efficient (just as stated size of target eMMC must be at least the same by number of blocks). Just to clarify your post (I guess there is a little bit of mistake - one SD card should contain OPi Plus 2 and second one - OPi Plus 2e - appropriate for target platform). And the described way is OK no matter which system I would run on both devices (It may be even not Armbian ). It would be important that both are run from SD card (for example /dev/mmcblk0) and eMMC is available as some other device (for example as /dev/mmcblk1). Thanks once again. BTW. I have only one SD Card. But I will use 3rd device in my network, QNAP Nas. So 1st I will run OPi Plus 2 from SD and from NAS: [~/OPiPlus2] # ssh root@plus2 "dd if=/dev/mmcblk1 bs=1M | gzip -c" >eMMC.gz (I can execute it from OPi Plus 2, but the command of course will be different). Then modify link so OPi Plus 2e would be able to start from SD Card. Start OPi Plus 2E and execute command to transfer image to mmcblk1 (I can execute command from either NAS or OPi Plus 2E). Link to comment Share on other sites More sharing options...
piknew Posted July 25, 2016 Author Share Posted July 25, 2016 One more question - as I understand the difference between OPi Plus 2 and 2E is only by used script.bin file? The rest (especially kernel) is the same? Link to comment Share on other sites More sharing options...
tkaiser Posted July 25, 2016 Share Posted July 25, 2016 Just to clarify your post (I guess there is a little bit of mistake - one SD card should contain OPi Plus 2 and second one - OPi Plus 2e - appropriate for target platform). Generally speaking yes, in this specific case it doesn't matter since the only differences affect USB and WiFi -- both not needed when it's about to dd to/from eMMC In this case the only differences between both OS images are contents of script.bin and /etc/modules (different WiFi driver). BTW: In case you moved your installation within the last 5 weeks to eMMC then you're lucky since I adopted our firstrun behaviour (leavy some space unpartitioned on SD card) for nand-sata-install too. This has been done for exactly this reason: ease the cloning of an installation. Link to comment Share on other sites More sharing options...
piknew Posted July 25, 2016 Author Share Posted July 25, 2016 May I know why unpartitioned space (at the end of block device) is helping in case of cloniong device data by "dd copy"? Link to comment Share on other sites More sharing options...
piknew Posted July 27, 2016 Author Share Posted July 27, 2016 BTW: In case you moved your installation within the last 5 weeks to eMMC then you're lucky since I adopted our firstrun behaviour (leavy some space unpartitioned on SD card) for nand-sata-install too. This has been done for exactly this reason: ease the cloning of an installation. I guess it is ok? See results: admin@PKSERVER:~$ sudo fdisk /dev/mmcblk0 Welcome to fdisk (util-linux 2.25.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/mmcblk0: 14.6 GiB, 15634268160 bytes, 30535680 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 /dev/mmcblk0p1 2048 30230303 30228256 14.4G 83 Linux Command (m for help): q 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 16 121085952 sdb 8 17 121084928 sdb1 admin@PKSERVER:~$ Link to comment Share on other sites More sharing options...
tkaiser Posted July 27, 2016 Share Posted July 27, 2016 May I know why unpartitioned space (at the end of block device) is helping in case of cloniong device data by "dd copy"? Let's take your current partition layout. On your OPi Plus 2 it looks like: admin@PKSERVER:~$ cat /proc/partitions major minor #blocks name 179 0 15267840 mmcblk0 179 1 15114128 mmcblk0p1 So /dev/mmcblk0 is 15267840 1K blocks large but Armbian's rootfs partition uses only 99 percent of this. Now imagine that for whatever reasons your OPi Plus 2E ships with an eMMC that is only 15267839 1K blocks large (15267840 - 1). If you now clone the whole device dd will report an error for sure since destination has less capacity than source. But since the partition scheme only uses 99 percent of the device's capacity you can safely ignore dd's error message and enjoy your cloned installation afterwards that will look then like this: admin@PKSERVER:~$ cat /proc/partitions major minor #blocks name 179 0 15267839 mmcblk0 179 1 15114128 mmcblk0p1 Link to comment Share on other sites More sharing options...
piknew Posted July 27, 2016 Author Share Posted July 27, 2016 Thank you for examplanation. It is clear for me now (I am just waiting for OPi+2E to test it in practical). This design assumption is quite good - one device may be slightly different than other "the same size" device. Link to comment Share on other sites More sharing options...
piknew Posted August 10, 2016 Author Share Posted August 10, 2016 In this case the only differences between both OS images are contents of script.bin and /etc/modules (different WiFi driver). 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? Link to comment Share on other sites More sharing options...
martinayotte Posted August 10, 2016 Share Posted August 10, 2016 In the OPi+2E, the driver is the F one, since it is the SDIO variant : 8189fs Link to comment Share on other sites More sharing options...
piknew Posted August 11, 2016 Author Share Posted August 11, 2016 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 Link to comment Share on other sites More sharing options...
piknew Posted August 12, 2016 Author Share Posted August 12, 2016 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:~$ Link to comment Share on other sites More sharing options...
Recommended Posts