I have no idea how that is even possible. The documentation clearly states that only one version with the same upgrade-code can be installed at a time. The upgrade code has not been changed since the MSI’s were first published.
Could it be the same as @Taomyn experienced, where you have two versions installed?
That is caused by the slow loading, a fix is ready soon.
Me neither as 108 was installed over 107 without issue, but I just had the exact same thing on two other Win2k22 servers so needed to reinstall on those. I still have two Win11 machines to check out when I get home so I will let you know, but if you want me to grab any extra information from them before I try to fix them, let me know.
The “again” sounds like failed upgrade did that. Have normal upgrades worked?
Kind of vague. There have been MSI releases for lots of years. A recent change:
Remove existing product before install for MSI #5538
I’m thinking that’s what About → Changelog shows as:
2024-09-11 - 2.0.9.107_canary_2024-09-11
Another fix for MSI packages breaking on upgrade
2.0.9.106 had this:
- Fixed MSI packages failing to upgrade
- Re-added the `FORSERVICE=true` flag to MSI packages
with that used by the user script, and me asking if it matters for fails.
Maybe I’ll test some upgrades, but I’m not sure what I should target.
Unfortunate clash of terminology. I was referring to the MSI field named “UpgradeCode”.
That is the big question. I have tried various approaches to replicate this, but I have not succeeded.
The fixes you found are changing the way the previous product (meaning MSI) is uninstalled.
The “fix” is to remove everything before even attempting to start the installation.
This has the downside that files that are already present in the correct version (i.e., not changed between versions) will now be removed and copied in again.
But that does not explain how/why the previous version is still listed as “installed”.
No, there was no failed upgrade mentioned, it just didn’t perform what was expected and I didn’t look for this as an issue because I thought it had been fixed.
@kenkendk I just remembered, I left the setting that would keep MSI logs for each run, so here’s the last 3 upgrades, to .108 and then for the two recent to .109, perhaps this can shed some light on it.
MSI-Logs.zip (601.9 KB)
I’m running Debian testing (trixie) on this particular machine.
If I do that, it wants to install 191 dependencies (probably because I’m running KDE Plasma) and remove pulseaudio packages. I don’t think I want to proceed with that test. Doesn’t sound like it solves the issue for you anyway with .109.
It could be different for KDE, but Gnome at least, I had to add the shell extensions to get it working. For .109 it still crashes due to the Tmds version problem.
I have put up a new version that fixes the issues reported in this topic (except the lingering update notification from @ts678 which is registered as an issue).
I only had the.209 installed. Version.210 solved the problem for me, everything works as expected. Thank you very much!
2 posts were split to a new topic: Upgrade with MSI causes duplicated versions installed
I know of some documentation work, but I don’t think anything was published by Experimental. Recent release of Beta before documentation availability is likely to impede the smooth rollout.
I was delayed a bit with the documentation. We have written much of the documentation, but there are still a few empty pages, and I need to get the current documentation fitted in there, so we do not break links.
I expect it to be available early next week.
There are specific detailed questions already. I was just trying to find the new environment variable format for the webservice options, because there’s a GitHub issue where a user’s backup is down.
Downgrading also wasn’t in at least the last draft docs I read. Need directions for exact use cases. There are annoying scenarios that go beyond version setting, e.g. due to crypto and the new table.
FWIW SQLite supports adding a table only if it doesn’t exist, which would avoid TokenFamily error.
OK, I have added them to the draft docs.
The rule is to prefix with DUPLICATI__, upper-case it, and replace - with _:
DUPLICATI__WEBSERVICE_PORT=8200
I think downgrading is quite complicated and not generally possible. The latest few changes are easily revertible, but we could potentially write a new table that cannot be reverted.
The backup copies of the database should work in most cases.
Good point. We could be more forward-thinking and allow a user to re-upgrade, by having a conditional create in this case.
Directions were even published in the early release notes. Making people dig is unattractive, but
is a somewhat bigger ouch, so maybe the proposal of
should be clearly documented in terms of file names and backup naming style. There are usually lots of different backups laying around. Disclaiming some cases is worrying. I don’t like recreates.
On the flip side, doing it this way avoids facing RC4 encrypted database that DB editor won’t edit. Solution there is --unencrypted-database, but it’s extra work, especially if it’s a Windows service.
Those are also pretty ugly when they go into a fast Server respawn loop. It’s not obvious, and can write out files like backup Duplicati-server 20241130120245.sqlite (true case) at a rapid pace.
This is documented in the new documentation, which is now live. (I am still working on getting the old links to work as backpointers to the previous documentation.)
Not sure what “disclaiming” is refering to here?
True. I have now added downgrade instructions to the documentation
That sounds like an issue that should be in the Github issues. Is this reported somewhere?
is still very vague, just saying where to look (good first step) without saying what to look for.
Refers to the two hedge-words “should” and “most” above. It’s not so specific. Should it be?
I don’t know if there are known cases being disclaimed, or if it’s so unknown that it can’t be.
I haven’t looked, and don’t know if it’s new. The respan of Server is (I’d guess) an older issue. Server exits, and WindowsService (which is probably all Windows knows of) loops on restart.
I found this on 2.0.8.1 Beta and 2.1.0.2 Beta upgrade and downgrade test as a user might try.
Thanks for the new directions on downgrade, but I was doing other things. I can file it anyway.
I also want to look again to see if new Beta installer stops the Windows service on the way up.
I see that I was being a bit vague there. The database backup is always created prior to updating the database. Since it is a copy of the pre-upgrade database, it is always possible to roll back.
The “most cases” refers to the situation where the user starts using the new version and after a while has a need to downgrade. In this case the current database(s) contain changes that are not included in the backup copy, and this (hopefully rare) situation needs the rollback instructions.
I do not understand what is missing. The error message will say something like “Unsupported database version, probably caused by downgrade” and the article is specifically “downgrading from 2.1.0.2 to 2.0.8.1”.
What is needed here?
Thanks!