tkaiser

I prefer buying somewhere where I can read honest reviews, where products are rated by customers (and not bots) and where a 'no questions asked' return/refund policy exists. Unfortunately that's Amazon. I also prefer my country's amazon.de site and when I search there for 'rtl8812au' 2nd link is already my 'manufacturer' of choice: CSL (of course they're not a manufacturer but sell the same Chinese stuff as on Ali or eBay but with certificates that are not faked and products that are not fakes but conformant to specifications/advertisements) Hmm... what's the point of using a chipset with support for 4 real antennas to make a product with zero real antennas? The problem remains the same as with all other 'performance metrics'. People buy numbers like (faked) chipsets and this 600 Mpbs / 1300 Mbps or even 1750 Mbps marketing BS (with single antenna it's not 600 but only 433 Mbps since with el cheapo stuff you can't use 2.4GHz and 5GHz in parallel, then this is just the PHY rate and nothing real and especially with crappy antennas and one or two walls in between performance is already ruined). That said it's great that you integrated a suitable driver in 4.x kernels for those better RealTek dongles now. Tested recently on Orange Pi Zero Plus with my RTL8812AU and got almost as good numbers than my MacBook over short distances, when testing from my neighbour's flat the MacBook won easily (3 antennas). And when I repeated the test this time powering the whole setup not through Xunlong's 3A PSU with barrel plug but Micro USB this time performance was a little bit lower though I don't understand exactly why. Anyway: those better dongles are prone to underpowering which is just another item we need to have on our list of 'support issues' that will pop up once people will combine 'cheapest board possible' with 'cheapest 802.11ac dongle possible' and then blame Armbian for wireless instabilities while's just the usual underpowering mess we deal all day long with already.

Well, only the title is wrong but the fine-print reveals all the ugly details: Realtek 8188CU, 150Mbps, 802.11n -- won't prevent the 'buy cheap, buy twice' target audience to choose it though Ever thought about why access points have more than one antenna? Ever thought about why those devices with really good Wi-Fi performance (better high-end laptops for example) have 2 or 3 internal antennas? Since MIMO is a basic requirement for 802.11n and 802.11ac performance (more 'spatial streams' in parallel).

No, not with OPi One (and other H3 boards). AFAIK the only boards that really support this are Olimex boards with A10 or A20 SoC. See also https://forum.armbian.com/topic/1631-marriage-between-a20-and-h3-ups-mode-sunxi-pio-utility/

Well, here in dmesg output docker0 is missing (I was interested in this) but doesn't matter since on this other Potato the problem is the same and I've to admit that I've no clue what's going on (other than reading quickly through your other thread and realizing that this might be really a hardware/driver related problem). Thank you for the provided information, now I've at least something to look into (wrong armbianmonitor output that needs fixes)

Unfortunatenly there's most of the information missing. Anyway, would be interesting to get the output of the following 3 commands 20 seconds after a reboot and then 3 seconds after you did the 'ifdown eth0; ifup eth0' again. ip addr netstat -rn nslookup google.com And then please output from 'armbianmonitor -u' again afterwards. Thank you.

I've not that much to add since we babble about this BS way too often. IMO it's necessary to force users to provide 'quality information' but they refuse to do so (maybe 'armbianmonitor -u' is too long to type, maybe it needs an alias called 'selftest' or just 'help' -- no idea). Providing the information from armbianmonitor -u will become soon even more important since as usual users fear everything that changes and with Stretch we will get tons of 'bug reports' complaining 'eth0 is gone, there's no network but there is network. I want it like in Debian 7 again!!!', also people editing happily /etc/network/interfaces trying to define stuff for eth0 which doesn't exist any more so NM taking care of enx001e06330005 and users telling made out stories instead of providing facts. And so on... IMO basic rule to deal with support questions should be to stop supporting anyone unless the necessary information has been provided. And for people who want to support others understanding armbianmonitor output is beneficial:

After latest commit on those crappy Bananas and other A20 boards a little bit more underpowering monitoring should be possible when our next major release is out soon. Example output (from a Lime2 with a dying PSU and only protected by a huge battery and AXP209 PMIC any more): ### Current system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU PMIC DC-IN C.St. 21:57:46: 720MHz 0.33 4% 1% 1% 0% 0% 0% 39.6°C 40.3°C 4.44V 0/6 21:57:47: 528MHz 0.33 17% 13% 3% 0% 0% 0% 39.6°C 40.0°C 4.44V 0/6 21:57:47: 528MHz 0.33 18% 13% 5% 0% 0% 0% 39.6°C 40.1°C 4.44V 0/6 21:57:48: 528MHz 0.33 17% 14% 2% 0% 0% 0% 39.3°C 40.1°C 4.34V 0/6 21:57:49: 528MHz 0.33 29% 23% 2% 2% 0% 0% 39.3°C 40.1°C 4.44V 0/6 21:57:50: 960MHz 0.54 4% 1% 1% 0% 0% 0% 39.4°C 41.1°C 4.19V 0/6 21:57:51: 960MHz 0.54 100% 0% 100% 0% 0% 0% 39.4°C 41.9°C 4.19V 0/6 21:57:52: 960MHz 0.54 100% 1% 98% 0% 0% 0% 40.3°C 42.1°C 4.19V 0/6 21:57:53: 960MHz 0.54 94% 2% 92% 0% 0% 0% 40.3°C 41.6°C 4.42V 0/6 21:57:53: 528MHz 0.54 17% 14% 2% 0% 0% 0% 40.3°C 40.8°C 4.41V 0/6 The first 5 lines should show normal/idle behaviour while then a 'stress' task is fired up (as many threads in parallel as CPU cores available) which should show voltage drops on boards with insufficient power cables and PSUs (applies especially to those Micro USB equipped boards but of course can also show PSUs making problems as above -- without battery I would assume this Lime2 would be dead already since a long time)

Well, but sdb1 has been formatted with btrfs. Just look at the log and fast-forward to 'Tue Nov 21 20:41:51 EET 2017: Start nand-sata-install'... at least that explains why system is not booting now...

Well, you used btrfs as target filesystem and according to @Igor there's a bug right now, isn't it? /dev/sdb1 /mnt/nand-sata-install.EXlu6i/rootfs btrfs rw,relatime,compress-force=zlib,space_cache,subvolid=5,subvol=/ 0 0

Well, you could try it again running from this SD card but there's something wrong with your installation anyway (6 times booted according to log but only 2 times shutting down correctly, in the other 3 occurences there's no shutdown logging). BTW: the F3 or H2testw stuff here https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card also applies to every thumb drive you want to use. Always check flash media first.

