Description of problem: Backup stops with a message : "backup fails , due to an unknown error" Version-Release number of selected component (if applicable):deja-dup-40.0.2 Select a Steps to Reproduce: 1.Select a distant device as storage location (in my case smb://Livebox/USB_102) 2.Launch the backup 3.In many cases, the program fails I have foud on rmpfind.net, a newer version (OpenSuse) deja-dup-40.6-2.1.x86_64.rpm , which works fine on my computer. Is it possible to update dejà-dup to this version in Mageia 7.1 ? Thanks for all.
Summary: This version does't work properly => deja-dup backup fails due to an unknown error
Thank you Daniel for reporting this problem, and this:- > a newer version deja-dup-40.6-2.1.x86_64.rpm, which works fine on my computer This seems very positive. 40.0 is by now very dated. We already have version 40.6 in Cauldron, thanks to Shlomi. Can this be pushed to Mageia 7? Assigning to Shlomi, CC'ing DavidG who has also maintained it.
Assignee: bugsquad => shlomifCC: (none) => geiger.david68210
Hello, More information about the error: https://www.mageialinux-online.org/forum/topic-27495-1+erreur-sauvegarde-avec-deja-dup.php It seems that a first error occurs which has a message in French and a second one occurs when trying to display it because it is expected that the message is in Ascii, not unicode. Is the cauldron release with Python 3?
CC: (none) => yves.brungard_mageia
Yes Cauldron package uses now python 3.
So you can test the upcoming deja-dup-40.6-1.mga7 in Core/Updates_testing repo!
Hello David, deja-dup-40.6-1.mga7 installed and launched, it works fine. Thank you .
I think that the error is in duplicity, which should also be updated.
I have also upgraded duplicity and switch it also to python3 (duplicity-0.8.12.1612-1.mga7) in Core/Updates_testing repo!
OK i will update duplicity and i will tell you about how dejà-dup works after that Thanks
Hi David, duplicity-0.8.12.1612-1.mga7 installed today and deja-dup works fine. But i wonder if Python3 is used : $ locate duplicity/backend.py /usr/lib64/python2.7/site-packages/duplicity/backend.py /usr/lib64/python2.7/site-packages/duplicity/backend.py.sav /usr/lib64/python2.7/site-packages/duplicity/backend.pyc /usr/lib64/python2.7/site-packages/duplicity/backend.pyo
I don't know why the command "locate" give that result, but i have verified with dolphin, all files backend.* are in /usr/lib64/python3.7/site-packages/duplicity. All is ok Thanks
OK, fine, locate works with a DB cache, which should be updated with: updatedb command. This explains why.
Assigning to QA now, Advisory: ======================== Our current deja-dup package does not work properly, backup stops with a message : "backup fails , due to an unknown error". So this update fixes this issue updating deja-dup and duplicity to the latest upstream release and also switch them to python 3. ======================== Packages in 7/core/updates_testing: ======================== deja-dup-40.6-1.mga7.x86_64.rpm deja-dup-40.6-1.mga7.i586.rpm duplicity-0.8.12.1612-1.mga7.x86_64.rpm duplicity-0.8.12.1612-1.mga7.i586.rpm Source RPM: ======================== deja-dup-40.6-1.mga7.src.rpm duplicity-0.8.12.1612-1.mga7.src.rpm
Assignee: shlomif => qa-bugs
MGA7-64 Plasma on Lenovo B50 No installation issues. I don't get it with ths tool. I have NFS shares mounted from my desktop to this laptop. When I try to use this as storage location, I run into errors "no mount point". I then went to use "Local folders" and point this to the mounted NFS share (like /mnt/Documents), and do the backup, I see the files going by in the "Details" section and "Verifying", but nothing is stored there. The tool however knows that something has been done, because when I do it the second time, it just passes on. When I doa restore, to another folder, I see there that it restores in this folder the full path like /home/tester7/..... So I wonder where the backup went.
CC: (none) => herman.viaene
I found a set of duplicity files on the NFS server, but not on the folder I specified, but one level above. That will be the backup files. So, to conclude, the thing seems to sort of doing what it should or could do, but I'm not a fan of it. Leaving to people with more knowledge of this thng to OK it, I will not object.
@Herman: Thought I would follow this up without updating. I found the interface slightly confusing but managed to backup a folder from the home directory onto a USB drive. There was no "backup fails ..." message. It looked complete on the backup device with volume difftar files and one sigtar file. Deleted one file from the source directory and tried restore which looked like it might be working but gave no confirmation. Anyway, the deleted file did not reappear. Your tests look OK so I went ahead with the update. The python3 switch is confirmed. Going back to the first backup checking the manifest indicated that the backup was performed in sections approximately 52 MB in size and accounted for the whole directory. It was detected by the new version of deja-dup but this time the restore function came up with the Restore to Where? window, which was not seen before. Restore worked perfectly apart from a few files which did not have write permission and the deleted file reappeared. So this confirms your OK. Thanks Herman.
CC: (none) => tarazed25
Whiteboard: (none) => MGA7-64-OK
Looks good to me, guys. Validating. Advisory in Comment 12.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
Keywords: (none) => advisoryCC: (none) => tmb
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2020-0115.html
Status: NEW => RESOLVEDResolution: (none) => FIXED