OMV for RockPro64 (and other RK3399 devices soon)

    • tkaiser wrote:

      Robbin wrote:

      Any ideas what to try to fix?
      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 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: cnx-software.com/2019/01/17/at…-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.
    • tobefond wrote:

      After updating the system the HDMI output is corrupted

      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.
    • tkaiser wrote:

      tobefond wrote:

      After updating the system the HDMI output is corrupted
      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.
    • tobefond wrote:

      That means I should never use the "update management" within OMV and use the image as it is???
      That isn't what he said. Most updates other than the kernel are from Debian and you most likely won't have this problem. If Armbian makes change that ruins your system, file a big report with Armbian. If your system is ultra important, then you should have a backup and test updates before using them on a production system. This applies to updates on anything (have you seen the bad Windows updates lately??).

      tobefond wrote:

      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.
      So update everything except for the kernel. This doesn't protect you against security issues but I don't have any other solution if Armbian won't fix it other than use an x86 machine where the kernel is maintained by Debian.
      omv 5.3.2 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.4
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • tobefond wrote:

      That means I should never use the "update management" within OMV and use the image as it is???

      No. Updates are important. Applying security updates in a timely fashion is strongly recommended. This also applies to the kernel which on all ARM images is provided by Armbian (RPi is an exception but RPi isn't a true ARM platform anyway).

      That said it's a real problem. My personal approach is to use armbian-config to freeze kernel/bootloader updates so I can simply update the system knowing that I need to take extra steps for kernel updates. I then offline clone my systems prior to unfreezing Armbian repository so I've always a working backup in case a kernel or u-boot update bricks my system or destroys functionality (often for no reason other than Armbian 'project lead' doing whatever he thinks would be a great idea without communicating or asking for consensus).

      Please remember that usual situation on ARM when your system is not based on Armbian is this: you run a horribly outdated kernel full of security holes that will never get fixed by anyone. So using Armbian as basis is a HUGE improvement. Unfortunately the countless upgrade hassles within the last 12 months prove that 'stable' is a principle not known at 'Armbian headquarters' so we have to walk the extra mile to deal with this.

      The post was edited 1 time, last by tkaiser ().

    • Robbin wrote:

      @tkaiser long story short: can we update OMV via web GUI or we should make extra measures to be sure kernel is not updated all of a sudden? Since OMV is based on Armbian, I assume whenever Armbian updates kernel it also becomes part of OMV update via GUI.
      Sorry, got a bit confused.
      I think what you need to do is:
      • SSH into your system
      • Run command below

      Source Code

      1. armbian-config
      • Go to 'System'
      • Select 'Freeze'
      • Do you want to freeze Armbian firmware updates?
        • 'Freeze'


      But I'm not sure if this only freezes the kernel updates or also the other Armbian updates which might require updating. Hopefully @tkaiser can elaborate on this?


      Another question for @tkaiser, I've recently updated the kernel on my NanoPC T4. I was able to roll it back by 'switching to other kernels' in the armbian-config utility. Is there an easy way to roll back to older kernels?

      Issue I have now is that USB3.0 speed dropped to ~10 MB/s whereas it was ~100 MB/s a few weeks ago. I expect the kernel to be the culprit, however not 100% sure of this. This is still on a "test" system so I could easily flash your OMV image. However if this happens in the future when the server is in operation than I cannot easily start from scratch.
    • Alexio wrote:

      But I'm not sure if this only freezes the kernel updates or also the other Armbian updates which might require updating

      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).
    • Robbin wrote:

      can we update OMV via web GUI or we should make extra measures to be sure kernel is not updated all of a sudden? Since OMV is based on Armbian, I assume whenever Armbian updates kernel it also becomes part of OMV update via GUI.
      Did you read what I wrote? I have no problems updating the kernel on my armbian-based boards. Because the kernel is a package in a repo enabled on the board, it is going to show up in the Updates tab. If you are that paranoid and can't test, you can use the apttool plugin to mark the kernel on hold.
      omv 5.3.2 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.4
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • tkaiser wrote:

      Alexio wrote:

      But I'm not sure if this only freezes the kernel updates or also the other Armbian updates which might require updating
      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.
    • I think avoiding updates is a bad idea and leaves you in a vulnerable security situation. tkaiser can't tell you what you should and shouldn't update because you may or may not use things affected. And it seems like the kernel is the "cause" in all of these situations. I've been using armbian on four devices for a long time now and haven't experienced any of these issues.

      tobefond wrote:

      It could help several users if you could provide a short summary how we should perform recomended updates
      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.
      omv 5.3.2 usul | 64 bit | 5.3 proxmox kernel | omvextrasorg 5.2.4
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • ryecoaaron wrote:


      tobefond wrote:

      It could help several users if you could provide a short summary how we should perform recomended updates
      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.
    • ryecoaaron wrote:

      And it seems like the kernel is the "cause" in all of these situations.
      Bootloader, kernel or device-tree flaws (well that could be called kernel too). In early 2018 I counted 5 occasions affecting different board families where 'Armbian' introduced upgrade hassles resulting even in bricked installations for no reason and few weeks ago a totally unnecessary kernel upgrade for ODROID XU4/HC1/HC2 happened for no other reason than 'Armbian headquarters' thinking it would be a great idea to switch on all productive installations from Hardkernel's well known 4.14 kernel to upstream mainline kernel 4.19 lacking functionality). Neither discussion nor announcement happened. It was just there in the repo and people started to realize that the result of upgrading their systems via apt-get update (or OMV's update mechanism) resulted in lost functionality.

      In all occasions a lot of time was needed to be wasted on discussions about this 'process' and the updates have been reverted after these discussions. At least I'm totally sick of this since all these hassles were totally unnecessary. But it seems the idea of 'stable' is nothing 'Armbian headquarters' is taking care of.

      That's why I freeze kernel/bootloader packages since a lot of my machines are at remote locations and the last thing I need is a bricked board after an update (experiences this way too often with Armbian already in last 2 years). Updates for bootloader/kernel are only applied after tests with local test machines.
    • 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?
    • Users Online 1

      1 Guest