Yeah it was.
OMV 5.0 - finally out! :-)
-
- OMV 5.x
- Mr Smile
- Closed
-
-
Thanks guys! I do not plan to upgrade.
Regards Hoppel
-
The main problem for me now in omv4 when using proxmox kernel, is that the proxmox team doesn't deliver anymore kernel update, that is pretty much all reserved for pve6, so this could potentially be security problem in the future for OMV4.
-
-
The main problem for me now in omv4 when using proxmox kernel, is that the proxmox team doesn't deliver anymore kernel update, that is pretty much all reserved for pve6, so this could potentially be security problem in the future for OMV4.
The backports kernel will stop receiving updates as well (once stretch goes on extended support). If someone doesn't want to update, the really should be using the standard kernel.
-
The backports kernel will stop receiving updates as well (once stretch goes on extended support). If someone doesn't want to update, the really should be using the standard kernel.
How can you tell if you're using the backports, standard or promox kernel?
Sent from my BBF100-2 using Tapatalk
-
How can you tell if you're using the backports, standard or promox kernel?
You would know if you were using the proxmox kernel because you have to manually install it. The backports kernel is the default in OMV. Otherwise, when you login to the OMV web interface, the kernel version will have pve in it for proxmox, bpo for backports, or neither for standard.
-
-
You would know if you were using the proxmox kernel because you have to manually install it. The backports kernel is the default in OMV. Otherwise, when you login to the OMV web interface, the kernel version will have pve in it for proxmox, bpo for backports, or neither for standard.
So if I'm perfectly happy with my OMV box running on OMV 4 for a very long time (don't have any interest in upgrading yet), is there any downside to moving over to the standard kernel (I checked, I am indeed on the backports - which I thought I was)? If I were to do that, how do I do it?
-
is there any downside to moving over to the standard kernel
Depending on your hardware, it might not have drivers you need. It could be less power efficient. Hard to say. The backports kernel will still be supported for quite a while. By the time it isn't supported, I would seriously consider upgrading.
-
Domoticz uses now GLIBC >=2.27 so Debian Buster is required to get it working.
It's terrible I have to choose between OMV and Domoticz. -
-
OMV 5 is okay ATM. The upgrade isn't that peachy(i had some trouble with zfs upgrading and omvextras),but can be done.
I personally don't see the difference betweend OMV4 and OMV5
The one glaringly obvious difference is the lack of a Docker GUI in OMV5 (OK, it is not in the base OMV5 but in the extras).
The one problem I have, is that I can't get Pi-Hole to run stable under OMV5, neither under the basic version nor under the Proxmox version (both installations from scratch).
-
Domoticz uses now GLIBC >=2.27 so Debian Buster is required to get it working.
It's terrible I have to choose between OMV and Domoticz.Domoticz in a docker should insulate you from problems like this.
-
Ok thank you, let's start learning Docker.
----
Well, there is lot of threads on Internet talking about Domoticz / Docker issues (for example, using a RFXCom or losing database after a restart). I don't want again to have a poor unreliable Domotic system, mine is now very mature with Domoticz and this is essential for me. Thank you anyway. -
-
The one glaringly obvious difference is the lack of a Docker GUI in OMV5 (OK, it is not in the base OMV5 but in the extras).
Docker has always been in omv-extras on OMV. The plugin did go away in favor of portainer in OMV 5.x. It is a much more powerful (and maintained) gui for docker. omv-extras has a button to install it as well.
I don't want again to have a poor unreliable Domotic system, mine is now very mature with Domoticz and this is essential for me.
So, run it in a Debian Buster VM. There should be no reliability differences between a physical install and a VM.
-
Docker has always been in omv-extras on OMV. The plugin did go away in favor of portainer in OMV 5.x. It is a much more powerful (and maintained) gui for docker. omv-extras has a button to install it as well.
I see I didn't communicate that correctly. I know Docker has always been in OMV-Extras, but the Docker GUI is missing in OMV5.
I find deploying images to containers to be easier with the old Docker GUI. Once I have a container, I can manipulate it equally easy both ways, but I must admit Portainer makes it a lot easier to change the image source when updating.
And it is a shame Portainer still needs version 2 of Docker Compose yaml when adding a stack because most published yamls are version 3 (as is the output of autocompose). -
I find deploying images to containers to be easier with the old Docker GUI. Once I have a container, I can manipulate it equally easy both ways, but I must admit Portainer makes it a lot easier to change the image source when updating.
Other than the fact that no one is maintaining the docker plugin, portainer is actively maintained and many more features. So, it just makes sense to use it.
And it is a shame Portainer still needs version 2 of Docker Compose yaml when adding a stack because most published yamls are version 3 (as is the output of autocompose).
The docker gui plugin didn't support any docker compose file. So, portainer is still ahead of that. You can still use compose v3 from the command line.
-
-
Aaron,i guess we will also need to reinstall(delete,and then add) flashmemory plugin, because it is based on omv-makeconf and such commands.
-
guess we will also need to reinstall(delete,and then add) flashmemory plugin, because it is based on omv-makeconf and such commands.
A new version of that plugin should be able to be installed over the old version. No need to uninstall it first. So, upgrading omv-extras will update the repos and then an apt-get upgrade should just upgrade it. Now that I think about it, it would've been nice if omv-mkconf was just deprecated (and become the second choice instead of default) instead of being removed. This would make upgrades go much better. Plugins that have a logging tag in the diagnostics section would still break the web interface because they use the PluginManager though until they were upgraded.
-
New - 2020.12.29
I recommend following this post now for upgrades - Upgrade Scripts for non-interactive major release upgrades (2->3, 3->4, 4->5)
Aaron,i guess we will also need to reinstall(delete,and then add) flashmemory plugin, because it is based on omv-makeconf and such commands.
On a test OMV 4.x system with the flashmemory plugin installed, this is all I did to upgrade it to OMV 5.x (as root):
I changed this to a script (no changes but eliminates the cut&paste issues:
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/upgrade4to5 | sudo bashreboot
apt-get purge openmediavault-omvextrasorg resolvconf
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash
apt-get update
apt-get dist-upgradeomv-salt deploy run nginx
apt-get install usrmerge
omv-confdbadm migrate conf 5.0.0
Clear your browser cache after upgrading!
-
-
Yeah that's the same procedure i tried, but zfs and flashmemory gave me headaaches. Docker not so much.
-
flashmemory gave me headaaches
This doesn't make sense to me. The plugin is barely different between 4.x and 5.x.
zfs
Proxmox kernel on OMV 4.x? If so, that makes sense since the proxmox kernel won't just upgrade.
Docker not so much.
Pretty sure they are the same package. So, that makes sense.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!