tkaiser

Useless unless you want to 'restore performance' or perform the equivalent of TRIM on an SD card (if the card supports it). It gets pretty boring to repeat everything again and again since it's written in Armbian's documentation: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-authenticity TL;DR: Check download authenticity/integrity, check your card with F3 or H2testw, burn with Etcher. Everything else is a waste of time.

Well, no idea then. I just did a quick web search for 'arm unhandled fault synchronous external abort' and that let me stop immediately since I lack both skills and patience to deal with such stuff (especially when hardware initialization happening prior to the kernel starting might be involved). BTW: since we're talking about EspressoBin... when using next kernel branch after updating from 5.35 to 5.36 I successfully loose network. Anyone else experienced this?

Maybe. But still trying to support issues when 'armbianmonitor -u' output is missing is just a waste of time. I asked already so why do you not provide the support info? Wrt ASM106x: http://kaiser-edv.de/tmp/91o1vu/ -- the 106flash utility can be used to query and update the firmware (IIRC also backing up the current one which is strongly recommended), the contained firmware seems to be somewhat recent. Only noticeable change after I applied the update on my card was the missing eSATA capability (which is fine since not supported by those mPCIe thingies anyway). Before: ahci 0000:01:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 impl SATA mode ahci 0000:01:00.0: flags: 64bit ncq sntf stag led clo pmp pio slum part ccc sxs And after: ahci 0000:01:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 impl SATA mode ahci 0000:01:00.0: flags: 64bit ncq sntf stag led clo pmp pio slum part ccc

To elaborate on the problem: This affects only certain WD drives that are directly SATA attached when running kernel 4.13 or 4.14. So if your disk is in an USB enclosure you're fine and if you use a lower kernel version than 4.13 you're fine too. In other words: this is just another example of why Armbian's next branch kernel version policy is a real problem (assuming Armbian wants to be a stable distro for headless use cases and not what it has turned into the last 12 months)

Use default kernel (4.4) or non WD disks or wait until the bug that was introduced with 4.13 is resolved. Can a moderator please move last few posts to a new thread in 'Common issues' forum reading 'WD drives inaccessible starting with kernel 4.13' please?

It's an ASM1062 instead Information about your hardware setup (especially how all components are powered) is missing 'armbianmonitor -u' output is missing, in addition to that multiple 'smartctl -x /dev/sda' outputs would be interesting to see which error counters at the disk side increase with some reboots in between This thing was cheap, yes? If so, your post and mine should be moved to the 'Buy cheap, buy twice!' subforum I have a strong feeling this whole issue does not belong to Armbian but is something for a 'Cheap hardware is crappy hardware' reality TV show or something like that Is this a joke? I reported that such an el cheapo ASM106x is crap and that I can't use any disk with this thing any more after a few tests (couple of cable/contact matings) and you report now the same instead of throwing this thing in the bin?

The Tinkerboard is a bizarre fail. It needs way too much juice but the 'board designers' chose Micro USB for DC-IN so users end up will all sorts of instabilites due to undervoltage (please read again: underVOLTAGE): I've no idea why Armbian continues to support such support nightmares (users will never understand that shitty hardware causes trouble that looks like instable software) but at least you should be aware now that you're suffering from a hardware problem. Power through GPIO header, replace the Micro USB cable between PSU and board, replace the PSU, replace the board. That's your 4 options if you want to have fun and use something reliable.

Sorry, I was not talking about a comparison of those two boring boards but referenced the Xunlong board just as a starting point wrt software situation. For my use cases OPi Zero Plus 2 regardless which SoC is used is uninteresting anyway and it's more or less the same with M2+ since overpriced. Software situation with Allwinner is a constant mess and I gave up on them already. If Allwinner boards cost less than 15 bucks they're worth a look for IoT purposes or lowend NAS but for everything else (except camera maybe) there are better alternatives in the meantime. Disclaimer: only talking about my use cases. Final note: 'eMMC: 8GB x 8GB' -- at least on the OPi Zero Plus 2 I shortly tested with there was amazingly fast eMMC (40/80 MB/s write/read) and at least on my BPi M2+ is the slowest eMMC I've ever encountered (6.5 MB/s write, I forgot the read 'speed' already). So depending on the use case (eg. expecting 'class 10' performance which would require at least 10 MB/s sequential write) it's always necessary to look a bit closer since on the majority of Allwinner boards the eMMC is slow crap (Xunlong being the notable exception but even they replaced fast eMMC on some Orange Pi in the meantime with slow one which is somewhat understandable given the constant rise of BOM costs for flash memory)

