• Content Count

  • Joined

  • Last visited

About esbeeb

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Another weird quirk that I wanted to mention: about 1 boot in 5, the Ethernet will autonegotiate at only 100Mbit, not 1000 Mbit, as it should. Rebooting is all it takes to get it to renegotiate properly. I've changed the GbE cable a couple of times, as well as using different ports on my Fritzbox WiFi router. Nothing helped. So I'm pretty sure it's the fault of the NanoPi Neo2 itself. I would catch this problem when I noticed that none of my OMV file transfers would go faster than 12 MB/sec, when I knew I could normally get 12-40MB/sec. The ethtool command would indeed verify that the Ethernet got negotiated at only 100Mbit. After a reboot, I would check again, and it would be 1000Mbit.
  2. Dear moderator, could this topic be moved to the H5 subforum? It's misfiled under the H2 & H3 subforum. Thanks in advance. @lanefu, @Igor Sorry, I don't know who the other mods are.
  3. So I built a new OpenMediaVault server from a new PC, and used the same 3 SATA disks mentioned above (two Toshiba 3.5", and one Samsung 2.5" SSD). This PC has an Asus mobo (Asus Tuf B450 Gaming) with GbE and a sweet B450 disk controller. The two 3.5" SATA drives now get about 200 MB/sec with hdparm, and the 2.5" SSD gets about 500 MB/sec, which of course is way faster than when these were hooked up to the NanoPi Neo2. Here are the results of the network transfer speed tests which mattered to me most, for sake of comparison: Using two different USB 3.0 GbE dongles on my laptop to upload (an Anker AH212, and a smaller, cheaper and slightly slower TP-Link UE300), I uploaded 2 GB of eBooks into this new Asus PC OMV server in different ways: Anker AH212: SMB upload of a 2GB .zip file: 54.1 MB/sec SMB upload of a 2GB folder with many tiny files (2029) in many folders: 24.7 MB/sec FTP upload of a 2GB .zip file: 105 MB/sec FTP upload of a 2GB folder with many tiny files (2029) in many folders: 40.8 MB/sec TP-Link UE300: SMB upload of a 2GB .zip file: 47.6 MB/sec SMB upload of a 2GB folder with many tiny files (2029) in many folders: 19.2 MB/sec FTP upload of a 2GB .zip file: 105 MB/sec FTP upload of a 2GB folder with many tiny files (2029) in many folders: 37.0 MB/sec Here are some of those test results again (gathering from my results above), when I uploaded using the same GbE dongles into the NanoPi Neo2, into the same disks (and let's set aside the disk IO error problems I had with the two 3.5" SATA drives in crappy Orico USB enclosures): Anker AH212: SMB upload of a 2GB folder with many tiny files (2029) in many folders: 14.6 MB/sec FTP upload of a 2GB folder with many tiny files (2029) in many folders: 25.0 MB/sec TP-Link UE300: SMB upload of a 2GB folder with many tiny files (2029) in many folders: 12.0 MB/sec FTP upload of a 2GB .zip file: 29.9 MB/sec FTP upload of a 2GB folder with many tiny files (2029) in many folders: 22.3 MB/sec
  4. I kept getting disk IO problems on my 2 external USB drives. I could never narrow down just what to blame: the USB cables (which I changed like 5 or 6 times), the USB enclosures I bought, or the two USB ports on the NanoPi itself. Even though these enclosures have JMS578 controller chips in them, and those are pretty ideal controller chips, I don't really trust the other ORICO components around those chips. I wouldn't recommend buying these ORICO 7688U3 enclosures ever again, even if just for the reason that they secure the drives poorly (which is why I had to hack together a nylon strap to prevent the drives from vibrating inside the enclosures). There's no "rails" on either side of the drives while they are in the enclosure. The only thing stopping the drives from wobbling side to side in the enclosures is the SATA port being connected itself, plus there is a little block of rubbery foam that the front of the drive pushes up against (and that only holds in the center, not at the corners). The SATA-connected SSD drive (connected to the NanoPi's "NAS kit" accessory board) always behaved nicely. No disk IO errors. So therefore, I suggest using the NanoPi Neo2 only for a project where you need 1 disk, and that 1 disk should be a 2.5" SATA attached to the NanoPi's "NAS kit" accessory board. Beware the USB ports, and you would be well advised that you are likely to run into Disk IO errors if you still dare. Watch your /var/log/syslog like a hawk, and maybe you'll see disk IO errors appearing there.
  5. Am I ever glad I used BTRFS on all the file shares. I have "snapper" set up nicely to do automated snapshots on all 3, and combined, these proved to be invaluable in recovering from the less-than-excellent USB cables I used. Let me once again stress that you absolutely cannot afford to cut corners on the USB 2.0 cables you choose. They must be brand spanking new, and have the inline cylindrical magnets to cleanse the signal. Also, I implore anyone using Armbian to make periodic backups of the MicroSD card (or wherever you install the OS), with, say, "dd", or some other disk imaging tool. I had an " apt-get update && apt-get upgrade" blow up in my face badly recently: I couldn't log into the web management interface of OMV, nor could I even log in with SSH any more! Not being able to log in with SSH (which is the normal way I would rescue such a problem) left me shocked and horrified, as there is no video port whatsoever on this rig to log in at the console. I have no equipment for a serial connection either. The backup SD card I had saved my bacon. I'm now losing my interest in using this ARM board for OMV. There have been just too many surprises and pitfalls, try as I might to do my best, and I only have enough spare time to slay just a few of the smaller dragons. I plan to use OMV in a PC instead (where I would have a video port for rescuing), and use this NanoPi just for SyncThing, which is less ambitious (than OMV), yet still useful to my organization. By using OMV in a PC, I'll also be able to install some Docker containers that my organization needs, this "sweetens the pot" enough for me to want to rebuild the NAS on that equipment. I hereby retract my bold statement above, that "This rig was born to run Openmediavault". I hope my small contributions above save others time and stress.
  6. Behold, the majestic zebracorns!
  7. There's a lethally poisonous spider in Australia called a "Whitetail". It too is black and white. I've had one standing on the tip of my index finger. Not a lie, and not a joke.
  8. It's tough to come up with a mascot that hasn't been used by some other project yet. How about a zebra? It's colors are black and white, and would match this website's color scheme. No wait, a zebra unicorn. You know, a zebracorn. The zebra would have a silver unicorn horn.
  9. @lanefu, fair enough. @PDP11, I too have a little confession. After just discouraging a non-systemd-based distro just above, my daily driver laptop has MX Linux, which defaults to a non-systemd init system. So there's irony in the exact opposite direction of you on your systemd-based chromebook. Having said that, I had to use the boot-to-temporary-use-of-systemd option (that MX Linux includes in their Grub menu), because I needed to install and use a snap, and snapd requires systemd (at this time).
  10. esbeeb


  11. I don't object to Devuan, per se, but I think Armbian is already being really, really nice by providing 2 (of the most well-known, popular) distro choices for almost all boards. Attracting legions of serious Linux geeks to Armbian is hard enough, even by offering those much-closer-to-mainstream distro choices. Every contribution matters, and watering down everyone's efforts by supporting too many things will furtherly slow down the overall progress of the whole project. I say that when you take off your "technical glasses", and put on your "Sociological glasses" (as in, don't get too hung up on technicalities, and be honest about available manpower/woman power/personpower), then Devuan becomes a really bad idea fast, never mind which init systems they use. I say Armbian needs to tighten its focus, conserving its rare, precious manpower/woman power/personpower the best it can, not loosen the focus wider by including another (far less popular) distro choice. Supporting a whole 'nother distro will surely be a large undertaking. There are still many smaller, more realistic-to-tackle, outstanding issues even with the two current distro choices, which, if left unfixed, might still be seriously off-putting for a much larger, less geeky, yet linux-appreciating audience.
  12. Since softy has no uninstall feature, it seems to me that maybe the better way to go about it is that softy installs things as docker containers. Then removing those docker containers again would be a clean uninstall.
  13. The penguin on the desktop background is nice, but maybe a bit too generic. How about a female cartoon Panda, or something like that? Panda bears are found in China, and many/most of these ARM boards were made in China. Her name would be "Armanda the Panda". On second thought, maybe the people at LattePanda might feel they are the only ones allowed to use a Panda...
  14. Once people not only get some board all working, but actually deployed to solve some real-world problem, there should be a place on this forum to showcase that, including pictures, or embedded videos. Any tricks or hacks they needed to use could be listed as well, in case others want to also do the same sort of project. For example the OpenMediaVault forum already has a sub-forum like this, called "My NAS build". Maybe this new subforum could be called something like "Deployment Showcase".
  15. There's a cheap M2 SSD, for example for sale here, but it would be a bad idea to use it in any ARM board with an M2 drive slot. I have one of these M2 drives in my laptop, and I learned the hard way how slow it will get within 1 year's use, like 30MB/sec read, 8.5 MB/sec write! Over time, this drive will gradually go slower and slower and slower, until you figure out you need a firmware upgrade. Then you'll need to use the closed-source firmware-upgrading CLI utility that Micron publishes. There is a version for linux, but it's AMD64 only. You might think you can put the M2 drive in a USB-3.0 enclosure, then firmware upgrade it in that enclosure. No, you can't, the firmware upgrader will only work if the M2 drive is installed in an M2 slot on the mobo. See here for more details.