tkaiser

Ok, you're running off a Samsung 64 GB SD card and currently no eMMC is connected to the board. Please shut down the board, attach the eMMC, adjust the switch so it still will boot from SD card, boot again and then wget https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/sbin/nand-sata-install sudo /bin/bash ./nand-sata-install Choose there 'Install and boot from eMMC', choose ext4 as format, let the eMMC been wiped out automagically and the bootloader been updated, then wait for the installation to be transferred, power down the board, adjust the switch to boot from eMMC now, remove SD card, boot and provide output from 'armbianmonitor -u' again. We'll talk in half an hour again!

Well, if there's mPCIe we can attach anything we want that's available with mPCIe interface using the PCIe data lines (read as: no LTE/WWAN modems since they use the form factor but need USB2 data lines on pins 36/38 of the mPCIe connector). But we should keep the following in mind: We've no idea how well this PCIe implementation performs (according to linux-sunxi IRC it's licensed Synopsys/DesignWare IP so should be ok). With PCIe 2.x we're talking about a maximum bandwidth of ~400 MB/s (5 GT/s using 8b10b encoding) per lane and there is just a single lane. We know that with x86 or eg. Marvell's PCIe implementation it's possible to saturate this but other/older implementations like i.MX6 show way lower numbers: https://forum.armbian.com/topic/4845-marvell-based-4-ports-mpci-sata-30/ Driver issues: the last Allwinner H SoC BSP (the one for H5) wasn't that great, I'm not aware of a single community member trying to make it usable (as it happened with A64 BSP 9 months before, but that was at another time when Allwinner + 64-bit was new and exciting). So if this repeats with H6 now then good luck since we would've to wait until mainline kernel support for H6 will be ready (the bad news here according to people in contact with Allwinner: a lot of IP blocks in H6 are said to be updated so that might require a lot of new coding efforts, maybe sometimes even from scratch. Bonus: PCIe in the available H6 user manual is not much documented) The whole setup: The SATA card when bought locally (warranty, customs, taxes included) is not really cheap though I bought mine on Aliexpress for less than 35 bucks. Add 4 disks and you need a good and reliable PSU, add 3.5" disks and you even need a dual-voltage PSU able to cope with high 12V peak consumption, you might need to add an enclosure and so on and in the end you're better served buying an HP Microserver -- accepting an idle consumption a lot higher -- or Helios4

Yeah, makes no sense. The eMMC is only fully accessible through SD/MMC host controllers. That means: full access when accessing it seated in the eMMC slot on your ODROID (single board computer -- SBC) full access when accessing it seated in Hardkernel's SD card adapter when using a real SD card slot like the one your ODROID RESTRICTED access with card readers that are USB attached since these add an abstraction layer preventing access to those hidden partitions and u-boot Since it makes absolutely no sense to continue here, please try again with Armbian on eMMC and provide output from 'armbianmonitor -u' (I don't know why this isn't always the first that's asked for since everything else is just a waste of time).

Ah, that explains a lot (eg. me being totally stupid since the card reader in my laptop is USB3 attached and I even passed it through to Linux VMs running here never thinking about that USB vs SD/MMC could make the difference)

Most probably it's the '2 GB DRAM' that sells best. Anyway: fixed VDD_CPUX at 1.2V + powering with Micro USB + no Gigabit Ethernet... I'm already out but shouldn't matter that much since the boards are advertised as Android 7.x devices anyway...

I've really not the slightest idea what you're doing or trying to achieve. Since we know in the meantime that you're talking about Hardkernel eMMC and you obviously try to access this on other hosts: there are hidden boot eMMC partitions on these modules that can only be accessed from the Linux running on your SBC when the eMMC is seated there. We even include now in most recent nand-sata-install script an option to update the u-boot sitting in this hidden areas.

Kernel 3.10 is at 3.10.108 in the meantime and also EOL now. And there's really no reason why Armbian should support this board anytime soon or at all as you can easily get from the link I posted above. If Armbian wants to improve IMO a few more boards should be kicked out of support (especially all those that allow for underpowering hassles -- MicroUSB for DC-IN just like this one here too)

Can you provide output from 'sudo armbianmonitor -u' please after you manually adjusted DNS resolving and DNS works? And then for a static IP address assignment why don't you use auto instead? # Wired adapter #1 auto eth0 iface eth0 inet static address 192.168.5.200 netmask 255.255.255.0 gateway 192.168.5.6 dns-nameservers 8.8.8.8 192.168.5.6

I consider the forum search close to unusable especially if you compare with the results from 'Google site search' next to it. And for the devices we deal with there's no hope since search terms with less than 3 characters are ignored, words are combined with a logical 'OR', result list is filtered to 'only recent' by default and so on...

