wildcat_paris

confirmed.
[gr@server1604:~] $ wget http://mirror.igorpecovnik.com/Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z --2016-06-27 14:07:40-- http://mirror.igorpecovnik.com/Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z Resolving mirror.igorpecovnik.com (mirror.igorpecovnik.com)... 185.94.112.69 Connecting to mirror.igorpecovnik.com (mirror.igorpecovnik.com)|185.94.112.69|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 176835029 (169M) [application/x-7z-compressed] Saving to: 'Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z' Armbian_5.14_Orangepi_Ubuntu_xenia 100%[================================================================>] 168.64M 11.1MB/s in 15s 2016-06-27 14:07:55 (10.9 MB/s) - 'Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z' saved [176835029/176835029] [gr@server1604:~] $ 7z t Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z 7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,4 CPUs) Processing archive: Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z Error: Can not open file as archive is there any issue with "Length: 176835029 (169M) [application/x-7z-compressed]"?

Also slow as hell. SanDisk gets interesting when choosing Extreme Pro or Plus. Best buy at the moment are Samsung EVO with 32 or 64 GB on boards like Oranges where sequential transfer speeds are limited by the host's SDIO implementation. Since they're both cheap and show excellent random IO performance while being fast enough when it's about sequential transfer speeds: http://forum.armbian.com/index.php/topic/954-sd-card-performance/

Yeah i guess you can add the [sOLVED] to it.
I'll see if i cant get em to let me pay an extra dollar to upgrade to a "SanDisk microSDHC Mobile Ultra 8GB (Class 10) 48MB/s" card instead and try with that.

Well NFS works realy well for what i intend to use it for

I just whent with a kingston sd card since speed was not my main consern since the whole plan was to use the cubieboard with a harddrive running armbian and NFS it over to the RPi3 and OPiPC for some of the heavy stuff.
Running F3 now, will post result soon.

Edit:
Getting errors at the end of the sd card ( at 99.3% in F3. ).
So i'll guess a trip to my local computer store for a warranty issue and get it replaced.

dmesg output:
[4509220.766159] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230500) [4509220.766233] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230530) [4509220.766278] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230560) [4509220.766322] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230590) [4509220.766363] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230620) [4509220.766404] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230650) [4509220.766446] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230680) [4509220.766488] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230710) [4509220.766530] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error -5 writing to inode 18 (offset 983425024 size 2572288 starting block 230740)

Did you went through these steps already? https://github.com/igorpecovnik/lib/wiki/Getting-started#how-to-prepare-sd-card
 
