Upgrade from OMV6 to OMV7 keeps failing and breaking my system.

1st Official Post

    I can't seem to upgrade from OMV6 to 7, I have tried on three occasions (one via Wetty that seemed to become unresponsive and twice via terminal/ssh) and it seems to fail everytime. After my failed second attempt, I thought it was because I forgot to disable backports before upgrading but I checked the output (via terminal) of my backports after upgrading and it stated backports were disabled. Thinking the issue was fixed, I stupdly ran omv-release upgrade again and this seems to have borked the sysem even more. Last time I recovered with apt --fix broken install but this is no longer working.


    Here is the log (shortened due to character limit) of my last most recent attempt at upgrading that seems to have made things even worse as I can no longer recover via apt --fix-broken install or omv-firstaid.


    At this point, I couldn't log into my cli (though my docker containers were all running well). I tried fixing things by running

    apt --fix-broken install at which point I got this output:



    I tried running omv-firstaid but get a command not found error.


    Quote

    root@xxxomv:~# omv-firstaid

    -bash: omv-firstaid: command not found


    I am not sure what happened here as I was careful not to modify core files outside the OMV gui, I think I ran sudo apt update once or twice via the terminal and played around with a config file (can't recall the file anymore) regarding time syncing as OMV kept resetting it's time and I could not log in. This was before I realised it was an issue in my BIOS that I fixed.


    Can anyone help me get my system back up and running and upgraded to OMV7? When I try to access my gui/dashboard I get error 403.

  • chente

    Approved the thread.

  • crashtest

    Approved the thread.
    • Official Post

    I'm going to assume that you have a healthy OMV6 installation to start from that has been upgraded and updated. I've used the following proceedure successfully with a couple of SBC's (one was an R-PI4) and two AMD64 platforms.

    ____________________________________________________________________________________


    Starting with a working, fully updated and upgraded, OMV6 install:


    1. Remove all plugins that do not have an exact counterpart in the new version. If you're not using a plugin, it would be a good idea to remove it.


    2. Run: omv-salt stage run deploy

    **In the case of the Odriod, the above command failed. It simply didn't complete and the system actually stopped responding to the network. (This issue was repeatable.) I proceeded with the upgrade anyway. Curiously, it worked and the upgrade actually corrected the SALT problem in the new install.**


    3. Get the current install up to date: omv-upgrade

    If you see "dpkg interrupted", run the recommended command, then run #3 again.


    4. Do the release upgrade by running: omv-release-upgrade

    If you see an error message from patches which says "a patch has already been applied", ignore it. (this is the only error to be ignored) if there's a grub-pc error continue.


    5. Shutdown after the script finishes.


    6. Unplug all data drives.

    This is recommended, but not absolutely necessary. What is necessary is to *know* which drive is your boot drive. ((This shouldn't be a problem in your case. It's easy to identify a 16 or 32GB USB boot drive.)) If the boot drive is unknown, and you run the command in 7 below, and the grub "select boot drive" prompt comes up, take no action. Shutdown and confirm the boot drive OR unplug all data drives .


    7. Run the following:

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

    - If this line is interrupted, follow the prompt for the command dpkg --configure -a

    Select correct boot drive for grub, if prompted.

    When the script completes, Shutdown again.

    8. Boot up and run the same line again.

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

    (nothing about grub should come up the second time around.)


    9. Run the following:

    wget -O - https://raw.githubusercontent.com/OpenMediaVault-Plugin-Developers/installScript/master/fix6to7upgrade | bash


    After the script completes, reboot


    10. If there no access to the GUI (using IP address), run the following again

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

    Otherwise, if the GUI comes up...


    11. When the GUI login screen comes up, hit Cntrl+Shift+r


    12. Check to see if there are any updates pending.


    13. Do updates under System, Update Management (or) run

    omv-upgrade from the CLI.


    Login and check if all services and docker containers are running as you would expect.

    If you see Linux image Updates you can not install, in the UI, go to the CLI and run omv-upgrade once more.

    Thank you for the reply, that is a helpful guide. Unfortunately when attempting to follow those steps with my current state of install, I get this output at step 2: :

    Quote

    root@xxxomv:~# omv-salt stage run deploy

    -bash: omv-salt: command not found

    I am using SSH from my Terminal in Fedora Workstation via ssh root@xxxx. I access this system via tailscale even locally and ran the above commands over a tailscale ip (100.xxx.xxx.xx) rather than the machines local ip. (192.xxx.xxx.xx).

    • Official Post

    The SALT stack is part of the basic OMV install. If you're getting "command not found" with omv-salt stage run deploy SALT may not be installed.

    You could try skipping over omv-salt stage run deploy (I had to in one instance, for another reason) and go to omv-upgrade and see what happens from there.
    _____________________________________________________________

    Before rebuilding from scratch, you might try apt-get install openmediavault That might fix the SALT stack.

    Otherwise, if I were you (with SALT missing), I'd consider building OMV7 from scratch. The reason being; a "release upgrade" assumes that basic packages are installed and intact. A release upgrade may, or may not, install missing packages.

    I tried the steps you suggested and this is my output:



    So it looks like I might need to rebuild from scratch. I do have a backup of the system that I can try recovering from but am not keen to go through that process of restoring the backup only to ran into the same issues sometime down the road. All my data and docker content was stored on separate drives but was hoping to avoid going through this as I am not sure I wont loose somethings,. such as in the case of container config files that are stored locally..

    • Official Post

    -> OMV-regen is an option. OMV-regen would recreate your OMV6 install, transferring your existing OMV config to a new OMV6 build, but it would not restore Dockers and you'd still have to upgrade to OMV7.
    _________________________________________________________________________________________

    There was something going on with your install. Dependency issues, packages not installed, the SALT-minion needing to be reinstalled (which meant that it was removed at some point), etc. There's no knowing what happened, or when, but something removed some of OMV's core packages. If it was my install, without doubt, I'd rebuild.

    Be careful with "direct installs", that run alongside of OMV. Direct installed server add-on's can create package conflicts that result in removal of OMV's core packages. In some cases, OMV itself can be fully removed. (The latter is why Desktop environments are NOT recommended.) If there's a server add-on that you want to try or just can't live without, Dockers or Kubernetes is the way to go. Since they're self contained and near instantly removable, in this respect, there's no downside to Dockers or Kubernetes.

    If you need to "direct install" an add-on, backup the boot drive first. Even with backup, realize that changes may be made that are not readily apparent.

    • New

    Thank you for all of your responses on this, in the end I managed to get my server up and running again with my ddfull backup as a temporary band aid solution. It is odd as I run all my services in Docker/Podman but when I first set OMV, being unfamiliar with Docker, I did install a few services via apt, I think Cockpit, Nextcloud and even some dependencies for Immich at one point. As I became familiar with Docker, I transitioned all my services to it and removed those old services. Perhaps when I removed those services, they removed some dependency for OMV.


    Regardless, I decided to use this situation to build a more robust backup system and have spent the week migrating to Proxmox with OMV7 running inside a VM. I used my backup to grab the Docker compose files and pointed them at my existing volumes and everything seems to have gone well. I passed through my data drives and am running SnapRAID on my data drives while the VM itself is being backed up to Proxmox Backup Server. My next step is to obtain some additional spinning drives to allow me to backup my OMV data drives to my PBS in a ZFS array. Hopefully if the system breaks during an update in the future, I can quickly restore from a snapshot without significant downtime as on this occasion.


    I will still try to update my OMV6 bare metal install to further investigate the cause of the issue but that will have to wait until I have confirmed all of my containers have properly transferred over.

Participate now!

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

Register Yourself Login