Well, problem has been reported by Hardkernel to them but most probably with wrong description ('We need more than 3 minutes' instead of 'make the bridge behaving SAT compliant everywhere'), TL Lim forwarded JMicron a link I provided and established then a direct contact in parallel. When they got back it seemed they already considered this a bug and not a feature (which could be a valid alternative given drive enclosure manufacturers might prefer sending disks to sleep as soon as possible) You can follow progress here BTW: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?page=4

https://forum.armbian.com/topic/3134-nanopi-a64-board-from-friendlyarm/?do=findComment&comment=24464

Well, I expect the HC2 (or HC1+ or whatever HC$something will be released by Hardkernel the next time) to be fully software compatible. It will be just another variant using the same SoC and a JMicron USB-to-SATA bridge (maybe just like with their Cloudshell 2 using JMS561 which will then lead to the same issues as today with this Cloudshell thing). The thread title there has a reason No, since all the results of our work are still there (we don't fiddle around manually with OS images but each and every improvement gets commited to the build system so everyone on this planet is enabled to build fresh OMV images from scratch as often as he wants to). It's just that there's currently nothing to improve and it also makes no sense to provide more OMV images since every Debian based Armbian image using kernel 4.x can be transformed into an OMV installation with 'armbian-config --> Software --> Softy --> Install OMV' (takes care about almost all the performance tweaks our OMV images contain). To finalize this a summary what 'Armbian + OMV' exactly means and what the result of this 7 month journey was. It was about identifying problems (both technical and user experience) and developing optimal settings for performance and energy efficiency. And now we're there. So if you want to run OMV on an SBC simply check whether the board is supported by Armbian with a recent kernel and you're almost done. If you want to do yourself a favour then click here on GbE (to avoid boards that are bottlenecked by slow networking) and have in mind that some stuff that looks nice on paper like Allwinner's 'native SATA' performs pretty poor in reality (check SBC storage performance overview) While you basically can turn every SBC Debian Jessie or Stretch OS image into either an OMV 3 or 4 installation the real differences are as follows: 1) Armbian as base: we care about kernel support, providing for all relevant platforms pretty recent kernel versions that enable all the features needed by OMV. Difference to other distros or OS images: they often use horribly outdated kernels that lack features needed for OMV working properly (please compare with the OMV related kernel config changes) our OS images contain several performance and/or consumption tweaks, eg. we optimize IO scheduler based on type of storage, we take care about IRQ affinity (on almost all other SBC distros all interrupts are processed on the first CPU core which will result in lower performance) and optimized cpufreq governor settings (allowing the board to idle at minimal consumption but switching to highest performance immediately if needed) We try to use modern protocols, eg. enabling 'USB Attached SCSI' (UAS) where possible while taking care also of broken USB enclosures that get blacklisted automatically. UAS allows for higher USB storage performance with less CPU utilization at the same time. Armbian contains powerful support tools that allow to remotely diagnose problems very easily (only problem: here in the forum we play mind-readers instead of asking for armbianmonitor output all the time) 2) Armbian's OMV/NAS performance/reliability tweaks: we use improved Samba settings to increase SMB performance especially on the weaker boards Several file sharing daemons that usually store caches on the rootfs are forced to use RAM instead (heavily increases performance in some areas and also helps with SD cards wearing out too fast) Enabling driver support for the only two USB3 GbE dongles (ASIX AX88179 and the better RealTek RTL8153) so even boards with only Fast Ethernet or without Ethernet can be used as NAS with those dongles 3) Armbian's OMV integration tweaks: we take care that we set in /etc/default/openmediavault three variables that heavily influence board performance once a user clicks around in OMV's 'Power Management' settings. Without this tweak otherwise OMV defines 'powersave' cpufreq governor which is totally fine on x86 systems but can result in a horrible performance decrease on ARM boards with kernels that then remain all the time on the lowest possible CPU frequency (on some systems like ODROID-XU4 or HC1 this can make a difference of 200 MHz vs. 2 GHz!) we install and enable OMV's flashmemory plugin by default to reduce wear on the SD card and to speed certain things up. WIthout this plugin OMV installations running off SD cards or eMMC might pretty fast fail due to flash media already worn out (way higher write amplification without the plugin will lead to your storage media dying much faster) All these 9 tweaks above make the difference and are responsible for such an 'Armbian OMV' consuming less energy while performing a lot better than distros that ignore all of this. I tested the last months a lot also with other OS images where OMV has been installed without any tweaks and Armbian's way was always way faster (biggest difference on ODROID-XU4 where I tested with OS images that showed not even 50% of our performance). That being said it's really as easy as: Choose a sufficient board (GbE, fast storage) supported by Armbian's next branch (so kernel version recent enough for all features to work), choose either Jessie (for OMV 3) or Stretch (OMV 4) and call armbian-config to let OMV be installed (few minutes on a fast SD card, if you have to wait ages it's highly recommended to throw the SD card away and start over from here). Just as a reference: the dedicated OMV images I generated the last half year do include another bunch of minor tweaks compared to installing OMV with armbian-config: Disable Armbian's log2ram in favour of OMV's folder2ram Automatically setting the correct timezone at first boot based on geo location (IP address) Device support for Cloudshell 2 (checks presence on I2C bus and then install's Hardkernel's support stuff to get display and fan working) Device workaround for buggy Cloudshell 1 (checks presence on USB bus) 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 Replacing swap entirely with zram Limit rootfs resize to 7.3 GB and automatically creating a 3rd partition using the remaining capacity that only needs to be formatted manually and can then be used as a data share All tweaks can be studied here and by using this script as customize-image.sh you can still build fully optimized OMV images for every board Armbian supports with a next kernel branch. And now may I ask a moderator to lock this thread from now on so new issues will be discussed separately? Thank you!

