OMV Upgrade Plan

  • Hello,


    I plan to install OMV5 in a vm to get used to the new interface and ways of doing things so i can try to best replicate my current OMV4 config. As far as my actual NAS goes, my plan was to put a new USB drive in and just install OMV5 to it and then redo my configuration based on my findings from the virtual machine. After installation of OMV5 will it pick up both of software mdadm raids? Also does this sound like a good strategy to getting my NAS back up and functioning quickly and correctly?

  • Here is the upgrade procedure described.

    RE: OMV 5.0 - finally out! :-)


    If it works, no reinstallation needed. But you should make a clone of your OS first so that you can go back in case something goes wrong.


    And as always you should have backup of your data.

  • This is how I intend to upgrade my Odroid HC2s from OMV4 to OMV5.


    I intend to reinstall everything from scratch.


    I will first do a test install on a test HC2 to make sure I understand how to use portainer and configure dockers right. I may have some false starts so I will first create a basic test system with everything but portainer and docker and clone that. Then I can try again without having to start over from scratch.


    Also I may try to figure out a some way to avoid using the ugly path names needed since /sharedfolders is a Bad™ thing (slow?) with OMV5 (SALT?). I am not sure what is easiest and won't slow down reconfigurations. I expect to need three "shortcut" paths on each HC2. One "docker" for docker images, one "appdata" for docker appdata and one "nas#" for the main shared folder, the same as the host name.


    Then, once I understand how to use pretty and efficient shortcuts to ugly sharedfolders paths, portainer and docker in OMV5, I will start for real.


    First I will do a generic install using default settings, DHCP and a generic host name: "noname". And I will add stuff like midnight commander, ffmpeg, ImageMagick, 7z, media-info, parallel, autofs and iftop packages. Set all the basic parameters like timezone and so on. Everything that is common for all my OMV servers. And then I will update and upgrade.


    Then I will clone this generic install. This will be my own "master generic image" for OMV5. I will keep it as the basis for future use. I may later update and upgrade this image.


    I will then start using copies of this master clone as the basis for my actual installations. I will have to boot my OMV servers one by one as a generic "noname" clone and set the host name to a matching existing static lease entry in my DHCP-server. And then reboot again to assign that IP.


    Once this is done on all the OMV servers I can start adding drives, filesystems, shares, autofs and services. And add some form of shortcuts to avoid using ugly paths to devices. I will do things just as it was on OMV4, as much as possible. KISS!


    Once this is done on all the OMV servers I will reboot them again and verify that all the OMV serves now have access to the main shares of each other using autofs and NFS. And clients using autofs, NFS or SMB.


    Then I will update the backup scripts with the correct paths. And add entries to them in /etc/crontab. And verify that the backup scripts all work correctly. And do the same for all other devices with scripts that access the OMV servers.


    Then I will run an update and upgrade again. And then shut down the OMV servers. And clone again. This time one clone per OMV server.


    Then I will add portainer and dockers. And configure the clients that use them.


    I really want a rsync snapshot script that temporarily shuts down all things docker and then creates an updated snapshot of docker images and docker appdata and then restarts all things docker. This may be the time to write that script.


    Then I will update and upgrade again. Shut down and clone again.


    And I am done... I think... :?:


    When is OMV4 EOL? When is OMV6 due? :S

    Be smart - be lazy. Clone your rootfs. This help is Grateful™.
    OMV 4: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

    Edited 3 times, last by Adoby ().

  • Also I may try to figure out a some way to avoid using the ugly path names needed since /sharedfolders is a Bad™ thing (slow?) with OMV5 (SALT?).

    Is there any detail on this change? I saw it in the changelog, but don't understand what is the new "good" way.


    I too have /sharedfolders on my H2C and wonder what the better approach is for OMV5: changing the directory structure on the HDD or adapting OMV configuration?

  • In OMV4 there are "shortcuts" to the shared folders created under /sharedfolders. So the share "my_share" can be accessed as:


    /sharedfolders/my_share


    Nice!


    The ACTUAL shared folder (not the shortcut) is naturally on the HDD and can be found as something like:


    /srv/dev-disk-by-label-XXXXXXX/my_share


    Longer and ugly compared to the shortcut.


    But...


    Some software can have problems with the nice shortcuts. It seems. I haven't experienced it myself. Also the nice shortcut make applying changes in OMV5 take significantly longer time. And salt already is pretty slow. So anything that makes salt work faster when applying changes to the configuration is good. Possibly even Good™ when it comes to slower and less powerful devices like SBCs.


    Possible things to try might be to mount the share somewhere, using an entry in fstab. Or use a link. Or use the path under /exports. Or something else. Or even use the ugly path, perhaps with a nice disk label. And check what works OK in scripts and elsewhere and doesn't cause salt applying changes to slow down.


    If you don't use scripts or often use paths into shared folders for some other reason, then this may not matter at all to you.

    Be smart - be lazy. Clone your rootfs. This help is Grateful™.
    OMV 4: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

    Edited once, last by Adoby ().

  • OMV5, by default, just use the shared folder where it is. The long path.


    Sure, salt is well documented. Just Google SaltStack.


    Once I have configured OMV, I expect to rarely touch the configuration again. And will not have any problems with salt being slow. I hope...


    Almost the only time I use the OMV4 GUI is when I do the initial config. And later, when I update update software.

    Be smart - be lazy. Clone your rootfs. This help is Grateful™.
    OMV 4: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

    Edited once, last by Adoby ().

  • Also I may try to figure out a some way to avoid using the ugly path names needed since /sharedfolders is a Bad™ thing (slow?) with OMV5 (SALT?). I am not sure what is easiest and won't slow down reconfigurations.

    symlinks. There is even a plugin to create them (not that you need one).

    Where does it create/expect shared folders?

    Nothing has changed other than OMV 5 is not creating the /sharedfolders bind mount by default. As I mentioned above, you can use a symlink if a shorter path is desired.

    OMV5 looking like quite the downgrade in performance, at least for SBCs: salt on OMV5

    This has nothing to do with performance of the device as a NAS. It *only* affects the web interface when changing settings. Most people setup a device and rarely change settings after that. So, I'm not sure why this is a huge deal.

    Once I have configured OMV, I expect to rarely touch the configuration again. And will not have any problems with salt being slow. I hope...

    Hope? Salt doesn't do anything other than configuration management. No need to hope it doesn't causing problems. It is doing the same thing the shell scripts used to do but better although slower.

    omv 5.5.0 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.3
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • Nothing has changed other than OMV 5 is not creating the /sharedfolders bind mount by default. As I mentioned above, you can use a symlink if a shorter path is desired.

    Given that I already have /sharedfolders (not many though) what would be the best practice when moving to OMV5?


    Creating symlinks in OMV or making other arrangements, such as changing the references to /sharedfolders?


    This has nothing to do with performance of the device as a NAS. It *only* affects the web interface when changing settings. Most people setup a device and rarely change settings after that. So, I'm not sure why this is a huge deal.

    I get that, but "snappiness" of the user interface is often taken as a proxy to performance and is kind of expected of newer and better releases. It certainly affects the user experience. Long waits when changing settings will be annoying, but you're right that after the initial setup it won't make any difference.

  • When it comes to /sharedfolders, you have to decide what works best for you.


    If you don't use ssh and don't write your own scripts or use the command line, then you will hardly notice any difference.


    Do nothing and use the actual paths.

    Create symlinks.

    Activate /sharedfolders and slow down salt more.

    Something else.


    I will start with symlinks.

    Be smart - be lazy. Clone your rootfs. This help is Grateful™.
    OMV 4: 9 x Odroid HC2 + 1 x Odroid HC1 + 1 x Raspberry Pi 4

  • Just as a follow up, I'm happy with the upgrade to OMV5.


    I didn't bother with /sharedfolders or symlinks and just used the /srv/... full path.


    Updating settings does take a long time in some cases with OMV5, maybe up to nearly 5 minutes on an Odroid, but not always. Sometimes it's not quite so long. What I really like is that OMV5, whether due to Debian/Armbian or OMV5, is responsive much sooner in the boot process than OMV4. Within a few seconds, before booting is completed, it responds to pings, allows logging into the webgui, etc.


    Boot time is also faster for me at ~45 seconds.


    So far it's great!

  • after upgrading omv4 to omv5 there is an issue with shellinabox which i start from the webbrowser with


    https://j3455-itx:4200/


    Code
    j3455-itx login: root command-line line 0: Unsupported option "rhostsrsaauthentication" command-line line 0: Unsupported option "rsaauthentication" root@j3455-itx.fritz.box's password: Linux j3455-itx.fritz.box 5.4.0-0.bpo.4-amd64 #1 SMP Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64
  • The plugin should have been removed prior update as it is not available for OMV5


    RE: Why should you use or not use dockers


    On windows you can use "command prompt" or "powershell" to ssh into your server. Just type


    ssh user@ip.of.your.server

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!