Sorry, I meant to follow up on that, but got sidetracked with the Kestrel update :/.
Anyway, I think this is something related to the RPI causing errors.
I tried with Docker to reproduce (I have the armv7 package in the CWD):
docker run -it --platform linux/arm -p 8200:8200 -v.:/packages debian:latest bash
Then running inside docker:
apt update -y && apt install -y libicu72 libssl3
dpkg -i /packages/duplicati-2.0.9.101_canary_2024-06-27-linux-arm7-cli.deb
duplicati-server --webservice-port=8200 --webservice-interface=any
This starts up just fine, and creates the SQLite database, indicating no problems with SQLite missing or being broken.
I crashes due to some memory issue, but I suspect this is Docker related.
Since I cannot reproduce your issue, can we perhaps rule out a packaging isssue? I have the following files:
> ls -lah /usr/lib/duplicati/*ite*
-rw-r--r-- 1 root root 215K May 20 04:03 /usr/lib/duplicati/Microsoft.AspNetCore.Rewrite.dll
-rw-r--r-- 1 root root 35K May 20 04:03 /usr/lib/duplicati/Microsoft.Extensions.FileProviders.Composite.dll
-rw-r--r-- 1 root root 91K May 16 2020 /usr/lib/duplicati/SQLite-net.dll
-rw-r--r-- 1 root root 2.6M Apr 8 10:09 /usr/lib/duplicati/SQLite.Interop.dll
-rw-r--r-- 1 root root 22K Jun 27 11:43 /usr/lib/duplicati/SQLiteHelper.dll
-rw-r--r-- 1 root root 1.6K Feb 13 21:38 /usr/lib/duplicati/SQLiteHelper.dll.config
-rw-r--r-- 1 root root 6.0K May 1 2020 /usr/lib/duplicati/SQLitePCLRaw.batteries_v2.dll
-rw-r--r-- 1 root root 46K May 1 2020 /usr/lib/duplicati/SQLitePCLRaw.core.dll
-rw-r--r-- 1 root root 5.5K May 1 2020 /usr/lib/duplicati/SQLitePCLRaw.nativelibrary.dll
-rw-r--r-- 1 root root 56K May 1 2020 /usr/lib/duplicati/SQLitePCLRaw.provider.dynamic_cdecl.dll
-rw-r--r-- 1 root root 369K Aug 25 2021 /usr/lib/duplicati/System.Data.SQLite.dll
-rw-r--r-- 1 root root 71K May 17 17:46 /usr/lib/duplicati/System.Diagnostics.TextWriterTraceListener.dll
-rw-r--r-- 1 root root 55K May 17 17:47 /usr/lib/duplicati/System.Resources.Writer.dll
-rw-r--r-- 1 root root 22K May 17 17:35 /usr/lib/duplicati/System.Xml.ReaderWriter.dll
-rw-r--r-- 1 root root 742K Apr 7 2020 /usr/lib/duplicati/libe_sqlite3.so
I also have an RPI4 to test with, but I need to know what OS version you installed?
No, you should not see those errors anymore. The current canary requests latest-v2.manifest and the beta requests latest.manifest, both files are present and return status code 200.
What urls do you see reported by Duplicati.CommandLine.AutoUpdater.exe / duplicati-autoupdater ?
It is supposed to open the download page:
https://duplicati.com/download-dynamic?channel=canary&from=2.0.9.100
I think the text should be changed to “Download”.
Do you see any errors in the console or logs when clicking “Install” ?
No, I will change it to be backwards compatible with the previous system.
The data is there in the manifest to point to the correct (or at least the same kind), but it does not currently use this. The channel name is embedded in the binaries during build, so it will look for canary builds unless overridden.
Unfortunately, the wixl tool does not currently support toggling the features (read: shortcuts) via conditions, so it will actually install the shortcuts. The missing file sounds like either an MSI quirk or an AV tool has quarantined it. I have not experienced this file as missing in any of my tests.
@Taomyn Is it reproducible for you?
The .NET runtime is bundled with the executables so you do not need to download it. Are you sure you have “unblocked” the zip file before extracting?
I think crashes here are not reported to the commandline, but can be found in the Windows Event Log. Do you see any indications of why it does not start up?
Yes, that part is still the same. The build process now builds the binaries first:
- win-x64-gui
- win-x64-cli
- linux-x64-gui
- …
After the binaries are built, the package tool uses the same source to produce the packages (zip, msi, dmg, deb, rpm, docker, etc). The installed contents of *-win-x64-gui.zip and *-win-x64-gui.msi should be exactly the same and all files should have the same hashes.
Yes, that is how the installation knows what install package you used, and this is intended to be used to guess what updated package you would like (but it is not used just yet).
I think there is something quirky going on with the MSI package. Ideally, it should just remove the old stuff and copy in the new. But for some reason it occasionally seems to install first and then remove afterwards, causing everything to be broken. Sadly, I have not managed to find a way to reproduce it.
Ideally yes, the update messages should be removed.
Yes, I think the error is that the installer somehow removes the files after installation. It seems to have something to do with what version of Duplicati that is being upgraded from.
As mentioned in the 2.0.8.105 thread, I tried several variations of installing 2.0.8.1 and upgrading without being able to replicate the issue. Any hints as to how I can reproduce this are appreciated. My only idea at this point is to try to install a chain of updates and reboot in between the installations.
