dleidert / openmediavault-upgrade

Script to upgrade openmediavault from one major release into the next
GNU General Public License v3.0
48 stars 1 forks source link

Upgrade failed - any easy way to tell how far it progressed? #35

Closed admusin closed 3 years ago

admusin commented 3 years ago

Hello dleidert,

I went this evening through an upgrade attempt from 4.x to 5.x using the upgrade script from: https://github.com/dleidert/openmediavault-upgrade/tree/4.

It went quite well for a while but I got an error in the end:

run-parts: executing /root/upgrade-script/openmediavault-upgrade-4.7/post.d/71-restart-services
Failed to enable unit: Unit file docker.service does not exist.
run-parts: /root/upgrade-script/openmediavault-upgrade-4.7/post.d/71-restart-services exited with return code 1

I'm not sure why it's trying to manipulate a Docker service file; Docker has been uninstalled from the system (via the WebUI) prior to the upgrade attempt.

I have a feeling that the upgrade went quite close to its finish line, because I can log in the WebUI and it shows me that it's running version v5.6.3-1 (Usul).

However, I'm trying to figure out if there's some essential part of the upgrade process that was not done yet, or it just stumbled before the final reboot prompt.

Is there any easy way for me to see what was left to be done (short of parsing and trying to reverse-engineer the whole upgrade script)? Thank you in advance.

omv_release_upgrade_to_buster.2021-04-07-001607.log

dleidert commented 3 years ago

It went quite well for a while but I got an error in the end:

run-parts: executing /root/upgrade-script/openmediavault-upgrade-4.7/post.d/71-restart-services
Failed to enable unit: Unit file docker.service does not exist.
run-parts: /root/upgrade-script/openmediavault-upgrade-4.7/post.d/71-restart-services exited with return code 1

Ok. So it stopped at the post.d/71-restart-services script.

I'm not sure why it's trying to manipulate a Docker service file; Docker has been uninstalled from the system (via the WebUI) prior to the upgrade attempt.

It is not trying to manipulate anything. It is trying to re-enable the docker service. This service is disabled during the upgrade due to #18. These scripts are for everybody, also those using docker. But it should only re-enable the service if it is installed. So the question is, why it tries to do so. Can you post the output of:

systemctl list-units --all | grep docker

please?

I have a feeling that the upgrade went quite close to its finish line, because I can log in the WebUI and it shows me that it's running version v5.6.3-1 (Usul).

However, I'm trying to figure out if there's some essential part of the upgrade process that was not done yet, or it just stumbled before the final reboot prompt.

It is missing all the cleanup that follows this script. See https://github.com/dleidert/openmediavault-upgrade/tree/4/post.d. You can remove all scripts in post.d before 71-restart-services (they are executed in numbered order). In post.d/71-restart-services remove the line reading docker from the SERVICES_ENABLE variable and then run the following commands from within the upgrade scripts directory:

. inc/envvars
sudo run-parts -v --exit-on-error post.d/

If you have removed all the scripts before 71-restart-services it should now run 71-restart-services and all the scripts which follow.

admusin commented 3 years ago

Thanks for the quick answer.

What I meant by "manipulate" was: "it tries to do something with". I was by no means suggesting any fishy behavior. :)

There seem to be some docker unit files left lying around somewhere; either the Docker removal via GUI didn't clean up properly, or something else happened:

# systemctl list-units --all | grep docker
  sys-devices-virtual-net-docker0.device                     loaded    active   plugged   /sys/devices/virtual/net/docker0          
  sys-subsystem-net-devices-docker0.device                   loaded    active   plugged   /sys/subsystem/net/devices/docker0   

Presumably, those two tricked the script into believing Docker was still installed?

Indeed, after following your instructions above, I believe the upgrade finalized successfully:

run-parts: executing post.d//98-end
******************************************************************************
Successfully upgraded to 5.0 (Usul) ..."

The following packages don't appear in any of the available repositories
anymore:

        linux-headers-4.19.0-0.bpo.5-amd64:amd64 4.19.37-5+deb10u2~bpo9+1
        linux-headers-4.19.0-0.bpo.5-common:all 4.19.37-5+deb10u2~bpo9+1
        linux-headers-4.19.0-0.bpo.6-amd64:amd64 4.19.67-2+deb10u2~bpo9+1
        linux-headers-4.19.0-0.bpo.6-common:all 4.19.67-2+deb10u2~bpo9+1
        linux-image-4.19.0-0.bpo.6-amd64:amd64 4.19.67-2+deb10u2~bpo9+1
        linux-image-4.19.0-0.bpo.8-amd64:amd64 4.19.98-1~bpo9+1
        linux-image-4.19.0-0.bpo.9-amd64:amd64 4.19.118-2+deb10u1~bpo9+1

Check carefully if you need them. Otherwise they can be removed.

Make sure to clear your browser cache before reloading the web GUI!! Otherwise
you might see this error:

        missing 'required' attribute 'enabled'

You might also be presented a request to apply the changes to OMV. Just hit
the <Apply> button

Some services might need a restart. Please restart your system now. Please
check the system state afterwards. E.g. check for failed units/services:

        sudo systemctl list-units --failed

******************************************************************************

After reboot everything works fine. I just had to fix systemd-modules-load failure to start due to an obsolete line in /etc/modules-load.d/modules.conf but that had nothing to do with the upgrade itself, rather with some old config of an USB WiFi driver still lingering around.

Thanks for the help and the huge amount of work you put into this script suite! I'll definitely use it to try and upgrade my second NAS.

mi-hol commented 3 years ago

please close this issue as it is resolved