Posts by tobefond

    Does NOT increase bandwidth.

    Do you know any possibility to increase network speed with multiple lines to allow paralell access of multiple users to access the NAS with high speed? I like the excellent speed, low price and low power consumption of the nanoPC T4 - all in a very small box. But I lwould like to further increase network speed - to get an even more outstanding cpmbination of speed, low power consumption, low price in a small box. Beside of that OMV meets all my requirements.

    Sorry, Network Manager. That's Armbian's default. To get rid of ifupdown behavior most probably you need to delete the interface in the OMV UI, then check /etc/network/interfaces and delete potential leftovers, reboot (DHCP then) and then either assign a static IP address using nmtui or let your router do the job.
    NM takes care about links that went down and brings them up when available again...

    Thanks, seems to work. Deleted the interface in OMV UI and afterwards /etc/network/interfaces was empty and the T4 got a DHCP address from the router after restart. After configuring address distribution at the router for the T4 the T4 now has it previous known address. Restart of the router is now no longer an issue - network connection gets re-connected afterwards. Thanks again.

    Then most probably behavior is as expected. While I have no idea why people do set static IP addresses (why remembering those silly numbers, why not accessing your NAS by its name http://nanopct4.local) to get the desired behavior I would assume letting NM control the interface will result in what you want.
    With OMV5 OMV's networking handling will move from anachronistic ifupdown to systemd -- maybe it's fixed that way too...

    I did setup the static IP to setup port forwarding and to setup automated backups of some devices. On some device I can only define a IP adress in order to access the NAS.
    What do you mean the NM? The Network Router in my case? Do I just need to delete the line in OMV UI and perform the definition of the IP on router side?

    My question was whether you configured this 'static IP address' via OMV UI or not. If you did it the OMV way then Debian's ifupdown package controls the NIC but if you leave things as they are when booting first time (or set a static address via nmtui) then Network Manager has control (and with NM this should work -- I have no idea about ifupdown since I hate using anachronistic mechanisms from last century)

    I did set the static IP via OMV UI.

    I am not sure if the following issue is related to the T4 image only. After restart of the network router the T4 does not reconnect automaticly to the network. I have to restart also the T4 in order reconnect the network. Is there any possibility the T4 tries to reconnects automaticly to the network after it lost connection for whatever reason?

    I'm not sure why you insist on ignoring me and asking this question again. I answered this question in post #44. If installing all updates was a serious issue, we would have hundreds of users having problems.

    Hello ryecoaaron, I am sorry you feel ignored. This was not my intension.
    So the conclusion is to update everything except for the kernel and we have to live with security issues unsing omv on a nanopc t4.

    No idea. armbian-config was an optional tool a while ago and not just me argued against an integration but in the meantime Igor made it an integral part of Armbian (while it's still a one man show) and encourages everyone to constantly switch between kernels and so on so that all the tries to provide a supportable installation base are rendered useless.


    I've no idea what 'Armbian firmware updates' are (Armbian or lets better say Igor also provides a huge armbian-firmware package containing wireless firmwares and such stuff and ignored countless developer discussions to clean up this mess), IIRC the menu item to stop kernel and bootloader upgrade hassles was called differently. I only tried to address some serious security issues in armbian-config, then improved OMV integration issues but have given up on trying to fix stuff there already a while ago (same is true for Armbian in general now).

    Hello tkaiser, a less experienced user like me is a little confused because I can not see behind the curtain of omv/armbian and how misaligned some developers may work. It seems you have a very clear picture, what happens behind the curtain. It could help several users if you could provide a short summary how we should perform recomended updates. Maybe some "Do" and "Do not" to stay clean but updated.

    So what? That's a kernel thing, the kernel is part of Armbian and I finally got sick of the totally unnecessary upgrade hassles the Armbian 'project head' integrates every now and then. I discussed the issue for more than a year and simply gave up in the meantime.


    With next kernel/device-tree update maybe networking might gone... I don't care any more.

    OK, that is new information for me. That means I should never use the "update management" within OMV and use the image as it is??? So what is the purpose to have such option "update management" on OMV web gui ?
    Without the updates the system was little unstable crashing once per week. After updating the system it became very stable - no crashes anymore but no HDMI output. However the HDMI output is usually not needed on a NAS application.

    Nope, I never connected a display to the majority of my ARM boards and since OMV is meant to be administrated headless (using the web UI or SSH/shellinabox) I don't consider this being a problem.
    If a ping nanopim4 works in your network everything is alright and you can access the box using http://nanopim4


    BTW: NanoPi M4 as well as NEO4 are prone to undervoltage, OMV/Armbian uses more demanding settings than FriendlyELEC's offerings and caused by this the voltage available on the HDMI port might fall below the allowed 4.8V so no display negotiation might happen. Details: https://www.cnx-software.com/2…-b-type-a/#comment-560002

    I can confirm - no HDMI output anymore. Using the regular armbian images without omv deliver HDMI output and even the original omv images. After updating the system the HDMI output is corrupted. SSH and everything else works fine. Just no HDMI output.

    Latest Image for nano PC T4 seems to have an issue with static IP adress. As soon as I set a static IP adress the device takes over the new adress and it connects to the router with the IP adress after reboot. But the web GUI is no longer accessable. I can connect to the device via putty but web GUI is not starting. So I tried an older image for the T4 and it is working with static IP.

    What speed can you get copying from NVMe ssd to HDD? And via which sata controller is the HDD connected?
    For reference : I'm in a boat choosing between the Odroid HC2, Nanopc-T4, Nanopi M4 and the Rockpro64.
    main reason is that I prefer to have a SSD/HDD combination to increase download speed with NZBGET (downloading to SSD, unpacking to HDD).

    I am using an older HDD connected via USB3.0. Running a backup from NVMe to HDD I get transfer speeds of about 120MB/s. But the speed is limited by the old HDD writing speed. The NanoPC T4 could transfer much faster with newer and faster HDD or SSD.
    However I would not take the HC2 since it is slower and no USB3.0 is available (i.e. for fast backups).
    I would go with a M4 or T4. With the M4 you have the advantage of a reasonable passive heat sink. For the T4 you need a fan or bigger custommade heat sink. The advantage of the T4 is the NVMe slot and with an NVMe SSD the T4 feels extremely fast responsive.

    Sure, I even linked to it from the review you quoted --> https://github.com/ThomasKaise…es/Heatsink_Efficiency.md (TL;DR: the NEO4 heatsink is not great for sustained highest loads)

    OK your testing on NanoPi NEO4 tells me that it is almost impossible to cool the NanoPC T4 with a passive heat sink in a condition with 100% CPU load over longer period of time. However my custom made heat sink (height 48mm!) is now sufficient for NAS application since CPU load does not exceed 50% running openmediavault - even with NVMe SSD and many paralell tasks (i.e. back to USB3.0 drive + other network traffic).

    The large heat sink seems to be an big advantage for the NanoPi NEO4. I tried to keep the NanoPC T4 cool by several huge custom made passive heatsinks. This is almost impossible if you need CPU/GPU load 80-100%. So with continiosly higher CPU/GPU loads a fan is mandatory on the NanoPC T4. Does someone has testet the NanoPi NEO4 with heatsink an higher CPU/GPU loads?

    I don't think your updating problems were related since basically the images only differ in two single locations: /boot/armbianEnv.txt (here it's a single line responsible for loading the correct device tree file) and then it's BOARD and BOARD_NAME entries in /etc/armbian-release.
    @ryecoaaron can you please replace the incorrect T4 image?

    I think the update issue is related to the "Plex Media Server" plugin. After instalation of Plex on the T4 system the update problem came back. Even after removing Plex the issue is still present. It comes with Plex, but it is not leaving with de-install of Plex.

    On SourceForge for whatever reasons yes. The PC-T4 image is the one for NanoPi M4.


    Original situation: http://kaiser-edv.de/tmp/xdNAzx/

    Code
    root@lime2:/var/www/kaiser-edv.de/tmp/xdNAzx# md5sum *
    b521ec66f3c698e699d95542aa7e3fed OMV_4_NanoPC_T4.img.xz
    608fe5bbb7ebd4d9e7acf880e9a56aaf OMV_4_NanoPi_K1_Plus.img.xz
    a2ababb0b95bbf873cb8efe82c4945af OMV_4_NanoPi_M4.img.xz

    Thanks a lot, now I got the right image. HW must be very similar between M4 and T4 because the Image for M4 was running fine on T4, except for problems with updates. Now with the right image the updates are running without any error. Thanks again.