Just look at Orange Pi Zero Plus 2: same PCB, one batch with H3 in the reel, the other batch H5. Due to software incompatibility use cases and usability of the two variants differ a lot (and I personally have not the slightest idea why 'we' started here to support the H5 variant at all since IMO no reasonable use case exists -- H3 variant with legacy kernel + Mali and video acceleration is something different) So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right?

But not upgraded to latest version? I remember that there was an issue with Network Manager and Wi-Fi MAC addresses on Stretch (and other more recent distros) that should be solved in the meantime. You might want to start reading from here. Besides that how does the output from the following look like? modinfo 8812au | grep rtm_initmac

Obviously based on ASM1061/ASM1062. If it looks exactly like the one I bought -- see picture below -- then due to placement of the SATA connectors you won't be able to use it on EspressoBin. On a related note: I'm going to throw my ASM1062 into the bin soon since both SATA ports are unreliable (contact problems after maybe 10 matings each) and I get always tons of errors as soon as I attach disks there and run something demanding. That's something we should always keep in mind. We're talking about internal SATA connectors here, those are rated for 50 matings max and the cheap crap we buy on Aliexpress and eBay can't withstand even this and might fail way earlier.

Me too. If I would want to combine an EspressoBin with a bunch of big disks I would probably follow the GnuBee design https://forum.openmediavault.org/index.php/Thread/20053 (please check whole thread, the vibration discussion the GnuBee folks obviously also read, and how they came up with a different design then). One MDF piece as bottom, two large metal plates to attach HDDs and spread heat away from them (most HDDs are designed for this), top open or maybe a punched plate on it. And some vibration rings. Parts for a few bucks and a few holes to drill. But since powering the whole setup becomes the most challenging part using an old multi-bay NAS enclosure (available for free at your local scrap yard ) might be an even better idea. One of the nice EspressoBin details is that the board fits pretty nicely in almost any larger enclosure. Some multi disk performance numbers with EspressoBin and single lane PCIe SATA controllers available here: https://forum.armbian.com/topic/4845-marvell-based-4-ports-mpci-sata-30/ (RAID performance will suck somehow but since playing RAID at home is stupid anyway this doesn't matter at all)

It's Aluminium, so just drill in a hole, saw a bit, sand the borders and you're done. And use tape if not needed (yeah, I'm one of the guys who never care about the look of enclosures since I hate boring equipment being exposed. All of such stuff is hidden in closets/cabinets here)

Nope, these are just default permissions set by the kernel. Any result of a web search for 'sysfs change permissions' will do, eg. https://unix.stackexchange.com/questions/68897/how-to-set-permissions-in-sys-permanent

I don't know whether I understand the question since by looking at either specs or even pictures the question is already answered, isn't it? There's a SATA port behind the USB3-to-SATA bridge and there's an USB2 port. Sure, OMV's user interface allows you to do any stupid things you want (eg. playing RAID-1 which is just an insane waste of disks for no reason -- 'RAID is not backup' and especially mdraid's RAID-1 is crap!) but also allows to take care of data protection and backup. But that's obviously stuff for OMV documentation / forum and not for a device review thread here.

Please check /proc/device-tree/model (applies also to all boards Armbian supports and there should be even a way to use a somewhat similar method at least with Allwinner legacy kernel since I tried some time ago to make fex contents compatible with the DT 'model name' mainline kernel uses for the same devices)

Just wait for your board arriving, then use a Powermeter and check what's going on (most probably fiddling around with this is not worth the efforts). Powering of the Wi-Fi chip is usually controlled via a GPIO pin and there exist a couple of ways to toggle those GPIOs, eg. https://forum.armbian.com/topic/5719-opione-usb-power-off/?do=findComment&comment=44261

No, the above command is for legacy kernel. With mainline kerrnel you delete the line reading '8189fs' in /etc/modules (the Zero Plus has another Wi-Fi chip) and maybe you have to blacklist the module additionally. Just give it a try when the board arrives, delete the line as described above, reboot and check 'lsmod' output for 8189fs. If it's there collect the output from 'armbianmonitor -u' and start a new thread (especially since this thread here is about another Wi-Fi module)

