WarHawk_AVG

diagnostics listing of Orange Pi Zero 2W http://ix.io/4Lwr Not sure if this helps..but the stock build is lacking...plus I am getting 1.0 cpu usage at idle Orange Pi 1.0.0 user-built System too busy for benchmarking: 16:33:21 up 25 min, 3 users, load average: 1.15, 1.03, 0.92 System too busy for benchmarking: 16:33:26 up 25 min, 3 users, load average: 1.14, 1.03, 0.92 System too busy for benchmarking: 16:33:31 up 25 min, 3 users, load average: 1.13, 1.03, 0.93 System too busy for benchmarking: 16:33:36 up 25 min, 3 users, load average: 1.12, 1.03, 0.93 System too busy for benchmarking: 16:33:41 up 25 min, 3 users, load average: 1.11, 1.03, 0.93 Wish there was an official Armbian build...it usually seems much more "complete"

I never got a chance to try a self build image...however After updating I decided to give it a whirl...I have a 1TB USB->SSD adapter (yeah, way overkill!!!!), and a 64GB USB drive... The 1TB drive has a 1/2 dozen docker containers running on em (the OPiPC isn't a powerhouse by any stretch...but by golly it's running...and has been running like a BOSS!!!! Thanks Armbian devs!) Gave it a whirl one last time...even did it remotely! (was worried I would bork it and get locked out...but it came right up!) warhawk@orangepipc:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 931.5G 0 disk └─sda1 8:1 0 931.5G 0 part /home/warhawk/hdd sdb 8:16 1 57.6G 0 disk └─sdb1 8:17 1 57.6G 0 part /var/log.hdd / mmcblk0 179:0 0 14.8G 0 disk └─mmcblk0p1 179:1 0 14.7G 0 part /boot /media/mmcboot zram0 254:0 0 499M 0 disk [SWAP] zram1 254:1 0 50M 0 disk /var/log zram2 254:2 0 0B 0 disk [Yeah, I have log2ram and zram-tools installed so it shows the mount point as /var/log.hdd and /] Worked like a boss...it did however blow out the /etc/fstab entry mounting the /dev/sda1 to /home/warhawk/hdd link...but was a VERY easy fix! warhawk@orangepipc:~$ cat /etc/fstab # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=705b28eb-7ba5-481e-ac44-cb93d2cfd612 /media/mmcboot ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 /media/mmcboot/boot /boot none bind 0 0 UUID=3c82ef17-f148-4cd5-afb5-efa861ad05ef / btrfs defaults,noatime,commit=600,compress=lzo,x-gvfs-hide 0 2 UUID=7e6a8eab-cf51-4649-9526-dd8adfeb63e4 /home/warhawk/hdd ext4 defaults,noatime,commit=600,x-gvfs-hine 0 0 I even found an older version of geekbench built for older ARM and ran it...nope..not a power house https://browser.geekbench.com/v5/cpu/compare/21830053?baseline=21830053 Even got an ARMv7 version of netdata working in a docker and even though it is a wee bit heavy on system resources, it's running it Odd thing is...the OPiPC has been more resilient than my daggum RPi4B 8GB...for some reason it either locks up or burns out the stupid POE hats I put on it...but the OPiPC keeps chugging! Kudo's to you and the dev team! OUTSTANDING job!!!!!!!! N_A - Geekbench.pdf

I believe I figured out why it's not working The proper format for /etc/fstab would be UUID=${target_partition_uuid} / ext4 defaults,noatime 0 1 Rather than /dev/disk/by-uuid/${target_partition_uuid} / ext4 defaults,noatime 0 1 Might be a quick fix in the script...and/or have people change that entry...for some reason it hangs on reboot because it cant' seem to get back the /dev/disk deal Also, found that the script was not commenting out the /dev/mmcblk0p2 above the entry it placed Just like in the adafruit script...it's putting the wrong ID in /etc/fstab so upon booting it can't figure out the /dev/disk/by-uuid/ entry rather than just the UUID= Can someone verify?? Ah heck...what can I loose other than a new reflashing huh?

Not sure if you guys are partnering with Orange Pi to produce the Orange Pi 800 OS...but just got mine in...fired it up and EVERYTHING was Armbian just re-branded as "Orange Pi" And uggh...all the apt sources were out of China...so trying to upgrade was CRAZY slow!

Brilliant! Love it...does it support USB to SSD/NVME and the like?

Found a spare card...flashed...working like a boss off the SD...was just wishing there was a way to have a boot SD that pointed to a USB/HDD for the OS will u-boot work on a fat32SD card like raspbian? If only there was a 2nd partition...

So sweet!!!

nope...then fired the daggum card out the back into the closet...uggh Waiting for the 64GB Sandisk Ultra's to come in...arrrgh

I really wish they would follow suit with other SBC distro...and have a small 256mb fat 32 as /boot...then the rest being the rootfs This way moving the root fs to another drive/partition would be MUCH easier and the system could still boot from the SD card

well crap... https://docs.armbian.com/User-Guide_Recovery/#flashing-boot-loader Is there no way to just copy the /boot partition to the SD card, then the root partition only on the USB? Would make it SOOOO much easier to have a small 256mb /boot partition (that could live forever and practically untouched unless booting on the SD card), then the rest under the linux format... reflashing...again This might help...maybe (would love to be able to move the rootfs to a USB and just boot up from the SD) https://paste.armbian.com/avocuvopid Right now the /dev/sdb1 formatted as BTRFS has the entire "before the hang" rootfs on the drive...I wonder if I could just update the /boot/armbianEnv.txt (from the new working only from the SD card reflash) verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 rootdev=UUID=705b28eb-7ba5-481e-ac44-cb93d2cfd612 rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u to verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 rootdev=UUID=b8a31eff-ba94-410f-9568-53171f393e3b rootfstype=btrfs usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u from Command (m for help): Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): Partition number (1-4, default 1): First sector (2048-31116287, default 2048): Last sector, +/-sectors or +/-size{K,M,G,T,P} (8192-31116287, default 31116287): NAME FSTYPE SIZE MOUNTPOINT UUID sda 931.5G └─sda1 ext4 931.5G 7e6a8eab-cf51-4649-9526-dd8adfeb63e4 sdb 57.6G └─sdb1 btrfs 57.6G b8a31eff-ba94-410f-9568-53171f393e3b mmcblk0 14.8G └─mmcblk0p1 ext4 1.9G / 705b28eb-7ba5-481e-ac44-cb93d2cfd612 zram1 50M /var/log zram2 0B Once the crash happened. The data is moved(rsync from the install command) and is still there in the locked USB drive...it should be able to just point there...or is that H3 disable from the above post mean it will NEVER work? It worked before on an older release.... I guess worse comes to worse...I would just have to reflash for the bazillionth time...

dangit...still borked...just attempted again...locked up at boot

Any luck on this? I did see an update to armbian-firmware come in... I just hate having to re-flash when it borks

Cool...how is the thruput on the drives?

Have no clue how to use it...I just know it starts and I get the webgui

From your initial link...installed and working on my Orange Pi PC just fine https://github.com/sshmanko/acestream-armv7 Just follow the howto just git clone https://github.com/sshmanko/acestream-armv7 Then cd into the directory it created modify the .conf file with username/password then run the .start file and it comes right up