Upgrading to OMV 5.0 issues with Salt monit config (I think...)

  • Doing the upgrade from 4.x to 5.x - everything was smooth sailing until the end when apt went to set up OMV:



    After doing various bits of digging around, I figured that Salt attempting to config monit might be the issue, so I ran omv-salt deploy run monit on it's own:



    Looking at the monit SLS file, I presume this is failing on: {% set email_config = salt['omv_conf.get']('conf.system.notification.email') %}



    With that in mind, I did a omv-confdbadm read conf.system.notification.email which returns the correct XML snippet with my monitoring config...



    However the fact the error says it can't even find omv_conf.get suggests something even more basic is failing, but I can't figure out what...?

  • STrange, that should never happen because Salt is updated some lines before in the package postinst script. This state is syncing the runner and modules to allow Salt to use them in other states.

    So, interestingly I actually ran salt-call --local --retcode-passthrough --no-color state.orchestrate omv.stage.prepare for troubleshooting before I posted my post too (after reading it on this post) but that didn't help. I didn't include it in steps here since I figured it was a red herring



    The orchestrate/prepare runs OK with no errors on any of the runners but still the same error on omv-salt deploy, weird!

  • I finally cracked it!


    I was running the salt-call straight from the script and completely missed the >dev/null


    Removing the pipe, I then got:



    One step closer... so let's run get_root_filesystem:

    Code
    > salt-call --local --retcode-passthrough --no-color --out=json omv_utils.get_root_filesystem
    
    
    'omv_utils' __virtual__ returned False: No module named 'pyudev'

    python3-pyudev dpkg is installed though... but running apt reinstall -f python3-pyudev and now working:


    Code
    > salt-call --local --retcode-passthrough --no-color --out=json omv_utils.get_root_filesystem
    {
        "local": "/dev/sde1"
    }

    Re-run the dpkg install and everything went fine (well... various DNS issues following the upgrade but I fixed this by forcing DNS servers through systemd-resolv - no idea what the deal is there)


    So yeah... not too sure where that python package went during the upgrade!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!