RPI dependency issues with latest php7.0 7.0.30-0+deb9u1 (and their dependent packages)

  • Hi,


    This issue is already resolved permanently with the rollout of latest version of the openmediavault-omvextrasorg package, which will be pulled automatically during an OMV update. Following issues should be neither present, nor the workarounds should be relevant anymore.


    as there are new info, I quickly want to summarize the latest status of the issue, so users with this issue do not need to scroll through the whole thread. Hope this helps to quickly solve the issue:


    What is the issue

    • issue is related to updating latest PHP packages (PHP7.0-common 7.0.30-0+deb9u1 should be available, but only can get 7.0.27-0+deb9u1)
    • leads to several other issues dependent on PHP like nextcloud via nginx, docker, Sonarr? and probably others


    Who is affected

    • basically looks like all Raspberry Pis + OMV4 (reported also by cskrat, rdowns, probably also luizbacci: Link to Post, also another thread: Link to Post)
    • other armhf devices seem not to be affected (tkaiser was not able to reproduce on a NanoPi NEO)


    What was tried so far/what we know

    • it is not an OMV4 issue itself (but combined with RPI)
    • OMV3 seems not to be affected
    • upstream of Debian seems to be the root cause, which somehow does not allow RPI devices to update properly: most likely it has to do with pin priority of archive.raspberrypi.org
    • trying a forced PHP7.0-common update to latest 7.0.30-0+deb9u1 would result in removal of many critical other packages, but can also force-re-install them (however is case by case which packages are affected)
    • disabling backport repos does not lead to a solution of a proper update
    • there are workarounds, one is case-by-case package install... the other one ignoring archive.raspberrypi.org, which will lead to a lot of package updates.


    Possible workaround

    • cskrat posted a current workaround, which force installs the latest PHP 7.0.30-0 packages + force "reinstalls" the packages, which would have been removed, careful, as other packages might have a need to be added. Looks like it depends on case by case: Link to Post
    • ryecoaaron found an alternate approach to comment out pin priority for archive.raspberrypi.org. Seems to fit for all cases, however installs a lot of packages. Not sure if this has some side-effects: Link to Post
    • other alternative by ryecoaaron: apt-get update and then apt-get install openmediavault-omvextrasorg=4.1.9
    • other alternative by ryecoaaron: wget -O - http://omv-extras.org/install | bash



    Conclusion/summary

    • So far got workarounds, which seem to do the trick. Especially the last approaches I would consider for now as "final workaround" and would therefore treat this issue as solved via workarounds, until it is permanently implemented


    ---


    ORIGINAL POST:


    hope this forum is correct one and maybe somebody had that issue too (and resolved it).


    Problem is:
    - I'm using Nginx (as a plugin) on OMV4.1.8.2-1 and a RPI3B+, no updates available
    - (On top it I got a Nextcloud version)
    - (It screams that it needs some plugins like e.g. PHP module zip)
    - When trying to install latest PHP module zip, it needs a newer version of PHP-Common
    - And there is the fun: Normal apt-get update does not help. When trying to update the PHP-Common manually, it would like to kick instead many of my OMV packages. Looks like a weird compatibility issue. :S


    It feels like my server says: "You want to have Nextcloud with OMV+Nginx? Sure, press 'y' to confirm, that in return I can kick you in your nuts! Or go back to OMV3, where it just worked."
    I feel it is strange, that updating a package (which obviously exists in a newer version), would kill instead the whole OMV installation.
    Now I'm not sure, if my fresh OMV4.0 installation is already broken and would need to start over, or whether issue is somewhere else.


    Was thinking to run it in a Docker instead, but Nextcloud itself seem to be not working there as expected. Also linking my Lets-encrypt SSL from OMV would be an additional challenge.

  • I'm having a similar/same issue installing docker on a RPi 3B.


    php7.0-common (7.0.30) is required by php7.0-curl but php7.0-common (7.0.27) is installed.


    Removing and reinstalling php7.0-common seems to break everything so I'm going back to etcher to reburn the image and start over.

  • Forgot yesterday to add some information, which may explain the issue:


    According to https://tracker.debian.org/pkg/php7.0https://tracker.debian.org/pkg/php7.0 our issue might be related to the latest update for PHP7.0, which was released few days ago "[2018-07-05] Accepted php7.0 7.0.30-0+deb9u1". Yet, hard to imagine, that after ten days it did not cause more issues for OMV users.


    However it looks like it is not available (yet) for us. Probably it needs some kind of full integration for OMV itself? Or Raspberry-related, as we both have it. But that would be weird, as I think it should affect also other platforms. Probably all our OMV packages are not compatible with php7.0 7.0.30-0+deb9u1. So I change the thread title to this.


    Just tried to update again (with hope, that the update would be magically available), no success.

  • dpkg.log:
    https://pastebin.com/v2n9BFYT


    dpkg output:
    https://pastebin.com/8MLFGjMu


    install attempt for php-curl and php7.0-curl:
    https://pastebin.com/mz6XE8Nq


    apt show for php7.0-common and php7.0-curl:
    https://pastebin.com/RDJTwCnT


    This is a fresh install from the image file obtained Sat. Jul 14, 2018. The only actions I've performed in the web gui at this point on this install is to enable root SSH login; no plugins, extras or even shares touched.


    Thank you for taking the time to look at this.

  • This is a fresh install from the image file obtained Sat. Jul 14, 2018. The only actions I've performed in the web gui at this point on this install is to enable root SSH login; no plugins, extras or even shares touched

    Thank you. I only had a look whether this could be the result of a mixture of Raspbian and Debian packages. The RPi image is using upstream Debian 9 (armhf) but we need to pull in some packages from archive.raspberrypi.org and without some ugly apt-pinning this could easily result in a broken package mixture. See Call for testers: OMV4 for ARM boards


    But the output looks fine, only upstream Debian involved so at least nothing we (OMV) could further look into or fix.


  • But the output looks fine, only upstream Debian involved so at least nothing we (OMV) could further look into or fix.


    On the other side i see it positively and it sounds like: they (from archive.raspberrypi.org) can fix it, right? As they update their parts regularly, it's just a matter of time... at least that's, what I hope now.

  • they (from archive.raspberrypi.org) can fix it, right?

    No. We use upstream Debian 9 armhf packages as already explained and there are only 5 packages that are pulled in from Raspberry Pi repos: https://github.com/ThomasKaise…/overlay/99raspberrypiorg


    I was only concerned that more packages are pulled in since such a mixture is a recipe for failure. But package installation seems not to be affected by such a mix and this is all upstream Debian stuff.

  • Hello tkaiser and thank you for looking into this!


    Can you please confirm that since this is neither an OMV or RPi issue that we need to engage the Debian team by creating a bug report?


    If this is incorrect, what would be our (people affected by this issue) next step in getting this issue resolved? So far, I have not found that this issue has been reported to Debian.



    Thanks!

  • Can you please confirm that since this is neither an OMV or RPi issue that we need to engage the Debian team by creating a bug report?

    Not entirely sure. Just tried my luck on a good SBC (I don't have any RPi around any more, too annoying)



    So can't reproduce but this is arm64 and not armhf architecture. Would be worth a try to check this on another armhf OMV4 image than RPi but I don't have 32-bit SBC any more to test with.

  • Would be worth a try to check this on another armhf OMV4 image than RPi but I don't have 32-bit SBC any more to test with.

    Silly me forgot my cute NanoPi NEO. Just tested:

  • On the NanoPi NEO I purged the php-curl package, activated Docker CE repo and it still works:


    Maybe important: I've the backports repo disabled:


  • Here looks like this:


  • commenting out the backports did not help, still get:

    • Offizieller Beitrag

    I don't have an RPi running but what is the output of: apt-cache policy php7.0-common php7.0-curl with and without backports enabled? I have a feeling adding -t stretch-backports to the apt-get install with backports enabled might fix it.

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

    Einmal editiert, zuletzt von ryecoaaron ()

  • Backports Enabled:


    Backports Disabled:

  • And, jumping the gun a bit:

    • Offizieller Beitrag

    The package isn't in backports but 7.0.30 is a candidate on your system. Try:


    apt-get upgrade


    If that still doesn't work:
    apt-get install php7.0-common=7.0.30-0+deb9u1

    omv 7.0-32 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.9 | compose 7.0.9 | cputemp 7.0 | mergerfs 7.0.3


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


    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!

  • as there are several longer posts with code, logs, ..., I updated the title and the first entry to reflect the latest status as good as possible. Should help to keep the key info at one place and if there is new progress, will update it accordingly. Increases also the chances, that somebody new to that topic might help directly without reading through the details. :)

  • The package isn't in backports but 7.0.30 is a candidate on your system. Try:


    apt-get upgrade


    If that still doesn't work:
    apt-get install php7.0-common=7.0.30-0+deb9u1


    I remember I tried "apt-get upgrade", unfortunately did not help.


    When trying to directly install the latest PHP7.0-common, it would break other stuff, see here: RPI dependency issues with latest php7.0 7.0.30-0+deb9u1 (and their dependent packages)

Jetzt mitmachen!

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