Release: 2.0.4.8 (canary) 2018-12-13

2.0.4.8-2.0.4.8_canary_2018-12-13

Does this release supersede the 2.0.4.7 release posted just before?
Also, any plans to fix the issue with the “check for updates” functionality?

I wanted to translate the new functions on viewing the logs, where can I go to translate into Italian?
thank you

You can translate per transifex,
https://www.transifex.com/duplicati/duplicati/dashboard/

@kenkendk
when i want to set the log level, there is only the option to disable. The other options are missing

Ignore 2.0.4.7, I forgot to git pull so it is identical to 2.0.4.6.

Yes, once I figure out why it fails, I will fix it :slight_smile:

Can you reload the page? The options are loaded from the server, so I think there might be a glitch where the options are empty.

I have reloading the page with STRG+F5, clearing chache, private mode in browser, Browser: vivaldi, firefox edge,…
In the debug console from the browser, is after click on the combobox this entry:

[Violation] Added non-passive event listener to a scroll-blocking ‘mousewheel’ event. Consider marking event handler as ‘passive’ to make the page more responsive. See Chrome Platform Status

Another thing, when i go to the protocol view, the saved log entries are only displayed after a change from live to saved…

If it helps, every time I’ve tried so far this pair of errors appears in the log:


(highlighted previous times to show how it always puts 2 entries in the log)

Also if it helps I downgraded to 2.0.4.2 and 2.0.4.4 and for both the update checks instantly started working again, so the issue appears tied to something in the 2.0.4.5 release, not some change on the updates server or DNS.

alt.updates.duplicati.com indeed doesn’t resolve. updates.duplicati.com resolves to 139.59.135.67.
Did Duplicati 2.0.4.4 and later change the update server URL to alt.updates.duplicati.com? In that case, the solution could be adding an A record alt.updates.duplicati.com in DNS that points to 139.59.135.67.

Yeah, I assume @kenkendk’s comment here that it was “not a problem” meant that the alt.updates.duplicati.com error was EXPECTED.

I’m going to see if I can figure out how to update my hosts or local DNS for a Docker container and dummy in 139.59.135.67 for alt.updates…

Edit:
Well, either I don’t know what I’m doing in Docker (likely) or there’s something else going on (also likely). Am I supposed to get something other than a 503 error from http://139.59.135.67/? (I assume it just hasn’t been configured to host anything off of IP.)

Same behavior here.

Yeah, you cannot do that. The server relies on SNI to pick the right certificate. If you send a name that it does not know, you get something like “upstream server error” as there is no server that handles the name.

Urgh… that really sounds annoying, given that it is a beta release and downloaded by a lot of user…

Does it also fail with 2.0.4.6 upgrade to 2.0.4.8 ?

Otherwise, I will try to install 2.0.4.5 on a clean system and debug the update problem.
From the error message, it sounds like 2.0.4.5 is using the wrong key to validate the signature in the update package.

The same happens to me for 2.0.4.4_canary_2018-11-14

For me, yes - and I think my previous comment about 2.0.4.2 and 2.0.4.4 updates working may have been incorrect. I think they were reporting an already detected update after their individual checks failed.


Keeping in mind I do weird things to my installations, I did some tests and it appears I now get the error on ALL versions as far back as at least 2.0.4.2 exp (my base install).

Based on my 2.0.4.2 exp Docker base install (set for the canary update channel):

  • 2.0.4.2 exp generated Signature and NameResolution errors
  • 2.0.4.3 can generated Signature and NameResolution errors
  • 2.0.4.4 can generated Signature and NameResolution errors
  • 2.0.4.5 bet generated Signature and NameResolution errors
  • 2.0.4.6 can generated NameResolution and Signature errors (yes, errors reversed order)
    Note that loading Stored logs got really slow here (toggling to Live than Stored ‘fixes’ this, I think it’s a UI issue)
  • 2.0.4.7 can (skipped invalid release)
  • 2.0.4.8 can generated NameResolution and Signature errors (yes, errors reversed order)

Two side notes:

  1. Sometimes the errors are Signature then NameResolution and other times they’re reversed (even on the same version) - I assume it has to do with how long it takes things to time out NOT the order in which they are called
  2. Why aren’t these errors showing up in the GUI alerts?

Hi tigro11, follow the directions of capilano, so you give me a hand in the translation. :grinning:

The NameResolutionFailure may have been resolved - please try your update again.

Indeed, updating from 2.0.4.4 canary to the latest version just worked. :smiley:

1 Like