Posts by T-Dawg

    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!

    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!

    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...?

    I ran into this and was able to fix it by simply uninstalling sysv-rc or openrc - whichever one is actually installed. Neither of them are used by OMV 4.x/Debian Jessie, as it's fully on systemd, and systemd-sysv handles it.

    If I try and remove sysv-rc it then just installs openrc at the same time, so still stuck :D


    Also it then starts doing a lot of slightly scary stuff with service runlevels and init.d including saying:

    Code
    **********************************************************************
    *** WARNING: if you are replacing sysv-rc by OpenRC, then you must ***
    *** reboot immediately using the following command: ***
    for file in /etc/rc0.d/K*; do s=`basename $(readlink "$file")` ; /etc/init.d/$s stop; done
    **********************************************************************

    Try omv-aptclean to see it if fixes the issue. I have the newer version installed on a test VM.

    Thanks for the quick response :)


    Given omv-aptclean a go - everything suceeds with the command fine, no errors (clears out a bunch of lists) but same problem persists unfortunately... dist-upgrade wants to upgrade zfs-dkms and blow OMV away

    Been using ZFS with the plugin happily for quite a while now. Noticed a couple of weeks ago that a dist-upgrade would now break my OMV install (and try to uninstall) because of ZFS updates which conflict (I've held them back for now)


    I use stretch backports kernel (currently 4.19.37-4~bpo9+1) and current ZFS packages:

    Code
    # dpkg -l | grep zfs
    ii libzfs2linux 0.7.12-2+deb10u1~bpo9+1 amd64 OpenZFS filesystem library for Linux
    ii openmediavault-zfs 4.0.4 amd64 OpenMediaVault plugin for ZFS
    ii zfs-dkms 0.7.12-1~bpo9+1 all OpenZFS filesystem kernel modules for Linux
    ii zfs-zed 0.7.12-1~bpo9+1 amd64 OpenZFS Event Daemon
    ii zfsutils-linux 0.7.12-1~bpo9+1 amd64 command-line tools to manage OpenZFS filesystems


    It looks like apt only wants to minor upgrade me from 0.7.12-1~bpo9+1 to 0.7.12-2+deb10u1~bpo9+1:


    But that seems to be enough for it to conflict with the ZFS plugin and make it want to uninstall everything:

    Code
    The following packages will be REMOVED:
    openmediavault openmediavault-luksencryption openmediavault-omvextrasorg openmediavault-zfs systemd-sysv sysv-rc zfs-zed zfsutils-linux
    The following NEW packages will be installed:
    cgmanager libcgmanager0 libeinfo1 librc1 openrc systemd-shim sysvinit-core
    The following packages will be upgraded:
    zfs-dkms

    Any thoughts on how to get around this?