NAS Dock v1.2 for Nano Pi NEO / NEO 2 is, as the name implies, a complete mini NAS kit for 2.5″ drive for NanoPi NEO or NEO 2 board. The NEO 2 board is strongly recommended, since it’s not much more expensive, but should deliver much better results due to its Gigabit Ethernet interface. I’ve received two of those kits together with several other boards & accessories from FriendlyELEC, and today I’ll show how to assemble the kit, configure OpenMediaVault, and run some benchmarks.
NAS Kit V1.2 Assembly with NanoPi NEO 2 Board
The only extra tool you’ll need is a screwdriver, and potentially a soldering iron as we’ll see further below.
The metal box is stuff wih accessories so the first thing is to open one or two sides to take out the content. We have the mainboard, NanoPi NEO back plate, NanoPi NEO 2 back plater, a heatsink and thermal set, and a set of 5 screws to tighten the hard drive which mean there’s one extra screw. FriendlyELEC always adds extra screws, and I find it’s a nice touch, as it can be a real pain if you happen to lose one.
Let’s have a closer look at the “1-bay NAS Dock v1.2 for NanoPi NEO/NEO2” board. We have a UAS capable USB 3.0 to SATA brige chip between the two header for NanoPi NEO board (note that the USB connection will be limited to USB 2.0 since the board only supports that), an LED, a USB 2.0 host port for a printer, WiFi dongle, or webcam, the power switch, the power jack, a 3-pin serial header, an I2C connector for Grove modules, and of course the SATA connector.
There’s not much on the other side of the board, except a CR2032 battery slot for the RTC.
Before going further, you’ll need to go to the Wiki, and get the latest OpenMediaVault firmware, in my case nanopi-neo2_debian-nas-jessie_4.11.2_20170531.img.zip, which I then flashed with Ether program to a micro SD card..
Once this is done, install the heatsink and thermal to your NanoPi NEO 2 board, and insert the micro SD card into the board.
Notice that I also soldered the headers. While it would be obvious to people would have looked at the pinout diagram, I’ve read some people have justed connect the board using the (pre-soldered) 4-pin header, as they may have believed it was a USB header, but it’s just the serial console instead, and obviously the hard drive was not detected. If you don’t feel like soldering the headers to the board yourself, make sure you tick the option “with pin headers soldered” when ordering. It just costs $1 extra.
Now we can insert our board into the “1-bay NAS Dock” board, instead the hard drive, and optionally an I2C module. I connected an I2C OLED display i the picture below for illustrate, as using the display would require cutting out the case. Some people may want to connect an I2C temperature sensor instead.
I used four screws to tighen the hard drive on the other side of the board, and install a CR2032 battery for the real-time clock.
Finally, you’ll need a 12V power supply with at least 1A, but I could not find any (safe) spare ones so I used Maxoak K2 power bank instead, since it can output 12V @ 2.5 A max.
OpenMediaVault Setup on NanoPi NEO 2 Board
So I connected everything, and applied power, but the board would not boot with the Ethernet Link LED blinking in a regular fashion, meaning something was very wrong. So I took out the board, and connected a serial debug board, connect to the console via minicom using 115200 8N1, and that’s what I got:
|
1 2 3 4 |
U-Boot SPL 2017.05 (May 27 2017 - 15:41:23) BOARD: DRAM: 512 MiB Trying to boot from MMC1 |
The boot was just stuck there. I re-inserted the micro SD in my PC, and I could see both boot and rootfs partitions, so everything looked good.
Then I powered the NanoPi NEO 2 board with a 5V/2A power supply only, and the boot succeeded:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
U-Boot SPL 2017.05 (May 27 2017 - 15:41:23) BOARD: DRAM: 512 MiB Trying to boot from MMC1 U-Boot 2017.05 (May 27 2017 - 15:41:23 +0800) Allwinner Technology CPU: Allwinner H5 (SUN50I) Model: NanoPi H5 DRAM: 512 MiB MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 |
Then I went back to the 12V power input on NAS Kit with the power bank and the boot succeeded. Very strange. It turns out the board would not boot most of the time, but the symptoms are not reproducible 100% of the time. This kind of random behavior is usually a timing or distorted signal issue. So I thought the micro SD card might not play well with the board, and the power bank signal might not be so clean. So I first flashed another micro SD card, but same results. I used another 12V/5A power supply, and it did not really help either. Finally, I used another NanoPi NEO 2 board and it appears to be stable.
You can find the board using FriendlyELEC.local if bonjour services are running in your computer:
|
1 2 3 |
ping FriendlyELEC.local PING FriendlyELEC.local (192.168.0.110) 56(84) bytes of data. 64 bytes from 192.168.0.110 (192.168.0.110): icmp_seq=1 ttl=64 time=0.316 ms |
Alternatively, you could check out the IP address in other ways. In my case, I just type friendlyelec.local in Firefox to access the web interface. The default username and password are admin and openmediavault.
After login, you can access the dashboard showing system information, and which services are running. You may want to disable the services you don’t need.
You can go to Storage->Physical Disks to check if your hard drive has been detected. No problem for me here with a 931.51 GiB drive detected.
You may then want to setup a fix IP address. There are various ways to do this but I went to Network->Interfaces and set eth0 to a fixed IP address. You’ll be asked to apply the changes once it’s done.
I also changed the hostname to CNX-NEO2-NAS in the General tab.
After that I decided to address some security issues. First by changing the administrator password in General Settings->Web Administrator Password.
I then went to Access Rights Management->User to find out there were two pre-configured users: pi and fa. I deleted fa user, changed pi’s user password, and added it to ssh group. It’s actually even probably better to just delete both user, and create your own.
The root user is not shown, but you’ll want to login as root through ssh first and change the password, as the default password is fa. Once it’s done, you’ll have better security, and your system should not be easily accessible via basic “hacks”. For more security, you’ll still want to install an RSA certificate. A self-signed one should do if you plan to use it only in the local network, but you may also consider a free Let’s Encrypt certificate instead.
We can now take care of the hard drive. I went to Storage->File Systems, and clicked on +Create file system which will let you choose between BTRFS, EXT3, EXT4, XFS, and JFS. I’ve gone with EXT4 first.
After a few minutes you drive should be formatted, so we can configure network shares. I want to use SAMBA and SFTP to transfer files for the purpose of this review, so I went to Access Rights Management->Shared Folders to add a new share called HDD for the root of of hard drive. You may want to add multiple share if you plan to split videos, documents, music and so on.
I clicked Save, and selected ACL to add permissions to pi and admin users. You can add whatever users you plan to use to access the share.
That share3d folder can now be assigned to the services you plan to use. SFTP is enabled by default when SSH is running, so I create a SAMA/CIFS share by going to Services->SMB/CIFS->Shares to add the share.
Browsing the Network with Nautilus would show both cnx-neo2-NAS – SMB.CIFS and cnx-neo2-nas – SSH (SFTP) shares.
Configuration is now complete. I have not find a clean way to power off the system, so I normally open a terminal session via ssh and run the shutdown now command. A software button to turn of the NAS would have been a nice features on the kit.
I also often encountered the error “Software Failure. Press left mouse button to continue. Session not authenticated.” before the session timeout is set to 5 minutes. If you prefer a longer timeout, you can change it in General Settings->Web Administration.
In case you want to use the RTC, you may first want to set the timezone:
|
1 |
dpkg-reconfigure tzdata |
Check the date is correct, and write it to the hardware clock:
|
1 2 3 |
date Sun Jun 18 16:53:20 +07 2017 sudo hwclock -w -f /dev/rtc-ds1307 |
before reading it back.
|
1 2 |
sudo hwclock -r -f /dev/rtc-ds1307 Sun Jun 18 17:03:53 2017 -0.494575 seconds |
You can test it by rebooting the board without the Ethernet cable:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
sudo reboot ... date Thu Jan 1 07:00:34 +07 1970 sudo hwclock -r -f /dev/rtc-ds1307 Sun Jun 18 17:05:32 2017 -0.781570 seconds hwclock -s -f /dev/rtc-ds1307 date Sun Jun 18 17:07:28 +07 2017 |
Perfect! You’d just have to make sure the “set” command is run automatically at boot time if the time in the RTC is set. It would be good if FriendlyELEC updated their image to do that automatically at boot time.
NAS Dock V1.2 + NanoPi NEO 2 Benchmarks
Since I can now copy files and folders over SAMBA and SFTP, we can start running some benchmarks to evaluate performance. I’ll use EXT-4, BTRFS, and XFS file systems on the hard drive, and run iozone to specicially test storage performance, following by copying large and small files over SAMBA or SFTP to test real-life NAS performance. For large file copy, I’ll use a folder with 7 large files totaling 6.5 GB, and for small files, I’ve done a fresh checkout of the Linux kernel in my computer:
|
1 |
git clone https://github.com/torvalds/linux |
and removed symlinks since they may cause issues during copy, as well as .git directory with a huge 1.8GB file:
|
1 2 |
find -type l -delete rm -rf .git |
The end result is a directory with 64,013 files totaling 748.6 MB.
Iozone results
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
root@cnx-neo2-nas:/srv/dev-disk-by-label-CNXDATA# iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Run began: Sat Jun 17 07:46:20 2017 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16 kB Record Size 512 kB Record Size 1024 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 10242 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 8668 8947 8978 9164 486 732 102400 16 20660 21090 20761 21579 1891 3512 102400 512 24643 25185 38237 40271 24545 26282 102400 1024 25676 26720 38948 40451 30554 26253 102400 16384 25365 26658 39299 41369 40647 26235 iozone test complete. |
BTRFS:
|
1 2 3 4 5 6 7 8 9 |
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 8225 7763 8776 7939 491 7971 102400 16 19279 18923 20854 21008 1874 17037 102400 512 35049 34780 37170 36023 23173 33961 102400 1024 35323 35730 37113 37428 28020 34652 102400 16384 37381 37348 40899 41318 40575 37479 iozone test complete. |
XFS:
|
1 2 3 4 5 6 7 8 9 |
random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 7896 8199 9681 9392 510 756 102400 16 20343 21484 20715 21173 1983 4372 102400 512 23512 24129 39104 40450 25062 25884 102400 1024 31040 33526 39122 40805 31155 34293 102400 16384 34323 35551 39752 41428 40645 34403 iozone test complete. |
I’ve taken results with 16384kB reclen for read, write, random read and random write values to draw a chart, since most people are likely going to store large files in their NAS. The smaller reclen could be interesting if you plan to handle smaller files.
All three file systems have a very good read speed of around 40 MB/s, but BTRFS write appear to be the fastest among the three, with EXT-4 being the weakest at around 25 MB/s. But for some reasons, those results are useless in practice, as we’ll see below. Finding out the exact reason would possibly require studying and profiling iozone and the kernel source code which would be outside of the scope of this review.
File copy over SAMBA and SFTP
Results for large files in minutes and seconds.
| File Copy Large Files | SMB | SFTP | ||
| Write | Read | Write | Read | |
| EXT4 | 02:49.00 | 02:40.00 | 03:54.00 | 04:15.00 |
| BTRFS | 03:20.00 | 02:40.00 | 03:48.00 | 04:32.00 |
| XFS | 02:45.00 | 02:38.00 | 03:36.00 | 04:23.00 |
Chart converted to MB/s.
First, we can see very good read performance from the NAS (NAS to my PC) with 41 to 42 MB/s close to the theorethical limit of a USB 2.0 connection. Write speed is a a little different as the files were transferred more slowly with BTRS, and around 40MB/s with EXT-4 and XFS. Since SFTP is encrypted the transfer speed is roughly the same for all three file systems. Overall the file system you choose does not really impact performance with large files.
Results for small files in minutes and seconds.
| File Copy Small Files | SMB | SFTP | ||
| Write | Read | Write | Read | |
| EXT4 | 15:26.00 | 18:34.00 | 09:02.00 | 12:48.00 |
| BTRFS | 18:48.00 | 18:02.00 | 10:30.00 | 11:30.00 |
| XFS | 17:33.00 | 18:22.00 | 09:18.00 | 12:35.00 |
Chart converted to MB/s.
Transferring a large number of small files over SAMBA is really slow, and barely faster over SFTP. Again,there aren’t any significant differences between file systems here. If you are going to transfer a large number of small file over the network, you may want to either compress the files before transfer, or compress the files on the fly using the command line:
|
1 2 3 4 5 6 |
time tar zcf - Network_Test_Files_Small | ssh pi@cnx-neo2-nas.local "cd /srv/dev-disk-by-label-CNXDATA; tar xzf -" pi@cnx-neo2-nas.local's password: real 1m49.704s user 1m29.036s sys 0m8.272s |
It took just 1 minute and 49 seconds to transfer all 64,013 files, or over five times faster than SFTP write to XFS, at around an effective 6.86 MB/s. So knowing your tools may matter as much as having the right hardware.
I was going to run a last part after enabling optimizations provided by tkaiser, but it turns out FriendELEC has already done that in their firmware image.
If you want to reproduce the setup above, you’ll need to purchase NAS Kit v1.2 for $12.99, and a NanoPi NEO 2 with soldered headers for $15.99. If you don’t have a 2.5″ hard drive, you’ll need to add this, as well as a 12V power supply which you could purchase locally, or on FriendlyELEC website for under $10. All in all that’s cheaper than a similar kit with a Raspberry Pi 3 board, and you’ll get close to four times the SAMBA performance for large files since RPi 3 will be limited to 10 to 12 MB/s due to the Fast Ethernet connection.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Mine will arrive in 2 weeks. Can’t wait!
Thanks for the numbers and taking care of details (like improved Samba settings in FriendlyELEC’s OMV image).
Just two notes: By looking at the iozone numbers with btrfs it’s obvious that random write performance is ‘benchmarking gone wrong’, with all three filesystems random reads are around ~100 IOPS (you need to divide the iozone numbers that are KB/s through the block size) and random writes are ~185 IOPS with etx4 and XFS vs almost 2000 IOPS with btrfs. In other words: there’s something different at the VFS layer and this test does not report disk speeds but something else with btrfs. Just another example of a benchmark result that should not be used but simply dropped since ‘numbers without meaning’ 🙂
It seems you used three different partitions for the filesystems tests? When doing this with HDDs this can affect performance numbers due to ‘position’ of the partition (with most 2.5″ HDD even when USB2 is another bottleneck). All modern HDD use a feature called ‘zone bit recording’ storing more sectors on the outer tracks than on the inner ones. And therefore data rates at the begin of the disk (outer tracks) is much much higher than at the ‘end’ (inner tracks). Details: https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=15319
@tkaiser
I did mention we should ignore iozone3 numbers since some are lower than numbers with SAMBA…
I reformatted the drive for each test, so the full 1TB (931MB) was used for each partitions.
@cnxsoft
Good to know, in the meantime I checked FriendlyELEC’s kernel repo (github.com/friendlyarm/linux/tree/sunxi-4.11.y) and saw they’re using ondemand as default which might be another possible explanation for some weird looking numbers.
Might be worth a simple retest with ext4 and cpufreq governor set to performance. And if then numbers improve it’s time to look into /etc/rc.local for something like this:
Unfortunately their english wiki page is still not updated.
It’s still showing JM20329 as USB to SATA bridge and misses to mention that with the PCB 1.2 version also 3.5″ HDDs should be directly useable (according to schematic VDD_SATA_12V is routed to the three appropriate pins on the SATA power connector)
@cnxsoft: Are you able to do a quick test with a 3.5″ HDD? In that case a 12V/2.5A PSU would be a good idea.
This looks promising. But too bad they do not offer a 1GB version of the Neo2. 🙁
@tkaiser
Sorry I can’t try. This would require a SATA male to female cable. I only have female to female cables.
@Mike Schinkel
Maybe if enough people make the case for it and uses they might?
@Mike Schinkel
For which use case do you need more DRAM?
@cnxsoft
I was talking about using the PCB to directly connect to a 3.5″ HDD without a cable in between.
70$ shipping to Belgium. It’s twice the price of the kit!
@tkaiser
Oh OK. I thought the SATA connector was higher on 3.5″ drives… But it fits perfectly.
It’s detected, and I can mount it:
I’m using a 12V/5A power supply. FriendlyELEC should make another case for a 3.5″ drive. That would allow for more capacity.
Yeah, there is no different SATA connector for 2.5″ or 3.5″, the only question is always whether 12V is available on power pins or not. Thank you for confirming, I hope FriendlyELEC starts to sell the NAS 1.2 PCB separately too.
@tkaiser
That’s weird they only sell v1.0 board separately. I thought they would have just phased out that board.
@roel
role does this help
https://www.aliexpress.com/item/NAS-Kit-for-NanoPi-NEO-512M-Aluminum-Case-OpenMediaVault-Ready-NanoPi-NEO-512M-Application/32803873331.html?
@cnxsoft
Availability is ‘Pre-Order’ so I hope they replace it with v1.2 soon. Maybe they could sell the remaining v1.0 PCBs as part of a really cheap ‘DYI Fast Ethernet NAS kit’ with a bundled H3 NEO — pin headers soldered — since there JM20329 doesn’t matter that much. With a price below €22 including shipping (no customs, no VAT) they could target European users that want to choose an RPi 3 for OMV instead. Same performance, same functionality (OMV) but better price and integration (no external disk and no cabling needed)
@roel
Please be aware that @theguyuk sent you the link to the outdated NAS 1.0 kit (so my idea above regarding a cheap ‘DYI Fast Ethernet NAS kit’ is already obsolete 😉 )
If there’s a large electronics retailer in Belgium why not asking them to get in touch with FriendlyELEC’s European distributor to improve shipping situation in the future –> friendlyelec@allnet.de
What is the maximum hard drive size it supports?
@tkaiser
I already noticed it was the old version on the aliexpress store. BTW it’s also only the kit without the nanopi-neo. I don’t think some vendor will be interested in Belgium. They are alienated here for such things. In the Netherlands they are more open to it.
@Vai
With the above 1.2 version of the kit there’s no limitation. JMS567 supports SATA drives of any size. Be careful when following obscure links to the old 1.0 variant of this kit or at least do some research on your own whether JM20329 used there is capable to deal with disks that exceed 2.2TB in size (32 bit integer overflow with old USB-to-SATA bridges) and can cope with Advanced format 4K drives.
@roel
Well, then it’s time to send a daily email to conrad.be (they’re ALLNET resellers and added recently some NanoPi models so show them that there’s demand for more 😉 )
BTW: I’m personally not interested in the 2.5″ enclosure solution at all since if I want to combine such a H5 based OMV thingie with 2.5″ disks I can choose any of the available options (most probably preferring Orange Pi PC 2, Prime or soon to be released NanoPi M1 Plus 2 if my use case requires more DRAM). The beauty of this solution here is the $6.99 PCB being able to be fed with any of the usual 12V bricks and allowing to attach/power a 3.5″ disk. So still looking forward for this PCB rev 1.2 appearing in FriendlyELEC’s shop 🙂
do you guys know what’s the HDD operating temperature inside the case ?
https://static.googleusercontent.com/media/research.google.com/en//archive/disk_failures.pdf
according to this study (fig 5), failure rates of 3+ year old drives tend to skyrocket when avg operating temp exceeds 40°C.
and imho, this case shoudn’t be such a S.M.A.R.T. choice (almost no cooling, that’s what i call a mini-oven-case)
you could get some nice info using these commands :
sudo apt-get install smartmontools
sudo smartctl /dev/sda -a | grep -i temp
PS: you should always backup your data :p
PPS: note that i’m talking about HDD, i have no idea about how SSD behave regarding operating temperature
You realized that only 2.5″ disks fit into the enclosure? Unless you take 10k WD VelociRaptors without their IcePack frames there’s no need to worry about temperatures at all. The better idea is using the -x switch with smartctl since this also allows accessing the so called ‘SCT logs’ if available and then you get also something like this:
This is a Notebook HDD currently used in an external enclosure to do backups, all thermal data fine.
Wrt to the Google study it’s always amazing what people extract from data. The study shows clearly the opposite of what you claimed 😉 ‘The figure shows that failures do not increase when the average temperature increases. In fact, there is a clear trend showing that lower temperatures are associated with higher failure rates’. Also ‘One of our key findings has been the lack of a consistent pattern of higher failure rates for higher temperature drives or for those drives at higher utilization levels’.
That’s the data. Only for some 3 or 4 year old drives there was a somewhat different correlation (correlation != causation). This study is from 2006 and tells clearly: ‘The data used for this study were collected between December 2005 and August 2006’ so some statistical correlation for some disks that were put into production in 2001/2002 should matter for any decision today? Really?
come on tkaiser… imho the text you quoted is more of a general interpretation.
The data is shown by the graphs, not the text.
And my “claim” (i don’t like this term, it’s more like how i interpret the graphs) took into account temperature AND disk age.
Figure 2 clearly shows that AFR (average annualized disk failure) is much higher starting with 2+ years old drives.
Is my reading of this graph wrong ? i don’t think so.
Figure 5 adds in ‘average drive temperature’. And yes, AFR of 3 years old drives skyrockets when their temp >= 40°C.
Is my reading of this graph wrong ? once again, i don’t think so.
though, i agree with you that the data is old. but can you provide more recent data ? i just can’t…
should i make as if this study didn’t exist ? really ?
It’s what’s called the result after analyzing all the data. Of course you’re free to ignore this based on looking at few graphs there 🙂
If you really read through this study you’ll find references to even older studies all mentioning a correlation between high temperatures and failure rates. Google’s numbers show this also for disks from 2001 and 2002 (you know that we’re talking here partially of ATA/IDE disks and not even SATA? And Google (mis)used desktop HDDs for 24/7 operation just as the Backblaze folks do today –> you might want to check http://www.backblaze.com/blog/hard-drive-temperature-does-it-matter/ and their summary: ‘I found that overall there is no correlation between temperature and failure rate.’ — I’ll leave it as an excercise for the reader to find out which methodological mistakes were made here 🙂 )
Anyway: If you feel affected by some statistical correlations that are all based on disks that are at least 15 years or older, then… well. We’re still talking here about energy efficient 2.5″ disks and even with a ‘NAS benchmark’ running NEO2 + HDD won’t be able to exceed overall consumption of 5W or maybe 7W. Ever seen a 7W heater? 😉
Really, temperatures are no concern but maybe Jean-Luc can run a NAS benchmark like Helios’ LanTest (needs a Windows box though) with 3 times 10GbE settings, then wait 10 minutes and provide output of
smartctl -l scttemp /dev/sda
This device support more them 1tb disk?!
@Dcbasso
Already answered.
@nobe
Results of the command after copying a large (~100GB) file over SAMBA.
CPU is around 75% idle during the copy so it’s not a worst case scenario. Room temperature is around 30 C.
Full output from smartctl /dev/sda -a -d sat command: https://pastebin.com/NbH0iJyE
@cnxsoft
Command with x switch:
So nothing to worry, disk temperature inside the enclosure is not even 15°C above ambient temperature. BTW: ‘grep -i temp’ is wrong to get the SCT logs, eg. temperature logging: this is a nice feature to get temperature variations eg. after running a heavy benchmark (heavy != NAS mode), looks then like this at the end here: https://pastebin.com/pVrPZr9Q
With 2.5″ HDDs that are better choices if you fear heat (Samsung/Seagate Spinpoint — compare the min/max values with the Toshibas from above) it looks like this for example (Spinpoint M7 AKA SAMSUNG HM500JI):
There’s a nice different too if you prefer your disks spinning down when inactive. A ‘smartctl -a’ wakes the disk so it spins up while a ‘smartctl -l scttemp’ gets just the recorded temperature records without waking up the disk and that way you get also temperature history for the drive while in standby state (unfortunately not all drives support SCT temperature logging). Current temperature is then
BTW: I photoshopped yesterday the combination 3.5″ HDD with the NAS 1.2 PCB: http://kaiser-edv.de/tmp/NumpU7/NAS_Kit_with_3.5_disk.jpg
Looking forward to just get the PCB, a 3.5″ HDD and then combine it with NEO2 or even NEO Plus 2.
@tkaiser
The photoshop looks about right (dimensions wise).
@cnx
thx running for the test
@tkaiser
it looks like the backblaze article mentions HDD which average temperature <= 38°C.
obviously i wasn't talking about this scenario : google graphs show AFR = 40°C.
but at least there the text (interpretation) doesn’t seem to contradict the graphs (data vizualisation).
and backblaze mentions another article from microsoft and university of virginia : http://www.cs.virginia.edu/~gurumurthi/papers/acmtos13.pdf
in section 4.2, this study :
– correlates higher AFR with higher temperature (there seem to be much more interesting information in there, but i don’t have the time to read it completely)
– points out it’s contrary to the google study (‘pinheiro and al 2007’)
and i’m not surprised here. there’s definitely a “by drive age” bias in google study. this is shown by the 2 graphs i mentionned in a previous comment which seem to contradict their own interpretation.
btw, thx for telling about the “smartctl -l scttemp” option, that’s very interesting.
and lastly, you probably won’t care but i just dropped my 2.5″ external hard drive when i wanted to try this option, now it seems dead T_T
oh… part of my previous comment doesn’t appear, i think it was somehow commented out
google graphs show AFR inferior or equals 5% when temp superior or equals 40°C
erratum : when temp inferior or equals 40°C ^^;
You should really read the studys you want to rely on. I know this paper since years and it’s IMO a good example why statistics is so hard. The folks who did the data research wanted to show a causation of higher temperatures with higher failure rates. They were so focused on temperature that they simply forgot about everything else, especially vibrations. They mention ‘vibrations’ as follows: ‘We currently do not have metrics that expose the level of induced vibration, and measuring the impact of vibration is one of our projects that are currently underway’ and then simply forget about it and focus on aging and temperature only. I would call this already stupid.
If you look at the graphs at page 12 it’s obvious that position of drives/servers matters more than temperature so you have to think about what’s different wrt position and that might be that the inner drives are exposed to more vibrations as the outer drives (that show similar low failure rates but totally different averaged temperatures).
All this ‘significant correlation’ babbling is useless if you’re already biased and want to use statistics to make your point. For example there is a ‘significant correlation’ between shoe size and reading capabilities. Those human beings with very small feet don’t read good or at all (those are called children BTW). If you do statistics wrong you make a causation out of a correlation and conclude that the larger the feet the better the reading skills. That’s what happens all the time 🙂
Back to real numbers, I made another test in the meantime. Samsung SpinPoint M7 in pretty small ABC plastic enclosure together with an SBC (Olimex Lime2). The thing is in a rack, temperature in the cabinet is a constant 18°C. HDD temp when sleeping is 32°C or 33°C. Few iozone benchmarks using sequential and random IO workloads ran between 11:15 and 11:30 afterwards I let the disk spin idle:
SoC and PMIC have internal thermal sensors. When the HDD is sleeping with normal workloads they’re both at 39°C but when running the iozone tests temperatures increased up to 43°C: https://pastebin.com/eAjWHQKU
While the HDD is spinning but idle HDD temp remains at 38°C and SoC is 1°C above normal level (so that’s HDD heat dissipating over to the SoC) while PMIC is 2.5°C above normal level (PMIC temperature rises with load). In other words: As expected everything’s fine.
Final comment: I hope you know that you don’t need to care about statistical data for fleets of HDDs if you’ve only one or a few disks? They don’t care or know about statistics and die within a few months or survive 10 years or longer. The above numbers are only interesting if you plan to use at least hundreds (better thousands) of disks since only then you can benefit from statistical results if they show a causation and not just correlations and you never looked into whether that’s the real cause.
Wrt disks and vibrations please visit youtube and search for ‘shouting in the data center’ 🙂 And another nice example why statistics is complex and correlations are no causations can be found on the web searching for ‘stork babies statistics’.
Does anyone use OMV on an SD card with read-only root?
@Andy Chentsov
If you use any of the Armbian based OMV builds from here https://sourceforge.net/projects/openmediavault/files/Other%20armhf%20images/ (or the most recent ones for ODROID-C1/C2/XU4 at the same location) you don’t need to care about that. Due to disabled monitoring and optimized settings (Armbian settings + folder2ram) SD card writes are reduced to the absolute minimum. If you don’t trust in SD cards at all you could create a small partition (4GB are already sufficient) on any of the disks and move the rootfs over using ‘nand-sata-install’. SD card has to remain in the slot but only the bootloader is read so then the SD card is really read-only.
@tkaiser
Thanks for the reply.
I would like to have a guarantee that the file system will not be broken if unexpected power off, so I’d like to make the root filesystem read-only.
Thanks, nice review…
Was the bad NanoPi NEO 2 board unstable by itself if unplugged from the NAS board? Maybe the NAS board is causing the instability. What did the manufacturer have to say about this? Anyone else with out-of-the-box unstable or dead NanoPi NEO 2 hardware, with or without the NAS board?
Since you said SFTP is running, an alternative to running SAMBA is to generate a key pair via OpenSSH and register the public key in your file browser (it’s easy to do in Nautilus, search online for a tutorial). Now your shared device will appear in your file browser under Network or Bookmarks and work just like a SAMBA share, but without the bloat and insecurity of actually running SAMBA. Note however, SFTP shares may be slower than SAMBA (roughly 15%-%50% depending on many factors like FS type, read or write, file size, number of files, media format, media interface, etc.)
SAMBA was recently found to have some serious bugs and was patched on all mainstream distros, so I would suggest research into this plus figuring out how to patch the NAS box OS (good luck with that).
Not possible and useless anyway since power losses could also corrupt data on the NAS shares. If you expect power problems simply fix them first! You can use any UPS here since power draw of such an idle NAS will be as low as 1W (a little bit more if you use an overrated 12V PSU brick).
LOL! FUD galore! OMV3 is based on Debian Jessie, Samba packages are those from upstream Debian repositories so Debian’s security team will provide fixes. I can’t speak for FriendlyELEC’s OMV image (since never used or tested) but the Armbian based OMV variants enable ‘unattended upgrades’ so as long as you let your NAS box access the Internet you get security fixes automagically on a daily basis!
For anyone concerned about Samba vulnerabilities and OMV: Simply allow unattended upgrades and update regularly! And check https://security-tracker.debian.org/tracker/source-package/samba if in doubt.
@tkaiser
You should given your experience do your own blog or a PDF book.
Other people still promote Banana Pi !?
https://simplenas.com/
The old Banana Pi with A20 SoC make up for nice little NAS boxes but you have to avoid the OMV images from simplenas.com — they are old, outdated, use broken settings and perform not that great. I’ve tried to explain that to Cyryllo (the one behind the site) several times in the past but have given up. Fully supported OMV images for the Bananas worth a try you’ll find in official OMV download section (See sourceforge link above) (they’re based on Armbian’s Debian flavour, use Armbian settings and a few improved tweaks for OMV to improve NAS performance)
While those old A20 based Bananas have ‘real SATA’ in most real world scenarios they’ll be outperformed by this cheap NEO2 NAS box here especially when using btrfs with ‘compress=lzo’ mount option (has to be set manually in OMV’s /etc/fstab). But same applies to all the other GbE enabled H5 boards once mainline kernel is ready for them (4.13 I would assume so just few months more waiting 😉 )
@tkaiser
UPS is a good thing, but using a 200-300W UPS to power the NAS on a NanoPi is like “use a cannon to kill a fly.”
@Andy Chentsov
That’s the reason we use Olimex Lime2 for small NAS boxes. There you simply plug in a battery and are done since Olimex engineers are not that stupid as others (talking about Bananas here) and a connected disk runs from battery if needed.
@tkaiser
Olimex Lime2 has an old A20 SoC. It would be nice if FriendlyArm engineers added the LiPo battery connector to the NAS Dock.
@Andy Chentsov
Adding a battery connector isn’t enough, you need charging circuitry and also some logic how to switch between power sources if needed. That’s the (only) reason why tablet SoCs like A20 are nice for small NAS because they’re accompanied by PMICs (AXP209 in A20’s case) that handle this. TV box SoCs like the one we’re talking here about (H5) miss this.
But just adding a battery connector and PMIC is also not sufficient as you can see by looking at the ‘designs’ from manufacturers known as ‘brain damaged retards’. On almost all Banana Pi for example you find a battery connector and a PMIC but those ‘engineers’ never think about what they’re doing and so connected disks won’t be powered when running from battery.
@tkaiser
I meant to add the connector -> to add the ability to use the battery for power backup (with switching logic).
This can be achieved not only by relying on SoC, but adding logic on its own, for example, to the NAS Dock board.
Would this 2015 RPI video suggest any diy solutions https://m.youtube.com/watch?v=qev1E7bqNjA
@Andy Chentsov
Currently the NAS kit is rather cheap ($7 without enclosure, an additional $6 for enclosure + heatsink) and if you do a web search for ’12v ups’ you find only solutions twice that expensive. By choosing a tablet SoC it’s just adding PMIC, boost converter and a common battery connecter and you’re done (regarding the latter: some manufacturers also known as brain damaged retards manage to use proprietary battery connectors you can’t find a single battery for since not even the retards sell batteries that would fit).
If I would want to combine a H5 based NAS with UPS functionality I would most probably choose an Orange Pi PC2 (or Prime if my use case needs more than 1 GB DRAM) and combine it with an USB powerbank that can be charged and powers devices at the same time (only a few do!). On the Orange Pi the horizontal USB receptacles share one current limiter so USB powered disks should always be connected to the upright USB port instead.
@theguyuk
That’s one solution, but this won’t work with all power bank though, as some will take some small time to switch between mains and battery power to the board may reboot. Some power bank (like the 50A one I used in this review) may just shutdown after a power failure, and you may have to press the button manually again to turn it on.
This should also be tested under load.
This is not a solution since the NAS kit wants to be powered with 12V. To combine it with an USB power bank you would also have to add an external step-up converter to do the 5V–>12V conversion while internally there sits a step-down converter to get back to 5V. Only a nice way to waste some energy and generate heat unnecessarily.
With an USB power bank I would prefer a 5V setup instead as outlined above (get an OPi PC2, FriendlyELEC’s OMV image, exchange the .dtb file and you’re done. Or wait few months until official OMV images appear on Sourceforge for all relevant H5 boards anyway. On the other hand now that RK3328 USB3 performance is known H5 boards look somewhat boring if it’s about the NAS use case)
@tkaiser
You don’t necessarily need a USB power bank, just a 12V power bank.
@cnxsoft
How can the power banks inform the operating system to switch to a battery so that it can automatically shutdown if the power does not appear for a certain period?
@Andy Chentsov
You can use the inavailability of a networked device as a ‘mains is gone’ indicator (a variation of the heartbeat principle) or you take the solder iron and use power bank leds (that usually start to blink if capacity gets low) as GPIO input of an SBC. All of this not necessary with appropriate SBC for this use case like Olimex’ Lime2 since there you can read out battery capacity/voltage through sysfs and act on accordingly 🙂
@tkaiser
To check the lack of power using the network devices is not reliable, because the network may disappear when the router is rebooted.
I was able to run OMV on the read-only root partition using overlayfs, scripts and patches for this you can see here https://gist.github.com/andyduke/3da146828e1fded905932ee56225802f.
Now I tried it in a virtual machine, next week I’ll try it on NanoPi Neo2.
I made few tests in that in that configuration:
– software: Dietpi OS v.154 with samba installed through Dietpi menu
– hardware: 2.5″ hdd, Western Digital 320 GB with file system NTFS, one partition
– main computer have Win8.1×64
– all my network interfaces are gigabit, router-switch-main PC…
After few moments after boot I transfered:
– a big file (2.2GB) from main PC to Nanopi Neo2 with 17 ~ 20 MB/s
– 1395 files from main PS to Nanopi Neo2 with minimum 13 MB/s
But, after a half an hour the whole Nanopi Neo2 and aluminium case become very hot.
The CPU temperature don’t drop below 68 degree and the aluminum case is also very hot when I touched with my hand.
The transfer speed dropped:
– the same big file – 2 MB/s
– the same small files – 2 MB/s
–
Seems to be unusable because of highest temperature.
Any other configuration, tests and temperature?
@doru
If the 68 C is the CPU temperature reported by the system, then it’s not too high. Maybe it’s another issue.
In case, it’s really a CPU throttling issue, then it can be mitigated in several ways:
Hardware – Make sure the thermal pad and heatsink are properly installed. I guess some people will forget to remove the plastic covers on the thermal pad.
Software – The way to CPU governor is handled matter too, so I’d check the OMV image released by FriendlyELEC above, and/or Armbian images. You can also adjust the power consumption (and indirectly heat dissipation) using armbian-config
O my good, that’s already worst case. DietPi is about marketing bullshit (lightweight, diet) and guiding clueless users in a menu driven way. It totally focusses on userland and don’t pays attention to the relevant stuff on small ARM boards (kernel, settings). As the creator says: ‘DietPi for NanoPi NEO was built using ARMbian build tools, then optimized and primed for DietPi.’ — so they simply ignored that Armbian considers all H5 based boards like NEO2 still being ‘work in progress’ and not ready to use. Therefore we at Armbian don’t provide any OS image for end users yet (will change once kernel 4.13 is out and we successfully optimized thermal settings).
Also by installing a default Samba you miss a lot of important performance tweaks! Check your heatsink as already suggested and download FriendlyELEC’s OMV image for NEO 2. Way better choice than this DietPi thingie and containing all the OMV/Armbian optimizations for decent NAS performance since FriendlyELEC folks don’t suffer from ignorance.
Overseen before: https://en.wikipedia.org/wiki/NTFS-3G#Performance
Using ntfs-3g on slow ARM devices is a great idea to lower performance and massively increase CPU load for no reason 🙂 You should better switch to ext4 or btrfs instead.
@tkaiser
That was true 10 to 5 years ago, now ARM processors are quite fast, so in most cases there are no big differences between NTFS and EXT-4 sequential performance in recent hardware, at least when using (mechanical) hard drives. It’s quite possible CPU usage is still higher though. I have not checked this for a long time.
@cnxsoft
Hmm… since I was investigating USB3 issues with ROCK64 I simply gave it a try. Benchmark calls used:
Results: https://pastebin.com/ruP3PRR1
Obviously with ntfs-3g/FUSE iozone’s -I parameter got ignored: -I –> Use DIRECT IO if possible for all file operations. Tells the filesystem that all operations to the file are to bypass the buffer cache and go directly to disk. (not available on all platforms)
So I repeated part of the test with 12GB file size (ROCK64 unfortunately has 4GB DRAM and I wanted to use at least 3 times the physical RAM to fight a little bit the aggressive buffering/caching with NTFS). So with huge block sizes we’re talking about 380MB/s possible with ext4 and only ~140MB/s keeping in mind that iozone in this mode fails to report real NTFS performance due to FUSE/ntfs-3g caching effects — all read values for NTFS are way lower in reality or if more suitable benchmarks were used for this use case.
Sequential reads with small block sizes (4K) look like this wrt CPU utilization (30 second samples and then averaged):
When we subtract the %iowait percentage for ext4 we end up with a difference of 94% idle vs. 71% with ntfs-3g. Also important: I tested on a quad core A53 running at 1.3GHz. With ntfs-3g the worker thread was all the time at around 90% CPU utilization almost fully using one CPU core. On something like NanoPi NEO 2 which is only allowed to clock up to 864 MHz reliably this will already bottleneck IO performance with ntfs-3g especially when using a crappy distro that doesn’t give a sh*t about necessary performance tweaks (eg. IRQ affinity to prevent all interrupts being processed on cpu0 which will lead to a nice overall performance drop in NAS situations when both network and storage are busy).
@cnxsoft
Thanks for the sugestions. I’m pretty sure that thermal pad and heatsink are properly installed but I will ckeck to avoid any doubt. Seems is software problem like ‘tkaiser’ told in comment 58.
@doru
Tried NAS performance with Samba today and compared between DietPi and OMV on a Raspberry Pi 3 and an ODROID-XU4 (but simply broke testing since DietPi’s NAS ‘performance’ was too disastrous): https://forum.openmediavault.org/index.php/Thread/18991-New-approach-for-Raspberry-Pi-OMV-images/?postID=150444#post150444
@tkaiser
You are right. Seems to be a software choice problem. Using Dietpi and proftp server I tried to copy the same big file (2.2GB) through FTP client. I removed the HDD because I’m afraid to damage due to whole system temperature. This time I used a SanDisk USB 3.0 stick, Ultra Fit 32 GB more exactly. After the 25% of the file was transfered the system frozen and I think was reseted. I will switch to FriendlyARM OMV image and I will post some data about transfer speed and temperature. Thanks for your informations.
Well, it is obviously now for me that was not the right choice when I chose Dietpi distro, but for ordinary user like me, when I tried to find simple but reliable solution for my needs this two points determined my choice:
1. simplicity – I have a SBC and I want to use with OpenVPN to connect to my home network and later I want to add Pihole to block some ads
2. reliability – at the time when I chose Dietpi distro I found a lot of people complains about SD card failure and Dietpi had included the method and guide to move all data from SD card to USB stick. This makes the whole system less liable to failure.
In few words: I have a Raspberry Pi board, I found on search engines Dietpi distro which have both OpenVPN and Pihole software installation option and they have on their forum step by step method to install the software and move the root file system to USB stick keeping the SD card just for system boot.
That two facts determined me to made my choice. However, that two concepts, simplicity and reliability, are very relative, even for the same person. What was reliable for me at the time when I made the choice, now seems aren’t because I know, thanks to your posts, the problem with Nanopi Neo 2 and Dietpi distro combination is not about just SD card failure but OS and software optimization.
After I finished my little project with OpenVPN and Pihole on Raspberry Pi I tried to use my other board, Nanopi Neo 2 with 1-Bay NAS for backed up my data but as I said and you had confirmed, that combination, Nanopi Neo 2 with Dietpi are unusable right now due to bad software implementation.
Definitely I will switch on Nanopi Neo 2 board, from Dietpi, to OMV FriendlyARM image. My concerns are about SD card speed and corruption and I think to try keeping the SD card just for system boot and using an USB stick for system files but I don’t know how to do that with OMV FriendlyARM system.
Maybe, you have some advices for me, please?
In my opinion fewer software are better. For example I think just armbian with samba software would be the best combination but is more advanced project for me.
Thanks
@doru
SD card issues are very common everywhere but there exist a few steps you can do prior to usage (do a web search for ‘armbian getting started’ to read through online docs where this is outlined in detail). Especially Raspberries were plagued by SD card crappiness since on first generation Raspberries further SD card issues were created while operating the boards due to a shitty power design. This has been fixed with 2nd generation Raspberries a few years ago (A+, B+) but once a myth is on the Internet the story will be told over and over again.
If you buy good and genuine SD cards (check the search field here on CNX in the upper right and search for ‘micro sd’ to read through a very good compilation of ressources) there’s nothing wrong running off an SD card. Some distros keep log files and other frequent changing stuff in memory and sync it to storage only once an hour (Armbian, DietPi and official OMV images for example) so if you ruled out ‘initial SD card troubles’ (buying counterfeit cards, burning the OS image wrong by avoiding Etcher) you also don’t have to fear early wear out of the card later.
Moving an installation from a good and genuine SD card to a crappy USB stick is stupid of course. All flash media can be crappy and should be handled the same way: Directly tested after purchase. I did this recently with a bunch of cheap USB sticks that were lying around here and there: the majority of them was magnitudes slower than a good Samsung EVO+ with 32GB for example and three went directly to the trash since showing errors. Moving an OS to such a crappy device is moronic.
The official OMV for ARM images since based on Armbian contain the nand-sata-install script (historically named wrong but Armbian core team unfortunately doesn’t care about such stuff, same with Armbian’s self-promotion) so you could move your installation away from SD card to eMMC, NAND, USB or SATA storage just like you wish. But to be honest: Since good SD cards are not really more expensive than crappy SD cards I simply buy the first category only. On all of the ARM servers we run at customers OS installation remained on SD card or eMMC and we’re using btrfs with compression and regular scrubs to check for data integrity issues. So far none occured.
Thanks for your detailed explanations. I will search for more informations related to armbian and I will try to begin switching from DietPi to armbian my RaspberryPi-OpenVPN-Pihole project. For my back-up project using NanoPi Neo 2 and 1-Bay NAS I will use FriendlyARM OMV image with good SD card following your advice. Thanks for that, and not last, for your time.
Hi guys,
Did you try to connect any temperature sensor to I2C connector?
I have tried with SparkFun Si7021 (https://www.sparkfun.com/products/13763) but with no luck.
I have I2C enabled but sensors-detect does not recognize anything.
Great post thank you! I do think it would make sense to compare to baselane, eg, stick that same hard drive into a beefy computer and run the same tests again. I think the 1TB hard drive used here wasn’t one of the latest, greatest and fastest; maybe limitting by itself. Or run that same test again with a beefy SSD so we are sure the disk itself isn’t the limit
@Michel
You did realize that on this board storage is implemented by a USB-to-SATA bridge behind an USB 2 port limited to Hi-Speed (480 MBps and around ~40 MB/s in reality with USB Attached SCSI)? This is the main bottleneck you can only eliminate by somewhat questionable RAID attempts and/or transparent file compression if you deal with data that’s not already compressed.
BTW: In the meantime NEO2 and the other Gigabit Ethernet equipped NanoPi are also supported by Armbian and therefore OMV too: https://sourceforge.net/projects/openmediavault/files/Other%20armhf%20images/
Hello. Is it possible to install OwnCloud on the device? I want to combine my two external HDDs (one of them connected with USB) to create nice little online storage. My first idea was to use RaspberryPi 3, but this solution looks neat. Thanks!
@Petr
Yes, it’s just an Arm Linux board. So you can install a Linux distribution like Debian or Ubuntu, and then install other software packages you want like ownCloud / NextCloud.
After upgrading OMV to Arrakis I have a problem with watchdog service.
Actually there are two failed units:
● watchdog.service loaded failed failed watchdog daemon
● wd_keepalive.service loaded failed failed watchdog keepalive daemon
As far I can tell it is cause by:
modprobe: FATAL: Module softdog not found in directory /lib/modules/4.11.2
Dou you know what can I do with that to be working?
You need to either enable/build softdog module for your kernel, or ask the maintainers of Arrakis image to add it.
That is what I already know 🙂
But how can I “enable/build softdog module for kernel” ?
I was installing my OMV from image available on:
http://wiki.friendlyarm.com/wiki/index.php/1-bay_NAS_Dock_v1.2_for_NanoPi_NEO/NEO2#Download_Debian_for_NAS_Image
I don’t even know who is responsible for it. (i.e. who should I contact)
Oh I see Arrakis is just an OMV plugin? I thought it was a separate firmware image.
The images you linked to are managed by FriendlyELEC, you can inform them on their forums: http://www.friendlyarm.com/Forum/viewforum.php?f=47
Alternatively, you could download the source code, and build it with softdog enabled. Have you ever cross-compile a kernel for Arm? A quick example of steps to follow: https://www.cnx-software.com/2015/11/19/amlogic-s905-source-code-published-linux-u-boot-mali-450-gpu-and-other-drivers/
After the defconfig step, you’d need to enable softdog in make menuconfig. You can search for it: https://www.cnx-software.com/2013/05/23/how-to-find-configuration-options-quickly-in-make-menuconfig/
> Arrakis is just an OMV plugin?
Nope, Arrakis is just a version name: https://en.wikipedia.org/wiki/OpenMediaVault#Release_history
Since the kernel version on FriendlyELEC’s OMV image is pretty outdated and obviously gets no updates I would better switch to Armbian instead. Debian Stretch Next from here https://dl.armbian.com/nanopineo/ and then ‘armbian-config’ –> Software –> Softy –> Install OMV
If I will install Armbian from scratch and then install OMV on it will there be any possibility to migrate OMV config from old setup to new one?
How does it look like with kernel on Armbian. Is it regularly ugraded like it is on Raspberry Pi?
> How does it look like with kernel on Armbian. Is it regularly ugraded like it is on Raspberry Pi?
Sure: https://docs.armbian.com/Release_Changelog/
Wrt migrating OMV settings: unfortunately not possible so you have to transfer settings manually. But re-using the data disk is no problem at all. A good idea when transferring settings is to document them somewhere (IMO that’s one of OMV’s design flaws: not being able to backup/restore/migrate configuration)
I have just installed Armbian from image (https://dl.armbian.com/nanopineo2/Debian_stretch_next.7z) and problem is still present 🙂
This time it looks like:
modprobe: FATAL: Module softdog not found in directory /lib/modules/4.14.14-sunxi64
Hi,
what’s the temperature range of the board? Industrial (-40C/+85C) or commercial?
I cannot find that info anywhere.
Would you give your advice about embedding that board in a real product?
Thanks