Fixed Upgrade Woes: Updates between multiple major versions ... unsupported

ℹ️ Support
1

Posting this for others that may have had a similar issue with trying to upgrade Nextcloud.

After a few years of upgrading a Nextcloud instance, it final got stuck on v25.0.2.3, and every time I went through the upgrade process to the next v25.0.x, it kept coming up with the exception:

"Updates between multiple major versions and downgrades are unsupported".

So having to revert back. So finally, after a good while, finally getting the time, dug into the code to see what was triggering this exception ( and maybe if I code manually hard code a bypass).

I ended up in the source file: “[nextcloud]/lib/private/Updater.php”
and the functions doUpgrade and isUpgradePossible, where I found (grep’ing) the exception string.

doUpgrade calls isUpgradePossible, and this pulls a config value with config->getAppValue('core', 'vendor', ''). I thought initially this was in the admin config file: “[nextcloud]/config/config.php”, and was some how missing (by a bad edit on my part :).

I thought this ‘vendor’ value may be the issue, since the next few code lines checks for which vendor it found, and if empty, defaults to “owncloud”, which then compares the versions allowed, pulled from the file: “[nextcloud]/versions.php”

However looking deeper into this getAppValue function, from the lib “IConfig.php”, it pulls its value from the db, and the “oc_appconfig” table, ahah!

Checking this db table, and no (‘core’,‘vendor’,‘nextcloud’) record, and so added it… Then gave another kick at the upgrade to v25.0.13, and shebang, it worked.

I thought I would share this, if any of you may run into a similar issue, where you are trying to upgrade within the same major version, and as I was, keeping getting stumped with this unsupported error.

Maybe a dev may see this and update the default on empty vendor to be ‘nextcloud’, as this had me not upgrading for over a year, and wondering how I was going to manually move all my data and setting to a new version.
Glad this solved it, and now up to v28 ;), fewww. Cheers.

2

I’m having trouble upgrading from 28 to 29 and unfortunately I already had this entry in the oc_appconfig table so there’s something else going on.

3

The vendor app gets set at installation time based on the same field in the /version.php from the Archive package at installation time.

I’m glad you figured out the culprit of the update problem in your environment, but that area of code you found only gets used if something is already weird (i.e. if that value never gets set). What’s the history of the environment? Was it originally a migration from OC by chance?

4

Not a migration from OC, but started at about NC v15.

I cant say about the ‘area of code’, only that I did a kind of manual trace of the Update code path, and the Exception string. This led me to the version and vendor check, and for me, it was a missing value in the db. Maybe over the history of upgrades, and there was one server hop (db export → import) this record value was ‘lost’.

I would implore any “devs” to review this Update path and version / vendor check, and on a install / successful update, to “refresh” any of the needed Values / records for this Updater code path… especially when it seems a common Exception, as reviewing this forum before my deep dive ;). Or as I previously suggested, changes the NC code default for vendor to fail-safe as “nextcloud” :slight_smile: