AnythingIsFine Posted May 4, 2018 Share Posted May 4, 2018 Hello, I want to try out Armbian OS as opposed to Ubuntu Artful 17.10 on my Rock64, mainly to see how it compares(I am aware Armbian minimal for Rock64 is derived from Ubuntu Xenial, but I understand it's optimized for ARM CPUs) Long story short, I have a 32GB eMMC and a eMMC to USB adapter from Pine64 and would like to run Rock64 Armbian off it, but I was unable to simply flash Armbian to it using 'dd' or Etcher as with ayufan's Ubuntu images. I am aware it's possible to boot from an microSD card and use the "nand-sata-install" bash script to achieve this as described in the Armbian documentation, so I am inquiring if I can bypass using the microSD card. * I want to know if it's possible to flash Ubuntu Xenial 16.04 on my eMMC, mount it in my Rock64 and attempt to an build Armbian image, which I can later copy to a separate storage media and flash to my eMMC card. If this is indeed achievable, I will share the Armbian eMMC rock64 image for all to enjoy. Regards, Link to comment Share on other sites More sharing options...
Igor Posted May 4, 2018 Share Posted May 4, 2018 3 minutes ago, AnythingIsFine said: but I was unable to simply flash Armbian to it using 'dd' or Etcher as with ayufan's Ubuntu images Can you get a console log? Link to comment Share on other sites More sharing options...
pfeerick Posted May 5, 2018 Share Posted May 5, 2018 You can most certainly just flash Armbian to the eMMC instead of to microSD and using nand-sata-install... I just tried it with the 5.42 xenial build of Armbian and it worked just fine. https://pastebin.com/qvNad516 1) Download 7z file containing image from Armbian website 2) Extract .img file from 7z archive (i.e. Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img at time of writing) 3) Write .img file with Etcher using USB eMMC adapter 4) Once verified (man that eMMC verifies fast on USB3!!), clip eMMC onto rock64 and apply power It's possible what was tripping you up is that ayufan's images are xz compressed, and Etcher can read then natively. It can't read the 7z archives natively, so you have to help it and extract the disk image from the archive before writing it. Link to comment Share on other sites More sharing options...
AnythingIsFine Posted May 5, 2018 Author Share Posted May 5, 2018 Firsly, thanks for your interest in my issue! @Igor I am afraid that's not possible, as I did not save the logs... In any case, no error was reported. @pfeerick I tried to flash the latest image of Armbian for Rock64, the very same one you pointed out. Here are the steps I undertook: 1) Downloaded the latest Rock64 Armbian build. 2) unzipped the image 3) a. Attempted to flash the image using 'dd if=/path/to/armbian_rock64.img of=/dev/sdb bs=1M' The image was flashed on the eMMC card, but only the 1.1GB root partition, no '/boot' partition was created. It looked as if the image was simply copied as opposed to flashed... b. Formatted the eMMC card, this time I used Etcher (the Pine64 version from Github), and had the same result. To test if I was actually doing something wrong, I used Etcher to flash ayufan's Ubuntu Xenial to eMMC, it worked and it created the /boot partition along with the root partition as expected, tried again with ayufan's Ubuntu Artful image, worked as well... 4) Etcher did not verify my image as I am running Fedora27 Workstation... Quote It's possible what was tripping you up is that ayufan's images are xz compressed, and Etcher can read then natively. It can't read the 7z archives natively, so you have to help it and extract the disk image from the archive before writing it. I unzipped the downloaded archive, albeit I used Fedora's native zip tool, not '7zip'...but the image was uncompressed with no error reported. Also, the Etcher GUI will only list images (probabily by looking for the '.img' extension on the end of files) so unless you uncompress the downloaded file you won't be able to see it in Etcher, let alone flash it... I will try to flash with Etcher once more from a Windows7 machine on Monday, although I am sceptical to say the least... If all else fails I will use the "nand-sata-install" script to flash the image to eMMC and create an image out of that to share with others... Link to comment Share on other sites More sharing options...
pfeerick Posted May 5, 2018 Share Posted May 5, 2018 When you did the dd, did you do a sync afterwards to ensure the image had completely finished writing to the sd card? pfeerick@ASUS-H55D:~$ sudo dd if=~/Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img of=/dev/sdf status=progress bs=1M 832569344 bytes (833 MB, 794 MiB) copied, 3.00251 s, 277 MB/s 1052+0 records in 1052+0 records out 1103101952 bytes (1.1 GB, 1.0 GiB) copied, 3.97628 s, 277 MB/s pfeerick@ASUS-H55D:~$ time sync real 0m11.902s user 0m0.000s sys 0m0.028s As can be seen above, I needed to wait 12 seconds after dd had finished before I could safely remove the microSD card. (Edit: Just to remove any confusion, I loaded Armbian on a microSD this time to show the timing and that a sync is needed with dd. I previously loaded and booted a 16GB FORESEE eMMC using the pine64 eMMC to USB adapter.) Armbian does not need a separate /boot partition, as the version of uboot it ships with supports ext4, hence they were able to get rid of that extra partition. pfeerick@ASUS-H55D:~$ sudo fdisk -l /dev/sdf Disk /dev/sdf: 15 GiB, 16118710272 bytes, 31481856 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: 0x91a1b523 Device Boot Start End Sectors Size Id Type /dev/sdf1 32768 2154495 2121728 1G 83 Linux pfeerick@ASUS-H55D:~$ fdisk -l Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img Disk Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img: 1 GiB, 1103101952 bytes, 2154496 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: 0x91a1b523 Device Boot Start End Sectors Size Id Type Armbian/Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img1 32768 2154495 2121728 1G 83 Linux Why does running Fedora Workstation mean that Etcher skips the verification/validation after writing? Are you running an older version, or have it turned off in the options? Etcher can read a xz compressed image (e.g. xenial-containers-rock64-0.6.27-196-arm64.img.xz) natively, without any need to extract the image from it. It cannot do the same for yet, although it has been discussed on their issue tracker as a possibility. Link to comment Share on other sites More sharing options...
AnythingIsFine Posted May 6, 2018 Author Share Posted May 6, 2018 @pfeerick Quote When you did the dd, did you do a sync afterwards to ensure the image had completely finished writing to the sd card? No, I did not issue a 'sync' after the 'dd' command was executed, but I waited a while before un-mounting the USB to eMMC adapter as I browsed the files that were flashed to it (certainly more than 3 minutes) I also waited after flashing the image with Etcher... Quote Armbian does not need a separate /boot partition, as the version of uboot it ships with supports ext4, hence they were able to get rid of that extra partition. I was not aware of this... Nevertheless, once I inserted the eMMC into my Rock64, it would not boot up, the white and red LEDs were constantly on as opposed to when booting Ubuntu Xenial/Artful when the red led was rapidly blinking indicating it found a bootable storage device and once it finished booting only the white LED would remain on... Quote Why does running Fedora Workstation mean that Etcher skips the verification/validation after writing? Are you running an older version, or have it turned off in the options? When I flashed images to microSD cards using on a Windows 7 machine, it also ran a "Verifying" step post flashing, this does not happen on Linux in my experience... Quote Etcher can read a xz compressed image (e.g. xenial-containers-rock64-0.6.27-196-arm64.img.xz) natively, without any need to extract the image from it. It cannot do the same for yet, although it has been discussed on their issue tracker as a possibility. I agree, but the Armbian image in question is compressed using '7zip' and as such you won't be able to flash it using Etcher unless you uncompress it beforehand. This is why I stated it would have been impossible for me to flash the compressed image to eMMC using Etcher. Link to comment Share on other sites More sharing options...
pfeerick Posted May 7, 2018 Share Posted May 7, 2018 If you subsequently mounted and unmounted the partition, a sync shouldn't have been needed, as you introduced enough time for the buffers to be written to disk, and the unmount shouldn't release the drive until everything has been written to disk. I don't know what's happening on your side with the verification, since at least version 0.9 Etcher has done a verify/validate on a write after the write phase on both Linux and Windows, but it was very subtle... the progress bar would just run through a second time but would state it was verifying instead of writing. In a update (1.4.2 or 1.4.4?) that was pushed a couple weeks ago, the verify progress bar is a different colour now, making it more visible. If you're using a serial console cable with the rock64, it would be a good idea to disconnect it (from the computer), powerup the rock64, and reconnect it, as sometimes the power feeding in from the serial console cable via either the TX or RX pin is enough to leave the rock64 in a non-booting state. Other than that, if Ether is verifying the image, it sounds like the image writing to eMMC is fine, so I don't know what else is going on. If you want to get really bored, you can watch these two screen record caps of me writing the current rock64 Ambian xenial image to the eMMC and then booting it... firstly using Etcher and then secondly using dd. Note with the dd capture I ran into the intermittent issue where the rock64 will not boot properly if there is a serial console cable connected at power on- it gets some residual power via the serial console cable and doesn't reset the CPU properly. Side-note: Can you link to a image that does this 'led' flashing... I've been using the Xenial images (initially the minimal images, but now container ones) of ayufan's images since he started producing them and hadn't noticed any of them flash the either of the LEDs OOTB, other than ones that flash the SPI Flash memory chip. I seem to remember the Android ones doing that though. Link to comment Share on other sites More sharing options...
AnythingIsFine Posted May 7, 2018 Author Share Posted May 7, 2018 @pfeerick Thank you for your time! On the other hand, I do apologize for wasting it. I managed to boot up Armbian on my Rock64 and figured out that the issue was between the keyboard and chair, namely me. I am running only headless boot on my SBCs and I just configure a static IP after flashing the respective image, which I later use SSH into post boot. On ayufan's Ubuntu Xenial/Artful I just edited the '/etc/network/interfaces.d/eth0' file to achieve this, but when browsing the files after flashing the Armbian image, I noticed the "armbian_first_run.txt.template" file and decided to use this option instead... I edited it to boot 'eth0' to a static IP which I would use to SSH into it, just to test it out (nice feature by the way, very Raspbian-e) Of course, I edited the file accordingly, but simply forgot to rename it to 'armbian_first_run.txt' so it may be found and read and as such the IP I set in it was not configured, hence I could not ping the IP I set up. This mistake, coupled with the fact that the red LED was constantly on as opposed to flashing quickly during boot and then being turned off, lead me to *mistakenly* believe the Armbian image would not boot of my eMMC. Quote I don't know what's happening on your side with the verification, since at least version 0.9 Etcher has done a verify/validate on a write after the write phase on both Linux and Windows, but it was very subtle... the progress bar would just run through a second time but would state it was verifying instead of writing. In a update (1.4.2 or 1.4.4?) that was pushed a couple weeks ago, the verify progress bar is a different colour now, making it more visible. I think this is default behavior on Etcher on Windows/Linux. When flashing an image using Etcher on my Fedora 27 Workstation computer there is no validation happening post flash process, or at least its very subtle as you point out... When flashing an image using Etcher on my Windows 7 Enterprise SP1 computer, a validation step occurs post flash process, which roughly takes as much as the flash process itself. Quote Side-note: Can you link to a image that does this 'led' flashing... I've been using the Xenial images (initially the minimal images, but now container ones) of ayufan's images since he started producing them and hadn't noticed any of them flash the either of the LEDs OOTB, other than ones that flash the SPI Flash memory chip. I seem to remember the Android ones doing that though. As can be seen in the below link, the Ubuntu Artful image does cause the red LED to blink during boot up and turn off once the boot process is finished. Artful-minimal-rock64-0.5.15-136-arm64 - Boot up LEDs The Armbian image on the other hand, does not have the same behavior and the red LED just remains on the whole time, which is expected behavior according to this post (your response) Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124 - Boot up LEDs I wrongfully assumed that the red LED on the Rock64 had the same behaviour as the green one on the the Raspberry Pi 3B as described below. Source. Quote Check the ACT LED to determine if the Pi is booting The ACT LED is essential in determining if the Pi can actually read from the card. It indicates that it can read from the card by blinking, If the ACT LED doesn't blink quickly in an irregular pattern for at least twenty seconds, this indicates that the Pi cannot read from the SD card, and that booting is not taking place. P.S. I noticed the Rock64 Armbian image is still in its testing phase... If there are certain tasks/test cases the good folks at Armbian would need extra help to test/implement, please let me know where I can sign up to help! 1 Link to comment Share on other sites More sharing options...
Jason Fisher Posted May 8, 2018 Share Posted May 8, 2018 On 3/23/2017 at 1:00 PM, zador.blood.stained said: First, generic Ubuntu/Debian DKMS packages may not work on Armbian since we provide kernel versions that we can provide for different devices and not ones ubuntu/Debian has. Second, DKMS recompilation on kernel upgrade is broken, so please keep this in mind. If you want ZFS you need to find the latest zfs sources (this?) and either compile them on the device (if zfs supports out of tree builds) or use the Armbian build system on x64 Ubuntu Xenial to create a patched kernel packages. Please note that kernel headers package should be already installed so you don't need to install "linux-headers-$(uname -r)" if build instructions/tutorials suggest doing that. I have a ZFS solution here that uses dkms/zfs with the standard packages and a few modifications after the initial dkms build fails: Link to comment Share on other sites More sharing options...
pfeerick Posted May 9, 2018 Share Posted May 9, 2018 @AnythingIsFine Ouch! That sounds like me with the raspberry pi... when the recent 'disabled by default' behavior of the SSH... scratching my head to work out why the SSH wasn't working, and I'd firstly forgotten to make the enable file, then made a typo in the filename... At least it's working now! Hm. so the artful images... interesting... will have to poke around and see why it changed. Be handy to port that back to other images. If the artful images are using the kernel that supports it, it could be signifying disk activity... 1 Link to comment Share on other sites More sharing options...
pfeerick Posted May 9, 2018 Share Posted May 9, 2018 @Jason Fisher er... not sure why you commented about ZFS as that has nothing to do with this thread... have you replied to the wrong thread? Link to comment Share on other sites More sharing options...
Recommended Posts