(I'm talking about the 'Boot problems? How to ensure your SD card is ok' steps and what sort of cards we recommend)
 
BTW: Since you have a serial console attached and get messages back from u-boot ('Card did not respond to voltage select!' or 'Could not determine boot source') this means that u-boot starts but then has trouble to figure out how to proceed. Never seen that myself but my 'workaround' would be to buy a new Samsung EVO and try it again with this (never trying out old and obviously ultra slow cards like you do -- 5 MB/s writing speed sounds to me like 'totally insufficient SD card used')

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

Okay, cool!  I did some tinkering.  It looks like using the GitHub wiki for the Single Point of Truth for the docs would work really well.
 
here's my findings:
 
you can SSH clone with your keys by inserting wiki in the main repo clone url (wiki gui only gives you https clone option) The raw wiki markdown files are named the same as the title, with no extra prefixes or suffixes The default wiki sidebar displays pages in a sorted fashion.  This allows us to rely on a naming convention to keep things grouped and allow for inserts direct access to the repo lets you add non-wiki files... ex: mkdocs.yml can reside within the wiki repo, along with style sheets etc

Non-free firmware package was removed from Xenial due to license issues. Since it doesn't have any dependencies, you can manually install package, for example, for Wily.
 
For build-dep you have to uncomment or add deb-src entries for each deb entry, check this for example. 
 
SHA1 is considered "not secure enough" currently, new APT keys should use more secure hashing algorithms. It is just a warning though, it should not affect anything.

On Orange Pi One, Lite and NanoPi M1 we currently have the ability to let VDD_CPUX voltage switch between 1.1V and 1.3V. With our current settings we switch at 912MHz CPU clockspeed from 1.1V to 1.3V. The higher the clockspeed the higher VDD_CPUX (this is the voltage the CPU cores are fed with) has to be to let the SoC work reliable. But on the other hand the higher VDD_CPUX is set the hotter the SoC gets and the earlier throttling will jump in.
  So knowing at which clockspeed H3 still works reliable at the lowest possible VDD_CPUX voltage (in the case of the aforementioned boards only 1.1V or 1.3V are available) can help with overall performance since throttling gets more efficient.   Since some users reported that they can run their OPi Ones with modified settings at 1200 MHz while staying at 1.1V and I just tested successfully 1344 MHz at 1.3V and it's known that these tresholds depend on the SoC/board in question, I quickly evaluated how to provide a tool that would enable users of OPi One, Lite and NanoPi M1 to check their boards limit by running a set of tests in an unattended way to determine  
highest clockspeed at which the SoC works reliable at the lower VDD_CPUX voltage highest clockspeed at which the SoC works reliable at the upper VDD_CPUX voltage The problem here is reliability. Most overclockers don't care, they're happy to fry their boards idling around at insane high clockspeeds (plain moronic since when the board is idle clockspeeds and voltages can be adjusted to the minimum) and simply don't give a shit that when they put some load on their devices that they get instable, data corruption occurs or even tasks or the whole system crash/hang.    What we try to provide are sane settings that don't affect reliability but provide better performance. Unfortunately that means that this requires some amount of testing (and also adjusted settings, a heatsink and maybe even a fan). The old approach is outlined here: https://linux-sunxi.org/Hardware_Reliability_Tests#CPU (most of the people forget the most important part: Run cpuburn-a7 in parallel on all CPU cores since otherwise test results are 100% worthless)   In the meantime we found another tool that is pretty cool to detect undervoltage situatios: A highly optimized Linpack build: https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-195928362 (with this approach we optimised dvfs/cpufreq settings for Pine64 3 months ago already)   So all that's needed would be an adjusted Armbian image (or tools) that contains this specific Linpack build to run the tests comes with adjusted THS settings to prevent throttling comes with adjusted dvfs settings to stay as long as possible at the lower VDD_CPUX voltage walks in an automated fashion through these clockspeeds: 912000 960000 1008000 1056000 1104000 1152000 1200000 1248000 1296000 1344000 checks /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state prior to a test and afterwards -- if anything changed then throttling occured and the results have to be thrown away (warning message to the user: improve heat dissipation otherwise test is useless) check Linpack output for data corruption If Linpack reports corrupted data, then that specific clockspeed at this moment is known to work not reliably with just 1.1V. So at this moment the DVFS settings have to be adjusted to the CPU clockspeed of the last working test since we need some safety headroom in script.bin (the LV2_freq parameter as can be seen below), then the board has to be rebooted and the current and the missing clockspeeds have to be tested now with 1.3V VDD_CPUX. When Linpack again detects an error then the maximum clockspeed this H3 can be driven with is also known.   So in case the first fail happens at 1056 MHz then in script.bin 'LV2_freq = 1008000000' has to be set. After exchanging that, rebooting and testing again when the next fail happens at 1344 MHz then the last passing CPU clockspeed is the maximum clockspeed that H3 should be allowed to run at. So the aforementioned example results would allow the user to use these three modifications in the productive script.bin he normally uses: max_freq = 1296000000 LV1_freq = 1296000000 LV2_freq = 1008000000 And in /etc/default/cpufrequtils this can be set: MAX_SPEED=1296000 (all other settings remain the same, it's just the adoption of this device dependent test that showed that this specific H3 becomes instable with 1.1V at 1056 MHz and 1.3V at 1344 MHz. Also normal throttling settings aren't affected since the reliability testing )   Different boards will fail at different clockspeeds (already confirmed! When we started to support OPi One in Feb I accidentally deactivated switching to the higher VDD_CPUX voltage and several users reported that they even got in trouble simply booting the board since kernel panics happened early in the boot stage!). So this is a tool that has to run on each board individually.   Prerequisits:   Replace these 3 sections with the following in script.bin [ths_para] ths_used = 1 ths_trip1_count = 6 ths_trip1_0 = 95 ths_trip1_1 = 96 ths_trip1_2 = 97 ths_trip1_3 = 98 ths_trip1_4 = 99 ths_trip1_5 = 105 ths_trip1_6 = 0 ths_trip1_7 = 0 ths_trip1_0_min = 0 ths_trip1_0_max = 1 ths_trip1_1_min = 1 ths_trip1_1_max = 2 ths_trip1_2_min = 2 ths_trip1_2_max = 3 ths_trip1_3_min = 3 ths_trip1_3_max = 4 ths_trip1_4_min = 4 ths_trip1_4_max = 5 ths_trip1_5_min = 5 ths_trip1_5_max = 7 ths_trip1_6_min = 0 ths_trip1_6_max = 0 ths_trip2_count = 1 ths_trip2_0 = 105 [cooler_table] cooler_count = 8 cooler0 = "1344000 4 4294967295 0" cooler1 = "912000 4 4294967295 0" cooler2 = "768000 4 4294967295 0" cooler3 = "648000 4 4294967295 0" cooler4 = "480000 4 4294967295 0" cooler5 = "480000 3 4294967295 0" cooler6 = "480000 2 4294967295 0" cooler7 = "480000 1 4294967295 0" [dvfs_table] pmuic_type = 1 pmu_gpio0 = port:PL06<1><1><2><1> pmu_level0 = 11300 pmu_level1 = 1100 max_freq = 1344000000 min_freq = 480000000 LV_count = 5 LV1_freq = 1344000000 LV1_volt = 1300 LV2_freq = 1296000000 LV2_volt = 1100 LV3_freq = 912000000 LV3_volt = 1100 LV4_freq = 648000000 LV4_volt = 1100 LV5_freq = 480000000 LV5_volt = 1100 Can be done by bin2fex /boot/bin/orangepilite.bin /boot/bin/orangepilite_test.fex [edit /boot/bin/orangepilite_test.fex] fex2bin /boot/bin/orangepilite_test.fex /boot/bin/orangepilite_test.bin ln -sf /boot/bin/orangepilite_test.bin /boot/script.bin Then replace /etc/default/cpufrequtils with ENABLE=true MIN_SPEED=480000 MAX_SPEED=912000 GOVERNOR=performance Package Linpack to be executed automatically.   Put the whole testing stuff either into check_first_login.sh so users just have to download this image, replace SD card and let their board run the tests unattended. Or provide the whole stuff as a tool that can be run (downloading the Linpack package, adjusting script.bin, rebooting if necessary and adjusting the originally used script.bin with the new settings)   Important: When testing through the individual clockspeeds (912000 960000 1008000 1056000 1104000 1152000 1200000 1248000 1296000 1344000) the speed can be set with echo $cpufreq >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq After the new clockspeed has been set, immediately save the contents of /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state, then run Linpack and afterwards compare again. If contents differ, throttling happened and the results are worthless! Since we want to test reliability of clockspeed X but throttling jumped in and we tested partially a lower clockspeed in reality.    Why do I write this here in developer forum? Adjusting dvfs operating points on Orange Pi One, Lite or Nano Pi M1 is easy since the voltage regulator here only switches between two voltages. Easy to start with IMO we should provide tools to improve performance behaviour of our supported boards. Performance on nearly every more modern SoC we support is related to thermal issues. Throttling prevents CPU/GPU cores running at full speed, high VDD_CPUX voltage negatively affects this since the higher the voltage, the more heat, the more throttling, the less performance VDD_CPUX voltage when set too low affects reliability. Since the cheap SoCs we deal with aren't 'factory tested' that much it's an individual job of the SBC's owner to test through possible dvfs operating points to determine best voltage settings (as low as possible -- so that reliability isn't affected) The whole testing process when started from scratch is really time consuming (eg. compiling the necessary Linpack version) and might be frustrating (please read through https://github.com/longsleep/build-pine64-image/pull/3 to get the idea how long it took to convince other devs to test correctly and to refrain from the idea to unlock clockspeeds too high) So it would be great if we as Armbian team could provide a test image or bundled tools that ease this process. Nearly all more recent boards we support suffer from throttling issues and by enabling our users to fine tune dvfs settings using Armbian means also automagically 'more performance' with full load workloads.   IMO it would be nice to add an additional armbian-test-reliability package to our repo containing scripts/tools to help testing Linpack as used for undervoltage checking (this and the next tool can also be used on ARMv8/64-bit systems since the 32-bit variants are more demanding!) cpuminer since this tools contains a benchmark mode that make testing through different settings more easy since you get the result of different dvfs/throttling settings directly as a performance ratio. Also if someone claims this task starting to play with such a limited voltage regulator as present on the little Oranges eases getting results quickly. It gets a bit more complicated if we want to provide the same for the larger Oranges that use the SY8106A voltage regulator that can adjust VDD_CPUX settings in 20mV steps (or any other board that would also benefit from 'per board optimized dvfs operating points').

@tkaiser
I want to claim last task you posted - armbian-test-reliability.
I have 1pcs of Orange Pi One, 15pcs of Orange Pi PC and 2pcs of Orange Pi PC Plus.
I have never tried to build my *.deb package but I like hw testing and scripting...
Due date? 1..2 weeks? I must collect informations what can I get and what I am missing/do not know.
I will let you know tomorrow.

Is it possible open ttyUSB0 with 115200 baud rate but its work incorrect and getting error about incorrect baud rate, example after newline character I lose data

Seems to be working now. Thank you!

I guess we forgot/failed to merge configuration. There is no other way than recompile kernel with proper configuration - to enable what's missing. I own one XU4 and that one is serving this forum so can't do the testing but will try to prepare a kernel update ASAP.

A last update when to choose better a different device. As said in the last post there is some hope that Allwinner will release a cheap quad core A20 successor that will be again SATA capable. A20's SATA implementation is NQC ready so especially random IO benefits from combination of SATA and a fast SSD. Unfortunately I only have a rather slow SSD lying around to test with
Model Family: Samsung based SSDs Device Model: Samsung SSD 840 EVO 120GB Firmware Version: EXT0BB0Q User Capacity: 120,034,123,776 bytes [120 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Fri Jun 24 14:17:04 2016 UTC SMART support is: Available - device has SMART capability. SMART support is: Enabled But here we go: still testing with A20 based pcDuino3 Nano running at 960 MHz CPU, 408 MHz DRAM, performance governor and 4.6.2 kernel:
 
SSD connected to SATA (A20 is known for slow sequential write performance while reads can exceed 200MB/s): random random kB reclen write rewrite read reread read write 102400 4 15763 20117 42851 43604 27816 19619 102400 16 27910 31112 106510 107041 78693 31509 102400 512 38375 38832 206048 206948 203762 38885 102400 1024 38733 39123 211012 212564 210230 39032 102400 16384 39378 39348 225381 227301 227189 39331 2048000 16384 39464 39501 160257 170876 As a reference some overclocking results from a year ago (same SSD, same board): http://forum.lemaker.org/forum.php?mod=redirect&goto=findpost&ptid=12167&pid=66512
  Same SSD, same setup, but now UAS used: 152d:3562 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 480M random random kB reclen write rewrite read reread read write 102400 4 7124 7901 8340 9410 7959 7926 102400 16 18734 21132 21238 21222 18935 21015 102400 512 35315 36161 36435 36605 37525 35993 102400 1024 34190 34881 38668 38587 38342 34920 102400 16384 36943 37217 39472 39546 39564 37158 2048000 16384 37426 37861 36412 36480 USB Mass storage:
04fc:0c15 Sunplus Technology Co., Ltd SPIF215A SATA bridge /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M random random kB reclen write rewrite read reread read write 102400 4 5206 6333 6367 6386 6368 6376 102400 16 15873 17997 18252 18194 18280 18118 102400 512 33996 34267 35473 35673 35653 34103 102400 1024 34269 34386 36021 35950 36105 34527 102400 16384 36207 36364 37482 37502 37381 36399 2048000 16384 34864 35305 31494 31466 Conclusion:
 
Many small file accesses and especially random IO (database server for example): Better choose a slower SoC with the faster storage implementation!

i made my own cable from an old usb cable and a power connector of the correct size.
 
i can confirm that:
a. with a good quality 2a psu i get no power or stability issues
b. with a crappy 2a psu - its unpredictable
c. With a good quality 1a psu its works fine.

@rsegoly,
original power adapter I bought together with Orange Pi One has no issues. When I tried some cable to power it from usb it failed even I feed it with about 6V. Reason is probably thin cable and usb male <=> female conector resistance. So basically I can only confirm what @tkaiser said.

okay.. I'll volunteer now...based on my understanding of this thread
 
A quick recap and some strategic questions about the direction we're heading.
 
Documentation will be provided in the following formats:
HTML / HTML Site w/ clean url ex: http://armbian.com/documentation/userdocs PDF (style of user manual) MD (github convenience  -- automatically renders individual files) Following tools will be used:
mkdocs htmldoc Behavioral Requirements
Functional TOC in PDF Search (for html site?) Questions:
Should we move documentation to a separate repo and update lib/documentation to be a git submodule? Where should the documentation output be stored (html/pdf)? Should documentation resources automatically be updated after every documentation commit?

Just a note to confirm i received my board yesterday morning.

I've received my OPi-Plus-2E this afternoon and done a fresh new Mainline build 5.14 kernel 4.6.2
 
I've soon discovered that 8189fs was not part of my fresh build.
I've done the same thing I did few days ago with my OPi-Lite : patch DTS and build rtl8189fs drivers borrowed from Legacy after apply Hans equivalent patch suggested to me by @jernej, and got it working.
I will probably probably have to prepare real patches for the official builds soon.
 
I've seen that eth0 is also not working, but I didn't investigated yet...
There is also the eMMC not present, but I think this one is related to new patches needed, I've seen several post on linux-sunix mailing list.
 
BTW, does someone have a link to schematic/board-layout for the OPi-Plus-2E board ?
(I didn't find it, I have all of them for others board I have, PC, One, Lite, but I wish to get this one as well as OPi-PC+ that I should received next week)

thanks

Minor detail - let user pick their favorite editor, "edit file /etc/exports" should be simple enough.
 
They are insecure anyway since you don't configure authentication or access limiting 
 
fsid=num|root|uuid NFS needs to be able to identify each filesystem that it exports. Normally it will use a UUID for the filesystem (if the filesystem has such a thing) or the device number of the device holding the filesystem (if the filesystem is stored on the device). As not all filesystems are stored on devices, and not all filesystems have UUIDs, it is sometimes necessary to explicitly tell NFS how to identify a filesystem. This is done with the fsid= option. For NFSv4, there is a distinguished filesystem which is the root of all exported filesystem. This is specified with fsid=root or fsid=0 both of which mean exactly the same thing. Other filesystems can be identified with a small integer, or a UUID which should contain 32 hex digits and arbitrary punctua†tion. Linux kernels version 2.6.20 and earlier do not understand the UUID setting so a small integer must be used if an fsid option needs to be set for such kernels. Setting both a small number and a UUID is supported so the same configuration can be made to work on old and new kernels alike. TL;DR from my experience - explicit fsid parameter is needed when underlying filesystem doesn't support UUID (i.e. tmpfs)
Edit: I mean for non fsid=0/fsid=root shares.
 
       nohide This option is based on the option of the same name provided  in               IRIX  NFS.  Normally, if a server exports two filesystems one of               which is mounted on the other, then  the  client  will  have  to               mount  both filesystems explicitly to get access to them.  If it               just mounts the parent, it will see an empty  directory  at  the               place where the other filesystem is mounted.  That filesystem is               "hidden".               The  nohide  option  is  currently only effective on single host               exports.  It does not work reliably with  netgroup,  subnet,  or               wildcard exports. User ID Mapping nfsd bases its access control to files on the server machine on the uid and gid provided in each NFS RPC request. The normal behavior a user would expect is that she can access her files on the server just as she would on a normal file system. This requires that the same uids and gids are used on the client and the server machine. This is not always true, nor is it always desirable. Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anony†mous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash. By default, exportfs chooses a uid and gid of 65534 for squashed access. These values can also be overridden by the anonuid and anongid options. Finally, you can map all user requests to the anonymous uid by specifying the all_squash option. Here's the complete list of mapping options: root_squash Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff. no_root_squash Turn off root squashing. This option is mainly useful for disk†less clients.        -a     Export or unexport all directories.        -r     Reexport all directories, synchronizing  /var/lib/nfs/etab  with               /etc/exports   and  files  under  /etc/exports.d.   This  option               removes entries in /var/lib/nfs/etab  which  have  been  deleted               from /etc/exports or files under /etc/exports.d, and removes any               entries from the kernel export table which are no longer valid.   "exportfs -ra" is enough to apply any changes made in /etc/exports
Restarting nfs-kernel-server may be needed to apply changes made in /etc/default/nfs-kernel-server or to disconnect already connected clients
 
Not exactly. This is not documented well, but I meant building image with "ROOTFS_TYPE=nfs" option, which creates small SD card image and rootfs archive. Edit boot script on SD, deploy and export rootfs on a server and you are done.

We will be configuring in a mode that allows both NFSv3 and NFSv4 clients to connect to access to the same share.
 
Q. What are the benefits of an NFS share over a SAMBA share?
A. This would take an article in itself! But as a brief reasoning, In a closed network (where you know every device), NFS is a fine choice. With a good network, throughput it disgustingly fast and at the same time less CPU intensive on the server. There are a lot of applications that support NFS "Out of the box" KODI being a common example. It's very simple to set up and you can toggle readonly on shares you don't need to be writeable. It only gets complicated if you want to start layering on security through LDAP/gssd. It's capable of very complex and complete security mechanisms... But you don't need them in this scenario.
 
Q.   Why are we doing this and not limiting to NFSv4?
A.   Flexibility, this will allow almost any device you have that supports reading and mounting NFS shares to connect and will also allow the share to be used to boot your clients from which will allow fast testing of new kernels etc.
 
Q. Why would I want to do this?
A. You can boot your dev boards from the NFS share to allow you to test new kernels quickly and simply
A. You can map your shared locations in Multimedia clients quickly and easily.
A. Your friends like to struggle with SAMBA so you can stay native and up your "geek cred"
 
This HOWTO: will be split into distinct areas,
     "Section One" Install and Configure the server
     "Section Two" Configure client access.
     "Section Three" Boot from NFS share. (a separate document in its own right that will be constructed shortly).
 
 
"Section One" Install and Configure the server

Install NFS Server and Client
apt-get update ; apt-get upgrade ; apt-get install autofs nfs-kernel-server nfs-common --install-recommends -f -y ; Now reboot
sync ; reboot ; I will be making the following assumptions (just amend to suit your environment)
1. You already have a working system!
2. Your media to be shared is mounted via fstab by its label, in this case Disk1
3. The mounted disk resides in the following folder /media/Disk1
4. this mount has a folder inside called /Data

Configure NFS Server (as root)
cp -a /etc/exports /etc/exports.backup
Then open and edit the /etc/exports file using your favourite editing tool:
Edit and comment out ANY and ALL existing lines by adding a “#†in front the line.
Setup NFS share for each mounted drive/folder you want to make available to the client devices
the following will allow both v3 and v4 clients to access the same files
# Export media to allow access for v3 and v4 clients /media/Disk1/Data *(rw,sync,insecure,no_root_squash,no_subtree_check,nohide) Explanation of above chosen parameters
rw – allows read/write if you want to be able to delete or rename file
async – Increases read/write performance. Only to be used for non-critical files.
insecure – This setting allow clients (eg. Mac OS X) to use non-reserved ports to connect to the NFS server.
no_subtree_check – Improves speed and reliability by eliminating permission checks on parent directories.
nohide - makes it visible
no_root_squash - *enables* write access for the connecting device root use on a NFS share
 
Further explanations if you so desire can be found in the man page for NFS or from the following link
http://linux.die.net/man/5/exports

Starting / Stopping / Restarting NFS
Once you have setup NFS server, you can Start / Stop / Restart NFS using the following command as root
# Restart NFS server service nfs-kernel-server restart # Stop NFS server service nfs-kernel-server stop # Start NFS server # needed to disconnect already connected clients after changes have been made service nfs-kernel-server start Any time you make changes to /etc/exports in this scenario it is advisable to re export your shares using the following command as root
export -ra Ok now we have the shares setup and accessible, we can start to use this for our full fat linux/mac clients and or configure our other "dev boards"  to boot from the NFS share(s).


"Section Two" Configure client access.
 
We now need to interrogate our NFS server to see what is being exported, use the command showmount and the servers ip address
showmount -e "192.168.0.100" Export list for 192.168.0.100: /mnt/Disk1 * In this example it shows that the path we use to mount or share is "/mnt/Disk1" (and any folder below that is accessible to us)
NFS Client Configuration v4 - NFSv4 clients must connect with relative address
Use the mount command to mount a shared NFS directory from another machine, by typing a command line similar to the following at a terminal prompt as the root user (where 192.168.xxx.xxx is the server I.P. address)
mount -t nfs -o vers=4 192.168.xxx.xxx:/ /home/â€your user nameâ€/nfs4 The mount point directory /home/â€your user nameâ€/nfs4 must already exist and there should be no files or subdirectories in the /home/â€your user nameâ€/nfs4 directory.
 
Another way to mount an NFS share from your *server is to add a line to the /etc/fstab file. The basic needed is as below
192.168.xxx.xxx:/    /home/â€your user nameâ€/nfs4    nfs    auto    0    0 NFS Client Configuration v3 - NFSv3 clients must use full address
Use the mount command to mount a shared NFS directory from another machine, by typing a command line similar to the following at a terminal prompt as the root user (where 192.168.xxx.xxx is the server I.P. address)
mount -t nfs -o vers=3 192.168.xxx.xxx:/media/Disk1/Data /home/â€your user nameâ€/nfs3 The mount point directory /home/â€your user nameâ€/nfs3 must already exist and there should be no files or subdirectories in the /home/â€your user nameâ€/nfs3 directory.
 
"Section Three" Boot from NFS share.
please refer to this document  on creating the image https://github.com/igorpecovnik/lib/blob/master/documentation/main-05-fel-boot.md - there will be an additional HOWTO & amendment to this HOWTO to cover this topic in more detail.

Hmm... quick test using MkDocs and htmldoc (without adjusting anything):
for i in main* ; do NewSite="http://127.0.0.1:8000/$(echo $i | sed 's/\.md/\//')"; Sites="${Sites}${NewSite} "; done htmldoc ${HTMLDOCOptions} --book --numbered --toclevels 3 -f ../armbian-userdoc.pdf ${Sites} Someone familiar with MkDocs could tweak HTML/CSS quickly and adding title page (with logo) and headers/footers in htmldoc is also easy: http://kaiser-edv.de/tmp/HbBtyV/armbian-userdoc.pdf  (different structure levels ruin the 'book/TOC structure')

Still grokking big picture -- interest piqued.   

I can take a look at it.

@tk, guide the user to the manual /wiki before answer it in the forum.
Kind if easy, but u must be follow such a 'rule'
 
Edit Tido:
Kind of easy, but u must follow such a 'rule'
 
 
 
@WP, thanks for edit - bloody cell phone :-)