To elaborate on that I just let this check run on two SD cards. Please search in new debug output for the two occurences of '/tmp/armbianmonitor_checks' armbianmonitor_checks_mmcblk1p1_ext4 is a 16 GB SanDisk Extreme Plus the OS is running from. Full capacity is usable and performance pretty nice (also due to ODROIDs having less SDIO bus limitations compared to most other boards we support) armbianmonitor_checks_sda2_btrfs is an 8 GB SanDisk Extreme Pro which is usually also very fast but limited here by the external USB card reader. So if people complain about strange storage related stuff simply always encourage them to run 'armbianmonitor -c' (over night since on slow SD cards this can take ages) followed by 'sudo armbianmonitor -u' to provide results to the forum.

No problems with HC1 since the JMS578 there doesn't show the Seagate behaviour (problem with Seagate disk enclosures is that while they use an ASM1153 bridge chip that is known to work well with UAS their modified firmware screws things up and UAS to work properly would either need some quirks or has to be completely disabled. Unfortunately every new Seagate disk enclosure seems to use same ASM1153 with same branded/broken firmware but uses a new product ID so upstream blacklisting these devices most probably will never work. Check which are the most 'popular' devices in drivers/usb/storage/unusual_uas.h ) JMS578 on the HC1 has a different problem but JMicron is currently working on a fix... I'm in contact with them and they said once they tested a new fully SAT compliant firmware internally they'll send it to me to test...

I think, testing through a 'worst case' scenario would be also or even more interesting. Powering off while the sync call is executed below: dd if=/dev/urandom of=tempfile bs=10M count=100 ; sync BTW: Last year in March and April I also tried very hard to get filesystem corruption on SD cards and simply stopped using 'shutdown' any more. Maybe tested also +100 times, never occured a problem but still this is not a good idea since when filesystem structures are updated at the same time power is lost there will be corruption for sure (and you should have a serial console ready to deal with the 'UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY' situation then)

Armbian implements some basic 'system logging' at every startup and shutdown and contains a little utility to provide this collected information combined with some more useful debug info from user installations. All that's needed is executing 'sudo armbianmonitor -u' (or armbian-config --> Software --> Diagnostics) and then all this support related information is uploaded to an online pasteboard service automagically (see example output) How to interpret this wall of text? The output is best read from bottom to top since the most important information is collected during upload: At the bottom /proc/interrupts contents to check for IRQ affinity problems (interrupt collissions on some CPU cores negatively affecting performance) Then last 250 lines dmesg output are included. Here you might find important information wrt the last (kernel) events that happened on the machine uptime output including average load statistics (1, 5 and 15 min) free output telling how much physical memory is available and how much swap and/or zram is used (you need to look directly above whether zram is active or not to interpret the 'Swap:' line) vmstat output contains virtual memory usage information since last reboot iostat output contains the same but allows for a 'per device' view since all devices are listed with individual statistics (so it's easy to spot IO bottlenecks by looking at these numbers and also looking at %iowait value) 'Current system health' displays what the system is actually doing while uploading the debug log (on systems where DC-IN monitoring is available also allowing for underpowering diagnosis -- if you read here numbers below 5.0V stop reading the log and tell the user to fix his underpowering issues first) In case the installation has been moved from SD card to other storage nand-sata-install.log will be included in the output 'Loaded modules' allow to look for module related problems If it's an Allwinner board running legacy kernel the whole script.bin contents are included 'Installed packages' shows version numbers of relevant Armbian packages 'Group membership of' should list all groups the user is member of. If this line is missing ignore the whole contents and ask the user to re-submit debug info, this time doing it correctly not as root but using 'sudo armbianmonitor -u' (group memberships are important to understand certain problems, eg. users not being member of audio group won't have success getting noise out of their devices) If the board is PCIe capable list of attached PCIe devices is included The lsusb output lists all connected USB devices and also information about speed (12M, 480M, 5000M) and protocol/connection details (mass-storage vs uas for example) If the user installed the lshw utility and verbosity is set to 4 or above in /boot/armbianEnv.txt some more disk related information will be included Important: The debug output also contains all collected support files that follow this naming scheme: /tmp/armbianmonitor_checks_* -- so if a user complains about 'transmission so slow' or 'latest files are always missing' ask him to run 'armbianmonitor -c /path/to/torrent-storage' and afterwards 'sudo armbianmonitor -u' without a reboot in between since then the checking results will also be contained. Everything above of this information at the output's bottom is result of regular logging at startup and shutdown (the contents of /var/log/armhwinfo.log). At startup the following items are logged: dmesg output, /etc/armbian-release and /boot/armbianEnv.txt contents, lsusb and lscpu output, /proc/cpuinfo and /proc/meminfo contents, network interface information, available partitions and filesystems, on Allwinner boards where /boot/script.bin points to, some metadata information for all MMC media connected to the host (eg. SD card and/or eMMC) and some system health information. At shutdown iostat, vmstat and free output are added to /var/log/armhwinfo.log as well as the last 100 lines from dmesg output. If these '### shutdown' entries are missing after reboots the system crashed while shutting down.