Please check last occurences of '### df' and '### mtab' -- still running off SD card which is not surprising since if you logged out previously while nand-sata-install was running it got killed after the usual timeout happened (that's why if you search for nand-sata-install in the output you'll see that the last message is 'Copying 54328 files to /dev/sdb1.' but that's it and 'Finishing transfer' is missing entirely.

Tons of support questions dealt already with this, we have a search function here in the forum and if someone is using a wrong password it looks like this instead: Permission denied, please try again.

SSH --> sudo armbianmonitor -u

For everyome else stumbling accross this thread: 1) if someone asks you for 'armbianmonitor -u' output then simply provide it. Armbian devs spent a lot of time and efforts on a tool to provide necessary debug info so we can help you more easily. Not providing this information is also a great way to prevent us from fixing issues 2) Since for Le Potato currently only Xenial images are available I simply gave it a try with correctly defined /etc/network/interfaces settings. It just works as expected, no need to follow outdated tutorials for outdated Ubuntu versions that introduce just another bunch of different problems: root@odroidxu4:~# head /etc/network/interfaces source /etc/network/interfaces.d/* # Wired adapter #1 auto enx001e06330005 iface enx001e06330005 inet static address 192.168.83.254 netmask 255.255.255.0 gateway 192.168.83.1 dns-nameservers 192.168.83.1 9.9.9.9 # hwaddress ether # if you want to set MAC manually root@odroidxu4:~# ping -c 2 google.com PING google.com (172.217.22.238) 56(84) bytes of data. 64 bytes from muc11s02-in-f14.1e100.net (172.217.22.238): icmp_seq=1 ttl=57 time=13.4 ms 64 bytes from muc11s02-in-f14.1e100.net (172.217.22.238): icmp_seq=2 ttl=57 time=12.6 ms --- google.com ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 12.650/13.038/13.426/0.388 ms root@odroidxu4:~# nslookup google.com Server: 192.168.83.1 Address: 192.168.83.1#53 Non-authoritative answer: Name: google.com Address: 172.217.22.238 root@odroidxu4:~# armbianmonitor -u /var/log/armhwinfo.log has been uploaded to http://sprunge.us/LCKf Please post the URL in the Armbian forum where you've been asked for.

