Upgrade Debian 9 and 4.x

  • I came here by looking for a solution to weakref.py error. I applied the fixes described below, but the web interface would throw a new error on anything I would do with it (for instance, I tried adding a scheduled job):


    Error #0:
    OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; omv-mkconf cron 2>&1' with exit code '1': Failed to import the site module
    Error processing line 1 of /usr/lib/python3/dist-packages/zope.component-4.3.0-nspkg.pth:



    Traceback (most recent call last):
    File "/usr/lib/python3.5/site.py", line 173, in addpackage
    exec(line)
    File "<string>", line 1, in <module>
    File "/usr/lib/python3.5/types.py", line 166, in <module>
    import functools as _functools
    File "/usr/lib/python3.5/functools.py", line 23, in <module>
    from weakref import WeakKeyDictionary
    File "/usr/lib/python3.5/weakref.py", line 109
    def remove(wr, selfref=ref(self)), _atomic_removal=_remove_dead_weakref):
    ^
    SyntaxError: invalid syntax



    During handling of the above exception, another exception occurred:



    Traceback (most recent call last):
    File "/usr/lib/python3.5/site.py", line 580, in <module>
    main()
    File "/usr/lib/python3.5/site.py", line 567, in main
    known_paths = addsitepackages(known_paths)
    File "/usr/lib/python3.5/site.py", line 344, in addsitepackages
    addsitedir(sitedir, known_paths)
    File "/usr/lib/python3.5/site.py", line 212, in addsitedir
    addpackage(sitedir, name, known_paths)
    File "/usr/lib/python3.5/site.py", line 183, in addpackage
    import traceback
    File "/usr/lib/python3.5/traceback.py", line 5, in <module>
    import linecache
    File "/usr/lib/python3.5/linecache.py", line 8, in <module>
    import functools
    File "/usr/lib/python3.5/functools.py", line 23, in <module>
    from weakref import WeakKeyDictionary
    File "/usr/lib/python3.5/weakref.py", line 109
    def remove(wr, selfref=ref(self)), _atomic_removal=_remove_dead_weakref):
    ^
    SyntaxError: invalid syntax in /usr/share/php/openmediavault/system/process.inc:175
    Stack trace:
    #0 /usr/share/openmediavault/engined/module/cron.inc(51): OMV\System\Process->execute()
    #1 /usr/share/openmediavault/engined/rpc/config.inc(168): OMVModuleCron->applyConfig()
    #2 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
    #3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
    #4 /usr/share/php/openmediavault/rpc/serviceabstract.inc(149): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
    #5 /usr/share/php/openmediavault/rpc/serviceabstract.inc(565): OMV\Rpc\ServiceAbstract->OMV\Rpc\{closure}('/tmp/bgstatus04...', '/tmp/bgoutputV2...')
    #6 /usr/share/php/openmediavault/rpc/serviceabstract.inc(159): OMV\Rpc\ServiceAbstract->execBgProc(Object(Closure))
    #7 /usr/share/openmediavault/engined/rpc/config.inc(213): OMV\Rpc\ServiceAbstract->callMethodBg('applyChanges', Array, Array)
    #8 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, Array)
    #9 /usr/share/php/openmediavault/rpc/serviceabstract.inc(123): call_user_func_array(Array, Array)
    #10 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod('applyChangesBg', Array, Array)
    #11 /usr/sbin/omv-engined(536): OMV\Rpc\Rpc::call('Config', 'applyChangesBg', Array, Array, 1)
    #12 {main}


    I reverted weakref.py changes and now the web interface is working normally again.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 6.x (HURRAY) on an Intel i5820K NAS (currently with proxmox kernel 6.2)

  • When you change the lines to the described, it should work:


    Upgrade Debian 9 and 4.x


    Regards Hoppel

    ----------------------------------------------------------------------------------
    openmediavault 6 | proxmox kernel | zfs | docker | kvm
    supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x10tb wd red | digital devices max s8
    ---------------------------------------------------------------------------------------------------------------------------------------

    Edited once, last by hoppel118 ().

    • Official Post

    You have to be careful with "space" and "tab". Not sure what is used (I assume "tab"), but make sure to use exactly what is used in the original weakref.py file.


    But I thought this is fixed in the meantime. Have you updated the system?

  • Odd10: thank you for pointing that out. It seems that I did not pay enough attention to what I was doing and I copy pasted it wrong. This never happened on Linux (I was using KiTTY on Windows). My Python knowledge is close to zero :D


    I updated everything there was to be updated, but it seems that OpenMediaVault 4 is a little behind than OpenMediaVault 3 was in regards to fixes and updates. There are also lots of plugins missing in OMV 3, even after this long period of time of being in Beta. It is still in Beta. Enough offtopic about OMV now.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 6.x (HURRAY) on an Intel i5820K NAS (currently with proxmox kernel 6.2)

    • Official Post

    I updated everything there was to be updated, but it seems that OpenMediaVault 4 is a little behind than OpenMediaVault 3 was in regards to fixes and updates.

    The python bug is not something OMV controls. That is a package in the Debian repos.


    There are also lots of plugins missing in OMV 3, even after this long period of time of being in Beta. It is still in Beta.

    There are no plugins missing (maybe fail2ban) that will be ported to OMV 4. I assume you are referring to the downloader plugins that we think are better suited to docker? OMV + Docker plugin media server (Plex, PlexPy, Ombi, Libresonic, NZBGet, ruTorrent, Sonarr, Radarr, Mylar, and more)

    omv 7.4.9-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.12 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    • Official Post

    I updated everything there was to be updated, but it seems that OpenMediaVault 4 is a little behind than OpenMediaVault 3 was in regards to fixes and updates. There are also lots of plugins missing in OMV 3, even after this long period of time of being in Beta. It is still in Beta. Enough offtopic about OMV now.

    OMV4 is much more stable than all previous versions. Some plugins have been dropped because they can be replaced by Docker containers. Others have been dropped because the maintainers do not support them anymore. If you like, then you can take over the maintenance for missing plugins.

  • I am sorry if I offended anyone, but I went from OMV 2 to 2 instances of OMV 3 and then to OMV 4. I has mostly everything in the latest version of OMV3, but my installation got messed up and I wanted to upgrade.


    I may have been also tired when I modified that Python code. I want an error free installation. Is that such a bad thing? I miss the Deluge integration within the GUI. I am not using any other downloaders. I also updated Plex by hand with help from https://dev2day.de/. I honestly do not see the benefit of running downloaders in Docker.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 6.x (HURRAY) on an Intel i5820K NAS (currently with proxmox kernel 6.2)

    • Official Post

    I honestly do not see the benefit of running downloaders in Docker.

    I can give you a few benefits:

    • We don't have a plugin maintainer so docker is your only option with OMV 4.
    • People who really know the downloader service are most likely maintaining the docker.
    • Downloaders often need bleeding edge dependencies that are not available in the Debian repo. Adding other repos to OMV can cause issues with system stability.
    • Downloaders have been known to do/download bad things. Keeping it in a jail (docker) will greatly reduce the chance of causing harm to things outside of the docker.

    omv 7.4.9-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.12 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • You probably wanted to get rid of some packages because the components that we are discussing about were present there in the previous release of OMV. I know that you upgraded Debian. This situation happened for other when upgrading from OMV 2 to OMV 3. What would it mean to take over the plugins? Is there a github repo where the older plugin is present?

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 6.x (HURRAY) on an Intel i5820K NAS (currently with proxmox kernel 6.2)

    • Official Post

    You probably wanted to get rid of some packages because the components that we are discussing about were present there in the previous release of OMV.

    I wasn't the maintainer of the plugins. And yes, the maintainer did maintain them for a while with OMV 3.x.


    I know that you upgraded Debian.

    I didn't upgrade Debian. Volker is the OMV author and he did choose to Debian 9 for OMV 4.x but that has nothing to do with why the plugins are not maintained/ported to 4.x.


    This situation happened for other when upgrading from OMV 2 to OMV 3.

    I'm not sure what this statement means.


    What would it mean to take over the plugins?

    You make them work although I don't know why you would. Most of the download plugins are just a start/stop. docker is still the best idea.


    Is there a github repo where the older plugin is present?

    Look at my signature.

    omv 7.4.9-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.12 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • I didn't upgrade Debian. Volker is the OMV author and he did choose to Debian 9 for OMV 4.x but that has nothing to do with why the plugins are not maintained/ported to 4.x.

    I thought some plugins were dropped because of being difficult to maintain them with the new Debian and/or new version of OMV.


    I'm not sure what this statement means.

    When I said "you", I meant "you guys/gals that are in charge of OMV or at least maintaing OMV".


    You make them work although I don't know why you would. Most of the download plugins are just a start/stop. docker is still the best idea.

    If you say it is not worth it, then I will not get involved anymore with the downloader plugins. I can live with installing and configuring Deluge by myself. Deluge plugin was the only one I needed.

    Riddle me this, riddle me that
    Who is afraid of the big, black bat?
    I write on a blog (Romanian mostly)
    Testing (latest) OMV 6.x (HURRAY) on an Intel i5820K NAS (currently with proxmox kernel 6.2)

  • Hi guys,


    some days ago my server informed about new python packages, which I installed today.

    Code
    Get:1 http://security.debian.org/debian-security stretch/updates/main amd64 python3.5 amd64 3.5.3-1+deb9u1 [229 kB]
    Get:2 http://security.debian.org/debian-security stretch/updates/main amd64 libpython3.5-stdlib amd64 3.5.3-1+deb9u1 [2167 kB]
    Get:3 http://security.debian.org/debian-security stretch/updates/main amd64 python3.5-minimal amd64 3.5.3-1+deb9u1 [1691 kB]
    Get:4 http://security.debian.org/debian-security stretch/updates/main amd64 libpython3.5-minimal amd64 3.5.3-1+deb9u1 [573 kB]

    After that I installed the new zfs packages and the weakref.py issue is back again:




    So, I googled a bit around and found the following comment at github: https://github.com/OpenTechStr…85#issuecomment-324815526


    Seemingly the issue is solved with python 3.6.1. So we have to wait until that version gets released officially. Until that happens I am using the workaround again.


    Regards Hoppel

    ----------------------------------------------------------------------------------
    openmediavault 6 | proxmox kernel | zfs | docker | kvm
    supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x10tb wd red | digital devices max s8
    ---------------------------------------------------------------------------------------------------------------------------------------

    Edited once, last by hoppel118 ().

  • Seemingly the issue is solved with python 3.6.1. So we have to wait until that version gets released officially

    No.


    If you're interested in this absolutely harmless warning disappearing you need to take action since upstream Debian is not known to increase software versions in a release (the 'stable' mantra). So report issues upstream if you're interested in them getting resolved or live with it: crash omv-mkconf and omv-update

  • Will not you switch to a newer Python package? 3.5+. Clear, I understand that this is a cosmetic problem and can be manually repaired. But I do not understand why 2 years ago this has not moved anywhere and this "problem" is visible at every update/upgrade.

    • Official Post

    Will not you switch to a newer Python package? 3.5+. Clear, I understand that this is a cosmetic problem and can be manually repaired. But I do not understand why 2 years ago this has not moved anywhere and this "problem" is visible at every update/upgrade.

    OMV is Debian and uses whatever is in the Debian repos. We do not maintain packages and it will be fixed when Debian fixes it. Because it causes no problems, most people aren't worried about it. There are workarounds posted in the forum.

    omv 7.4.9-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.12 | k8s 7.3.1-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.9


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • Hi everyone,


    First of all i hope I'm not posting in the wrong thread as this mainly talked about the "weakref.py" error. I tried to fix it by changing the two lines explained in page 2 but no luck, and it does not even appear everytime I run apt-get update (about half the time). Anyway this is not my main issue with updating.


    I have 2 NAS running Debian 9 and OMV 4. Have installed them pretty much the same way but I am now unable to update one of them for some reason (I suspect I have installed something different on this one but can't find out what...). When I try to apt-get upgrade it I run into the following error (sorry this is in french, I can translate if needed) :


    Code
    root@NAS:/# apt-get upgrade
    Lecture des listes de paquets... Fait
    Construction de l'arbre des dépendances
    Lecture des informations d'état... Fait
    Vous pouvez lancer « apt --fix-broken install » pour corriger ces problèmes.
    Les paquets suivants contiennent des dépendances non satisfaites :
     python-samba : Dépend: libwbclient0 (= 2:4.5.12+dfsg-2+deb9u4) mais 2:4.5.16+dfsg-1 est installé
                    Dépend: samba-libs (= 2:4.5.12+dfsg-2+deb9u4) mais 2:4.5.16+dfsg-1 est installé
    E: Dépendances non satisfaites. Essayez « apt --fix-broken install » sans paquet
       (ou indiquez une solution).


    I then try to run "apt --fix-broken install" as suggested :


    I accept, and run into the following errors :




    I've been searching the web and trying stuff for 3 hours now but i am unable to make any progress, as everything lead me to the same exact error I have when I try to run apt-get upgrade. I can no longer remove any plugin from OMV web interface as well, it seems everything related to installing/updating/removing packages is stuck.


    Is there something I missed when searching for a solution ?

  • Updating python to the Debian's testing branch seems to resolve the issue:


    Add 'testing' to sources.list:


    # sudo nano /etc/apt/sources.list
    deb http://ftp.de.debian.org/debian testing main



    Make the 'stable' repository default on your server:





    Code
    # echo 'APT::Default-Release "stable";' | sudo tee -a /etc/apt/apt.conf.d/00local
    
    
    # sudo nano /etc/apt/preferences
    Package: *
    Pin: release a=stable
    Pin-Priority: 900
    Package: *
    Pin: release o=Debian
    Pin-Priority: -10



    Install updated python3 (this updated me to Python3.7.2+)
    # sudo apt-get update
    # sudo apt-get -t testing install python3


    Based on: https://www.rosehosting.com/bl…python-3-6-4-on-debian-9/ and https://unix.stackexchange.com…to-set-default-apt-source

    Edited 3 times, last by fergbrain: Formatting, adding additional information about /etc/apt/preferences ().

Participate now!

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