Posts by MrTestOne

    Thanks for the tips, just checked them out.


    https://www.indiegogo.com/proj…i-computer-computers-pc#/ looks definitely interesting, but looks like it is still not fully available yet, according to the campaign still may take for production. "manufacturing to be completed and fulfilled by late August"... so from my experience this adds:
    - 1w. for QA,
    - 6w. shipping, probably will go first to the major markets EU and US (so for me in SE Asia will still take more time :( )
    - 2w. channel distribution
    - so around end of Oct. available - unless their industry has some magic processes or they will use air freight (doubt that)



    https://www.udoo.org/udoo-x86/, let me explain my experience:
    - I see buy
    - I click buy
    - I see USD 174
    - It hurts my heart (and my pocket) :) - but you've warned me about the price


    ODROID-XU4
    - Internal USB hub? - uhhh ... looks like I missed that (already checked your topics about HUBs, so I fully agree: don't mix HUBs and data...)
    - https://www.hardkernel.com/mai…e=G143452239825&tab_idx=2 USB HUB was hidden in the small "details" ;)



    Leaves almost only one choice, a RK3399:
    - RockPro64
    - available on market
    - 2x USB 3.0 (1xType A, 1xType C)
    - GbE
    - below $100
    - got an OMV image... the one linked in the other thread: https://github.com/ayufan-rock64/linux-build/releases
    - Only criticism (on the picky side): so much unneeded stuff like camera ports, audio jacks, ... :S
    - Hope I did not miss anything... But I assume, this you can only find out once you order it and then start to work on it. Then the moment comes like "f*** I forgot xyz" :D


    But honestly if it's more than just one or two 3.5" disks I would always also check how much in your area the costs of a HP Microserver are.


    I was actually thinking of getting a single board PC for 2x HDDs, like an ODROID-XU4, but then I saw this: No support for ODROID-XU4 especially in combination with Cloudshells any more! (Or is it just related to the +Cloudshells - and without them the board is fine?)


    Was a sad moment, because it seems like the ODROID-XU4 seems to be the only solid single board PC with 2x USB 3.0 and GbE, according to this Wiki list. Proposed alternative from tkasier is a HP Microserver, but that seems to be a bit too much (cost and performance wise, when looking for a decent 2 bay home NAS).


    Yet: Is there really no other choice for mini PCs and 2x USB 3.0 for 2x external HDDs? Hard to imagine, that there is no mini PC that can handle 2x HDDs at solid speeds... Any ideas here?

    luckily i still have the log. Looks a bit more than just PHP:

    Just found out, that there is a thread, similar to this here with more people having trouble and another approach: Link to Post


    The following lines are causing the php packages to pinned at 10 in /etc/apt/preferences.d/99raspberrypiorg which won't let them be upgraded.
    Package: *
    Pin: release n=stretch, origin archive.raspberrypi.org
    Pin-Priority: 10
    Not sure why. I commented them out and everything upgrades fine but you risk installing packages from the raspberry pi repo (raspbian). Those lines look fine to me but the origin is being ignored. I will have to figure out why.

    commenting out the lines and using an apt-get upgrade seems to do the job. However lot of packages are updated, makes me feel a bit worried, that it might be "too much".

    Had to add from your list some packages like "openmediavault-docker-gui" or "php-curl", as they were on the "will be removed"-list. So looks like it is always a bit different for each installation:


    Code
    apt-get install php7.0-common=7.0.30-0+deb9u1 openmediavault openmediavault-flashmemory openmediavault-netatalk openmediavault-omvextrasorg php-bcmath php-cgi php-fpm php-mbstring php-pam php-xml php7.0-bcmath=7.0.30-0+deb9u1 php7.0-cgi=7.0.30-0+deb9u1 php7.0-cli=7.0.30-0+deb9u1 php7.0-fpm=7.0.30-0+deb9u1 php7.0-json=7.0.30-0+deb9u1 php7.0-mbstring=7.0.30-0+deb9u1 php7.0-opcache=7.0.30-0+deb9u1 php7.0-readline=7.0.30-0+deb9u1 php7.0-xml=7.0.30-0+deb9u1 openmediavault-docker-gui php-curl php7.0-curl=7.0.30-0+deb9u1

    This is... ugly but seems to have worked.


    apt-get install php7.0-common=7.0.30-0+deb9u1 openmediavault openmediavault-flashmemory openmediavault-netatalk openmediavault-omvextrasorg php-bcmath php-cgi php-fpm php-mbstring php-pam php-xml php7.0-bcmath=7.0.30-0+deb9u1 php7.0-cgi=7.0.30-0+deb9u1 php7.0-cli=7.0.30-0+deb9u1 php7.0-fpm=7.0.30-0+deb9u1 php7.0-json=7.0.30-0+deb9u1 php7.0-mbstring=7.0.30-0+deb9u1 php7.0-opcache=7.0.30-0+deb9u1 php7.0-readline=7.0.30-0+deb9u1 php7.0-xml=7.0.30-0+deb9u1


    Basically, I started with a forced version of php7.0-common, said 'no', got the list of packages that would have been removed and tossed them in with forced version on all the php7.0-* packages. This could probably be pared down to just the php7.0 packages.


    Sounds like a plan.


    There is one question remaining: After this forced installation of the packages, are many others like Python, libraries, ... marked for "auto-removal" at next "apt autoremove"? That was reported on my system: Link to Post


    So with next "apt autoremove" after this workaround, there would be a big hole in the system? ;(

    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)

    commenting out the backports did not help, still get:

    Here looks like this:


    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.

    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.

    Yepp, can confirm this under OMV 3.x. However, for some reason it looks like part of suisujin's solution worked for me to revive the webgui of OMV (probably, because i use LetsEncrypt SSL for a separate nginx server, not for OMV itself):


    - Take latest private key (copy content) from /etc/letsencrypt/keys/000x_key-certbot.pem
    - Paste (and overwrite) content in /etc/ssl/private/openmediavault-KEYIDHERE.key
    - use omv-firstaid to configure webgui port, afterwards webgui restarts (no need to reboot)