OMV Upgrade Plan

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?

Zitat von chuckado

do i need to do anything specific because I am running the pve kernel?

No. The sed commands will change the repo to get the proxmox repo you need.

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.

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.

Zitat von 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).

Zitat von grokov

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.

Zitat von grokov

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.

Zitat von Adoby

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.

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.

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