Reboot required for 2.0.2.9 Canary over-install

I was testing installing the 2.0.2.9 Canary release on Windows 10 (currently have 2.0.2.8 Canary as a service) and got the following message:

The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup.

I don’t recall seeing this on any previous releases, do you know what is being changed that requires a reboot now? (I did confirm the Duplicati service was stopped before running the install.)

Note that this IS an installation over a previous version as the built in upgrade feature does the download, seems to try to install something, but then the GUI won’t come up even if the service is verified running.

If you are using Duplicate2 as a service, you need to stop the service before upgrading. I’ve seen a similar situation with Windows 10 but after manually stopping the Duplicati Server, the upgrade went well and after completion, I had to start the server manually again…all without the need of a reboot.

Hope this helps…

Thanks. I tried the install first, got the message about rebooting, then remembered I forgot to stop the service.

After cancelling out of the install I manually stopped the service and tried the install again but still go the reboot message. It could be that the first aborted attempt left something goofy sitting around that screwed up future attempts.

I expect it will work fine once I do actually reboot. If not, I’ll post about it. :slight_smile:

I just tried the upgrade to the latest Canary version using the .msi file and after the upgrade completed, the Duplicati.Server could not be started…the file could not be found. …huh???
I then downloaded the .zip version and copied all files to the Duplicati2 program directory and then the service could be started without any problems…weird.

Thanks for the tip - I’ll keep it in mind if a reboot doesn’t solve my issue.

When you do that, Duplicati will notice that the base version (in the program folder) is newer than the updates and ignore it. The updates are stored in %LOCALAPPDATA%Duplicati\updates if you need to remove a botched one.

I saw them in there when I started poking around to try and figure out what I broke, but it never occurred to me that I could just delete the onethat had failed. :slight_smile:

I am trying a new thing for the next canary. Instead of relying on loading the update inside the running process (using AppDomains) it will instead start a new process and forward input/output to this process.

I hope this will make the update mechanism more stable.

Sounds good. I haven’t installed 2.0.2.10 yet but I’m assuming this new update process won’t be in it yet.

Let me know if there’s a particular update flow you’d like me to test.

This will be in 2.0.2.11 and it cannot be tested until 2.0.2.12…

For the record the internal updater worked fine for me going from 2.0.2.10 to 2.0.2.12 on Windows 10. :smiley:

As expected, my Tray Icon shortcuts “lost” their --no-hosted-server parameter causing the tray icon to start on port 8300. Manually adding the parameter back resolved that issue.

I did not expect that. The MSI is the one installing the tray-icon, so using the internal updater should not mess things up?

I’d be willing to test for that again. Is there a particular downgrade method I should use?

FYI - on another machine I did a Windows 10 2.0.2.1_beta (service) GUI switch to canary then GUI update to 2.0.2.12_canary, and it seemed to work fine.

Additionally, it didn’t seem to wipe the --no-hosted-server parameter from my “C:\Users<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup” shortcut - though admittedly that was a manually added shortcut.