Debian 10 - OMV 4.x

  • I have a VM with debian 9, OMV 4 using ZFS as root filesystem. I use it mostly for testing, so I upgraded it to debian 10 a few days ago and I had no problems. YMMV.

    OMV 4.1 on Debian 10 @ HP Microserver gen8 [2x 256GB SSD ZFS mirror on root + 3x 8TB ZFS raidz1 pool]

  • I have a VM with debian 9, OMV 4 using ZFS as root filesystem. I use it mostly for testing, so I upgraded it to debian 10 a few days ago and I had no problems. YMMV.

    Great to hear that! I'll go the same way. First on a VM (with snapshot), finally my NAS server.

  • so I upgraded it to debian 10 a few days ago and I had no problems. YMMV.

    The only reason this has a chance of working is that it doesn't uninstall needed packages from Debian 9. You do not want to do this.

    Great to hear that! I'll go the same way. First on a VM (with snapshot), finally my NAS server.

    Just don't...

    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!

  • Just don't...

    Sorry, to late. Yesterday I upgraded my NAS to stable and everything still up and running, no issues. First I performed the interface renaming procedure and then a usual "apt-get upgrade" & "apt full-upgrade". Everything fine, the OMV interface is still functional.


    Hilmar, running Debian for > 18 years.

  • Sorry, to late. Yesterday I upgraded my NAS to stable and everything still up and running, no issues. First I performed the interface renaming procedure and then a usual "apt-get upgrade" & "apt full-upgrade". Everything fine, the OMV interface is still functional.


    Hilmar, running Debian for > 18 years.

    If you have been running Debian for more than 18 years, then you should know what happens if you leave stretch packages installed on a buster machine. The only reason this works is because the php packages (and probably a few others) from stretch stay installed. These packages will never get patched and it is bad to not patch php. If the machine is fine with Debian 9, what is the motivation to run a frankenstein setup like this?? If you need newer packages, that is where docker solves the problem.

    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!

  • If you have been running Debian for more than 18 years, then you should know what happens if you leave stretch packages installed on a buster machine. The only reason this works is because the php packages (and probably a few others) from stretch stay installed. These packages will never get patched and it is bad to not patch php.

    I'm aware of the implications. However I know, which packages are left and I know too, that I have to patch them manually if needed. I'm subscribed to debian-security-announce@lists.debian.org, and hence follow the advisories. And yes I know too that my procedure is not recommeded for all users!


    hille@nas1:~$ apt-forktracer |grep -v openmediavault.org|sort
    gcc-6-base (6.3.0-18+deb9u1)
    monit (1:5.20.0-6)
    openjdk-8-jre-headless (8u222-b10-1~deb9u1)
    perl-modules-5.24 (5.24.1-3+deb9u5)
    php7.0-bcmath (7.0.33-0+deb9u3)
    php7.0-cgi (7.0.33-0+deb9u3)
    php7.0-cli (7.0.33-0+deb9u3)
    php7.0-common (7.0.33-0+deb9u3)
    php7.0-fpm (7.0.33-0+deb9u3)
    php7.0-json (7.0.33-0+deb9u3)
    php7.0-mbstring (7.0.33-0+deb9u3)
    php7.0-opcache (7.0.33-0+deb9u3)
    php7.0-readline (7.0.33-0+deb9u3)
    php7.0-xml (7.0.33-0+deb9u3)


    Given the fact that there is only a small amount of bugs open for OMV 5.0, I'll rather upgrade to it sooner or later at least on T stage. Regards.

  • I'm aware of the implications. /-----/ And yes I know too that my procedure is not recommeded for all users!

    This is why @ryecoaaron is commenting. Without some specific info such as; "These packages will never get patched and it is bad to not patch php" new users may read this thread and think that a Frankenstein approach is OK. Since OMV is designed for new Linux users, this wouldn't be appropriate for the majority of the user base.

  • I'm aware of the implications. However I know, which packages are left and I know too, that I have to patch them manually if needed. I'm subscribed to debian-security-announce@lists.debian.org, and hence follow the advisories. And yes I know too that my procedure is not recommeded for all users!

    I still don't understand the motivation. Upgrading to Debian 10 now won't make the upgrade to OMV 5.x easier since the upgrade process makes assumptions that you running Debian 9 and OMV 4.x together.

    Given the fact that there is only a small amount of bugs open for OMV 5.0, I'll rather upgrade to it sooner or later at least on T stage. Regards.

    That is probably because not many people are using it yet. Trust me, the change to using saltstack is a big change. And if you use any omv-extras plugins, I haven't started porting most of them. So, not many bug reports there either.

    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!

Participate now!

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