Upgrade Scripts for non-interactive major release upgrades (2->3, 3->4, 4->5)

    Quote from dleidert

    JFTR. I'm currently working on improving the scripts so if one fails the user can fix an occurring issue and then continue at the point the script left.

    Would be nice indeed...
    In my case, I took esxi snapshots before each upgrade trial. If it failed, I reverted and tried again after some cleanup but I had to redo evrything.

    I ran upgrade script on my RPI4 OMV 4 install to upgrade it to 5 and had the following problem show up:


    The following NEW packages will be installed:

    apt-show-versions

    0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

    Need to get 32.6 kB of archives.

    After this operation, 93.2 kB of additional disk space will be used.

    Get:1 https://deb.debian.org/debian buster/main armhf apt-show-versions all 0.22.11 [32.6 kB]

    Fetched 32.6 kB in 0s (150 kB/s)

    Selecting previously unselected package apt-show-versions.

    (Reading database ...

    Preparing to unpack .../apt-show-versions_0.22.11_all.deb ...

    Unpacking apt-show-versions (0.22.11) ...

    Setting up apt-show-versions (0.22.11) ...

    ** initializing cache. This may take a while **

    Error: No information about packages! (Maybe no deb entries?)

    dpkg: error processing package apt-show-versions (--configure):

    installed apt-show-versions package post-installation script subprocess returned error exit status 255

    Processing triggers for man-db (2.8.5-2) ...

    Errors were encountered while processing:

    apt-show-versions

    E: Sub-process /usr/bin/dpkg returned an error code (1)

    run-parts: /root/openmediavault-upgrade-4.7/post.d/50-apt-install exited with return code 100

    root@RPINAS2:~/openmediavault-upgrade-4.7# sudo apt-show-versions

    Error: No information about packages! (Maybe no deb entries?)


    I then checked how far the upgrade had proceeded and it appears to have not upgraded any parts of OMV


    root@RPINAS2:~/openmediavault-upgrade-4.7# dpkg -l | grep openm

    rc openmediavault 4.1.36-1 all openmediavault - The open network attached storage solution

    rc openmediavault-flashmemory 4.2.2 all folder2ram plugin for OpenMediaVault

    ii openmediavault-keyring 1.0 all GnuPG archive keys of the OpenMediaVault archive

    rc openmediavault-omvextrasorg 4.1.16 all OMV-Extras.org Package Repositories for OpenMediaVault


    I'm not sure if this is salvageable. Any suggestions?

    Quote from dci2u

    I ran upgrade script on my RPI4 OMV 4 install to upgrade it to 5 and had the following problem show up:

    Please provide the full log!


    You hit the same bug of apt-show-versions as described here.

    Actually the rc-state means that the package has been removed except for its configuration files. These packages should already been as version 5 here. But again I need the full log to understand what happened.

    You have a pinning for stretch in /etc/apt/preferences or /etc/apt/preferences.d/*. This leads to packages from stretch having a pin-priority of 900. Unfortunately when openmediavault is to be upgraded by the scripts this pinning leads to packages not being pulled from buster repositories but from stretch thus getting openmediavault removed from your system because of unsatisfiable dependencies:



    Please remove the pinning for stretch (and please send me the pinning entry, so I can find a way to overwrite this in future situations). Then finish the broken installation of apt-show-versions using:


    sudo apt-get -o Acquire::GzipIndexes=false update && sudo apt-get install -f


    If that worked try to install openmediavault:


    sudo apt-get install -t usul openmediavault


    This should pull in OMV5. If it works reinstall omv-extras:


    wget -qO- https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | sudo bash


    Then run the remaining upgrade scripts:


    . inc/envvars

    sudo run-parts -v --exit-on-error post.d


    which hopefully succeed without any further error. Now you have to install openmediavault-flashmemory.

    I'm sorry, I'm not sure what change I need to make in the preferences.d directory (there was no preferences directory) to remove the offending pinning entry. I've attached the files from that folder for your reference. The only file I noticed with a 900 priority was the 99raspberrypiorg. pref_files.zippref_files.zip

    Comment out (means: prefix each of the following lines with a #) in 99raspberrypiorg so it looks like this:

    Code
    #Package: *

    #Pin: release n=stretch, origin httpredir.debian.org

    #Pin-Priority: 900

    This will remove the pin priority for stretch. Then proceed as suggested above.

    I continued to get installation errors after commenting out the lines in 99raspberrypiorg file. However, the messages led me to believe these were not fatal faults. I then tried to install omv5 but it also faulted out. I ended up installing a new copy of omv5 from scratch and it's back in service.

    I also had / have problems when trying to upgrade from OMV 3 -> OMV4 -> OMV5
    Upgrade from 3 to 4 works without problems, but after that I tried to do an upgrade from 4 to 5 with "openmediavault-upgrade-4.7"-script and that failed and left back an unusable system.


    The original problem was that I imported a SSL certificate in OMV made by my own CA which seems to be too weak now:

    Code
    nginx: [emerg] SSL_CTX_use_certificate("/etc/ssl/certs/openmediavault-a39391e1-ca69-452a-b0b1-e31adeb24be4.crt") failed (SSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak)

    After that I had a Debian buster system but still old OMV parts?!
    I tried to solve it by changing nginx configuration, removing / purging / reinstalling packages, ... and a lot more.
    My final situation is now, that "apt-get update; apt-get dist-upgrade" doesn't show any error anymore but the OMV part is not installed and I'm unable to install it because it complains about some "salt-minion" dependencies which it cannot solve:


    Does anybody have any idea how to solve it?
    What information / files from my system is/are needed to help me?


    [EDIT]

    I now did the following:
    apt-get install -u -d -o Debug::pkgProblemResolver=true salt-minion=3002.2+ds-1 salt-common=3002.2+ds-1

    and then

    apt-get install -y --no-install-recommends --no-install-suggests -u -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" openmediavault


    that seems to do the job - at least it installs something ;-) (I'll see if it completes it successfully later).


    BTW (a bit OT): back to my original problem, that my CA's certificate is too weak - is it possible to change that without to regenerate all my existing certificates which are signed by this CA?


    [EDIT2]

    it still has configure problems (now with lvm2):

    Quote from Bodenseematze

    After that I had a Debian buster system but still old OMV parts?!

    I tried to solve it by changing nginx configuration, removing / purging / reinstalling packages, ... and a lot more.
    My final situation is now, that "apt-get update; apt-get dist-upgrade" doesn't show any error anymore but the OMV part is not installed and I'm unable to install it because it complains about some "salt-minion" dependencies which it cannot solve:


    Does anybody have any idea how to solve it?
    What information / files from my system is/are needed to help me?

    That's caused by temporarily setting APT::Default-Release. Because OMV provides its own release names it is not pinned by APT::Default-Release as well. So the scripts install OMV by explicitely using -t usul:


    sudo apt-get install -t usul openmediavault


    I'm working on an improvement which will use pinning instead.


    Quote from Bodenseematze

    The original problem was that I imported a SSL certificate in OMV made by my own CA which seems to be too weak now:

    Code
    nginx: [emerg] SSL_CTX_use_certificate("/etc/ssl/certs/openmediavault-a39391e1-ca69-452a-b0b1-e31adeb24be4.crt") failed (SSL: error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak)

    BTW (a bit OT): back to my original problem, that my CA's certificate is too weak - is it possible to change that without to regenerate all my existing certificates which are signed by this CA?

    https://www.debian.org/release….en.html#openssl-defaults maybe?


    Although I would recommend to harden your certificate.


    Quote from Bodenseematze

    [EDIT2]

    it still has configure problems (now with lvm2):

    You should find out what the problem is: sudo systemctl status lvm2, sudo journalctl -xe. Also the log files may contain useful information.

    ySorry to be such late with my reaction - I had no time for the OMV server lately :rolleyes:

    Here are the outputs / logs - there are still a lot failures, but they don't seem to be related with lvm?!


    # systemctl status lvm2

    ● lvm2.service

    Loaded: masked (Reason: Unit lvm2.service is masked.)

    Active: inactive (dead)


    Logfile of journalctl -xe is attached, relevant entries from syslog also...




    Quote from dleidert

    https://www.debian.org/release….en.html#openssl-defaults maybe?


    Although I would recommend to harden your certificate.

    Yes, I also would like to do that - harden the certificate of my internal CA - but how do I do this without the need to regenerate all my certificates which all have already be signed by that CA?

    Quote from Bodenseematze

    Here are the outputs / logs - there are still a lot failures, but they don't seem to be related with lvm?!

    [..]

    Logfile of journalctl -xe is attached, relevant entries from syslog also...

    I find it quite hard to help you. The upgrade scripts bailed out very early in the minimal upgrade scripts. Then instead of setting the openssl defaults back or asking how to deal with the situation you tried to solve the certificate issue by pondering around with package removals and (re)installations?! I have no idea in which state the system is, or if any of the scripts run after run.d/50-apt-upgrade have been run at all. I think it is salvageable. I'll send you a DM later.


    Quote from Bodenseematze

    Yes, I also would like to do that - harden the certificate of my internal CA - but how do I do this without the need to regenerate all my certificates which all have already be signed by that CA?

    Well, the truth probably is: you can't. If the certificates use algorithms, ciphers, or key lengths considered too weak they have to be regenerated.

  • Post by kkottikas ().

    This post was deleted by the author themselves: problem was related to networking issues ().

Participate now!

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

Register Yourself Login