The proper way to deal with those crappy external Seagate drives is to either create an usbstoragequirks entry in /boot/armbianEnv.txt or let Armbian do this for you (with next gen Armbian images -- new boot script required -- we try to auto-detect these drives and UAS blacklist them automagically but this requires the drive to be connected at boot and at least another reboot in between)

Sure, fix your underpowering problems. I also hope a moderator has splitted the relevant posts here and merges/creates them into just another new thread over at https://forum.armbian.com/forum/31-sd-card-and-power-supply/

This is what I was looking for: /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 12M For whatever reasons that's not Hi-Speed (480Mbps) but so called 'Full-Speed' (12Mbps). The USB-to-SATA bridge you're using (Norelsys) is crap BTW (advertises itself as being UAS capable but isn't and has most probably other flaws as well). Check dmesg output at the bottom please: [19909.593371] usb 8-1: not running at top speed; connect to a high speed hub (no idea why the kernel tells you to 'connect to a high speed hub' since my personal recommendation with Norelsys SATA briges is to throw them away) BTW: If you solved this problem your next challenge will be shitty performance due to NTFS (using FUSE and being slow as hell while fully occupying at least a single CPU core)

I give up finally. So much time went into tools to help supporting user problems while users refuse to use them and provide the needed information. The link above asks for the output of 'armbianmonitor -u' (containing most important info at the end of the uploaded stuff eg. 'lsusb -t' output). Same with those useless 'headers' in each and every subforum. They are obviously invisible to users. What an insane mess...

https://forum.armbian.com/announcement/5-2-make-sure-to-collect-and-provide-all-necessary-information/

Thank you, that looks ok (well, I was asking for a reason: when I started with Bananas few years ago being absolutely clueless and not knowing how badly they are designed with Micro USB as power source I managed to poweroff my Banana Pi simply by connecting my Apple keyboard with optical mouse connected to the keyboard's internal USB hub -- the consumption peak led to a brownout every time). So next step for you is to diagnose what's going on, maybe the 'watch + dmesg' recipe over there helps with this...

This is about filesystem corruption and on the 1st generation Raspberries (A and B, not including A+/B+ and all the later variants!) there was a nice underpowering <--> SD card failure relationship: https://tech.scargill.net/a-question-of-lifespan/#comment-34055 (reading through all the comments there is also interesting since you can easily see that a lot of Raspberry Pi users consider SD cards totally unreliable). That being said if you do not properly shutdown an Armbian installation filesystem corruption can occur as well though I never ran into this if not the SD card itself became corrupt (they all do after some time but this is just due to wear out or physical damage -- I just cooked one to death recently). Armbian's rather high commit interval of 10 minutes might add to this behaviour as well as an fsck running at boot if necessary (initrd). But if you have to deal with power losses you should not trust in filesystem self-healing but prepare for the worst (using a read-only rootfs, just search the forum for recipes) Not on any of the boards Armbian supports. The only SBCs I own that really need a FAT partition to boot are Raspberry Pis since there the primary OS that runs on the VideoCore IV can only be loaded from FAT due to the 1st stage bootloader living in the SoC not able to deal with anything else (that's also where the 'use SD-Formatter and format your SD card prior to usage' BS originates from since Raspberry Pis can not deal with ExFAT too while all modern SD cards exceeding a certain capacity ship preformatted with ExFAT. SD-Formatter is only needed with Raspberries Pi, SDXC cards and when the user wants to run NOOBS)

So it's time to check the voltage available to your setup. Please repeat the test with the same image without the USB hub connected, then execute 'sudo armbianmonitor -m' in a SSH shell, wait 10 seconds and then connect the hub. Please provide armbianmonitor output here afterwards.