Why did you not provide output of 'sudo armbianmonitor -u' as requested?

But this will only confuse linux-sunxi community members since no one else knows about H64 existence (and at least I only know of Remix Mini, Merrii's Nobel64 dev board and Allwinner's own green thing -- did you spot more H64 devices?)

Soon we might know a bit more. Icenowy holds a Pine H64 prototype board in her hands already

After latest armbian-config updates the following will now also be tweaked if OMV is installed this way: Disable Armbian's log2ram in favour of OMV's folder2ram Device workaround for Cloudshell 1 (checks presence on USB bus -- for this to work the Cloudshell 1 must be connected when installing OMV!) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working -- for this to work the Cloudshell 2 must be connected when installing OMV!)) Cron job executed every minute to improve IO snappyness of filesharing daemons and moving them to the big cores on ODROID XU4 Making syslog less noisy via /etc/rsyslog.d/omv-armbian.conf So only remaining difference to the 'dedicated' OMV images is now the following: The dedicated OMV images set the correct timezone at first boot replace swap entirely with zram limit rootfs resize to 7.3 GB and automatically create a 3rd partition BTW: There is currently no OMV uninstall routine and there will most probably never be one. While you could probably succeed with an 'apt purge openmediavault' this is also not recommended since too many leftovers will remain. If for whatever reasons after installing OMV you want to stop using it it's strongly recommended to start over from scratch with a freshly burned new image.

The filesystem on your SD card is most probably corrupted and already set to read-only. Please use 'Google site search' in the upper right corner and search for 'authentication token manipulation error'.

UNBELIEVABLE! Instead of providing information you still only write essays with personal Blah blah and provide screenshots where you censor the most important information (the kernel version!!!!) away. We provide both a stable Xenial with 3.4.113 kernel and a stable Xenial with 4.x kernel and the debug output would allow us maybe to get a clue what's going on TO IMPROVE ARMBIAN (that's all I'm interested in).

XU4 can only boot from the red eMMC modules: https://forum.odroid.com/viewtopic.php?f=139&t=19929#p134291 So unfortunately you bought the wrong one (black for ODROID C2?)

Anyone already tried nand-sata-install with Stretch? I did before and it seems DEST=$(df -BM | grep ^/dev | grep ${TempDir}/rootfs | awk '{print $4}' | tr -cd '[0-9]. \n') failed since ${TempDir}/rootfs wasn't mounted at this stage (sorry, I wiped already the installation out, accidentally closed the Terminal Windows and didn't had a 2nd look).

Samsung eMMC sold by Hardkernel doesn't work with Samsung SoCs used by Hardkernel (the primary bootloader can't cope with it). It seems you bought the wrong color...

What a mess. You still do not provide any information NEEDED. No one except you knows what you consider being 'the Stable Build'. We provide a couple of different OS images, some based on Debian, some on Ubuntu, some with 3.4 kernel, some with 4.11 kernel, some with 4.13 kernel. What are you using? No one except you knows. Instead of writing essays you could've provided output from armbianmonitor -u already (yeah, from whatever you call 'Stable Build' NOW of course!) Background info:

I think guessing is just a waste of time. I already asked for real information but as usual in this forum this gets ignored