I just installed Windows 10's April 2018 Update, and it looks like it
enabled Fast Startup again.
I've got Ubuntu 18.04 now, with duplicity/bionic,now 0.7.17-0ubuntu1
amd64 [installed]. And the bug remains:
Traceback (innermost last):
File "/usr/bin/duplicity", line 1555, in
The above has nothing to do with this bug report. Perhaps you should post
it to https://bugs.launchpad.net/bugs/1727653
On Mon, Mar 19, 2018 at 2:07 AM, sebastienserre <1729...@bugs.launchpad.net>
wrote:
> Hello
>
> Traceback (most recent call last):
> File "/usr/bin/duplicity", line 1546, in
Hello
Traceback (most recent call last):
File "/usr/bin/duplicity", line 1546, in
with_tempdir(main)
File "/usr/bin/duplicity", line 1540, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1391, in main
do_backup(action)
File "/usr/bin/duplicity", line 1468, in do_backup
Ubuntu 17.10 (duplicity 0.7.12)
Traceback (most recent call last):
File "/usr/bin/duplicity", line 1546, in
with_tempdir(main)
File "/usr/bin/duplicity", line 1540, in with_tempdir
fn()
File "/usr/bin/duplicity", line 1391, in main
do_backup(action)
File "/usr/bin/duplicity",
I suspect this is fixed in duplicity 0.7.15 now -- by commit 1318 [1].
I'm going to tentatively mark the upstream side fixed. Can someone
confirm? Ubuntu bionic does not yet have 0.7.15, but it should before
release.
[1] http://bazaar.launchpad.net/~duplicity-
Take a look at the message in duplicity-team called "Help with unicode
branch (for Python3 support)".
It turns out that uexc() is using ufn() which is calling
sys.getfilesystemencoding(). We may have a fix, not implemented yet, for
sys.getfilesystemencoding() returning 'ascii' or None when
Actually, that looks like what is happening — an error is bubbling up
from the system and when trying to format it, duplicity is misconverting
from/to Unicode and crashing. Possibly due to a translation.
Reassigning to duplicity and myself.
** Package changed: deja-dup (Ubuntu) => duplicity
I have the almost the same system configuration as Paul Nickerson,
except that backups are stored on a separate NTFS-formatted drive, that
neither Ubuntu nor Windows boots. Disabling Fast Startup solved the
problem for me too. Thanks for sharing the solution!
I have noticed that while Fast
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: deja-dup (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729695
Title:
I thought of something that could be a change on the system. I dual boot
Ubuntu and Windows. The target disk for backups is formatted as NTFS,
and Windows 10 mounts it when it boots. I just checked the Windows logs,
and the second to last time I booted Windows was just before the backup
started
I don't know why, but the backup started working again yesterday. I did
not do anything to try and fix it.
The only thing I can think of that changed on my system is that these packages
were updated (from /var/log/dpkg.log):
2017-11-07 08:10:32 upgrade google-chrome-stable:amd64 62.0.3202.75-1
Ubuntu 17.04 was fresh installed in early July 2017, and I've since
upgraded to 17.10 (I did not fresh install 17.10). I did not reconfigure
Deja Dup before or after that upgrade.
When I did the fresh install and then set up the backup, I already had a
backup directory on the secondary drive that
Hello!
This looks exactly like a very old bug, that should be fixed for a
while. So I am wondering if this is the old problem, which sometimes
stays if people continue to use their old backups while upgrading to
newer versions. So I have to ask a few questions:
When did you first configured
13 matches
Mail list logo