Fixed with most recent firmware update. As already suggested it's the best idea to check such basic device support stuff over in Hardkernel's forum. Since I found my EspressoBin again I quickly made a disk performance comparison between EspressoBin and HC2 with same disk, same 12V PSU (the one from HC2) and identical test. I created 10 partitions on an older Seagate Barracuda and ran 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' on the first and last partition to measure the Zone bit recording (ZBR) influence and compared to that the USB-to-SATA overhead. EspressoBin (native SATA, dual-core A53 @ 1.0GHz): Most outer tracks random random kB reclen write rewrite read reread read write 102400 4 38374 55057 55560 56965 1069 1065 102400 16 106295 145784 149721 146768 4417 4757 102400 512 185709 185657 195152 208663 66077 109677 102400 1024 185809 183024 195910 210544 94518 139335 102400 16384 161376 190062 191007 206133 195470 173037 Most inner tracks random random kB reclen write rewrite read reread read write 102400 4 36221 52685 57760 55920 1117 876 102400 16 102695 115695 104080 105510 4156 2258 102400 512 114614 114578 121710 128529 51331 80396 102400 1024 114641 114690 124344 133445 75044 95449 102400 16384 106151 114470 127629 127190 121159 107905 ODROID HC2 (USB3 SATA via JMS578, octa-core with 4 x A15 cores @ 2.0GHz):: Most outer tracks random random kB reclen write rewrite read reread read write 102400 4 13093 18465 18978 19550 1120 1041 102400 16 60695 65743 66638 66918 4284 4759 102400 512 181296 183683 160550 174847 59757 112229 102400 1024 181539 183761 185347 203931 87746 130942 102400 16384 156686 183753 190891 207956 193699 168763 Most inner tracks random random kB reclen write rewrite read reread read write 102400 4 17044 18679 18021 19589 1073 795 102400 16 60380 66453 47286 64413 4085 2842 102400 512 112966 112848 118677 127218 46118 80652 102400 1024 109957 64721 118274 125493 70672 87559 102400 16384 98049 113128 120900 130945 124400 106930 Especially with small block sizes sequential write and read performance suffers a lot with small block sizes due to added USB overhead while with large blocksizes the difference between native SATA and USB3 SATA is negligible (this is what the usual inappropriate pseudo benchmarks done with dd/hdparm will also show: almost no difference). So it highly depends on the use case whether HC2 with its USB3 SATA implementation will perform a lot slower compared to 'true SATA' ports like on EspressoBin or almost as fast.

And guess what: I have a huge box here labeled 'PC-Schraddel' (PC junk), just checked it for those cables and to my surprise I found in there my EspressoBin and also the right cable with 2 female Molex jacks:

Sounds like a good idea to me even if I would prefer a somewhat different enclosure approach following your thermal design with a huge metal bottom plate (might even look like this) but combined with cheap 3D printed top parts. Anyway, please keep us informed and if you come up with an enclosure for sale then it would be IMO worth to 'feature' this somehow... Wrt the 'Molex problem' I did some research some time ago to find a cable with female Molex connector suitable to connect to a disk's SATA power port. My first hit on Aliexpress was even inexpensive but one person claimed the wires would be too thin which leads to 3.5" disks not spinning up. I really wonder why GlobalScale put the wrong Molex connector on the board...

Nice. How did you solve the problem of the stupid Molex male power connector? And do you sell these things?

You've still a corrupted btrfs filesystem, you're still playing with a device that you tortured with 20V in between, AFAIK (not reading through all the new posts since useless) you're still using strange powering. We're back at the 'waste of time' aspect. This thread might serve as something others can learn from. But that's it IMO.

It's the 512MB variant with eMMC in the kit which adds the additional $10.

Seriously: you now power totally different than before since you play around with custom wiring. If you did something wrong before you created what you suffered from: undervoltage. And now let's stop! The only reason I posted in this thread was since I couldn't believe what was happening and that others created the impression your powering problems would be related to software in general or Armbian. Please add spoiler tags to the walls of text you posted since then this thread might serve as a read for other users affected by the same boring underpowering hassles.