Die Angaben sind sehr dünn um damit etwas anfangen zu können. Duplicity ist eine Abhängigkeit für deja-dup.
Und bitte immer die vollständigen Ausgaben des Terminals posten wenn du hier eine Fehlermeldung anhängst. Also Prompt, Befehl, Ausgabe, Prompt. Sonst kann das niemand nachvollziehen.
Funktioniert hier einwandfrei in einem Leap 15.4 VB guest mit deja-dup-40.6-150400.8.11 und duplicity-0.8.21-150400.1.7
Welche Version von deja-dup setzt du ein?
Schonmal die deja-dup config gelöscht?
Schonmal deja-dup und duplicity deinstalliert und wieder neu installiert?
Ja. Das habe ich übersehen, aber mit Leap gibt es auch kein Problem:
leap154:~ # zypper -n install -dD deja-dup
Loading repository data...
Warning: Repository 'Hauptaktualisierungs-Repository' metadata expired since 2023-05-27 12:03:47 CEST.
Warning: Repository metadata expired: Check if 'autorefresh' is turned on (zypper lr), otherwise
manualy refresh the repository (zypper ref). If this does not solve the issue, it could be that
you are using a broken mirror or the server has actually discontinued to support the repository.
Reading installed packages...
Resolving package dependencies...
The following 3 recommended packages were automatically selected:
duplicity-lang lftp python3-boto3
The following 16 NEW packages are going to be installed:
deja-dup deja-dup-lang duplicity duplicity-lang lftp librsync2 python3-boto3 python3-botocore python3-fasteners python3-future python3-jmespath python3-lockfile python3-monotonic python3-python-dateutil python3-s3transfer python3-simplejson
16 new packages to install.
Overall download size: 0 B. Already cached: 11.0 MiB. Download only.
Continue? [y/n/v/...? shows all options] (y): y
In cache lftp-4.9.2-150400.1.8.x86_64.rpm (1/16), 815.2 KiB
In cache librsync2-1.0.0-1.27.x86_64.rpm (2/16), 50.6 KiB
In cache python3-lockfile-0.10.2-2.24.noarch.rpm (3/16), 27.7 KiB
In cache python3-monotonic-1.5-7.3.13.noarch.rpm (4/16), 17.1 KiB
In cache python3-python-dateutil-2.8.1-1.24.noarch.rpm (5/16), 312.4 KiB
In cache python3-simplejson-3.17.2-1.10.x86_64.rpm (6/16), 73.1 KiB
In cache python3-fasteners-0.14.1-3.2.4.noarch.rpm (7/16), 43.1 KiB
In cache python3-jmespath-0.9.3-1.21.noarch.rpm (8/16), 48.3 KiB
In cache python3-future-0.18.2-150300.3.3.1.noarch.rpm (9/16), 721.0 KiB
In cache python3-botocore-1.29.89-150200.37.14.1.noarch.rpm (10/16), 6.7 MiB
In cache python3-s3transfer-0.6.0-150200.9.7.1.noarch.rpm (11/16), 119.7 KiB
In cache python3-boto3-1.26.89-150200.23.12.1.noarch.rpm (12/16), 830.6 KiB
In cache duplicity-0.8.21-150400.1.7.x86_64.rpm (13/16), 486.6 KiB
In cache duplicity-lang-0.8.21-150400.1.7.noarch.rpm (14/16), 149.5 KiB
In cache deja-dup-40.6-150400.8.11.x86_64.rpm (15/16), 293.0 KiB
In cache deja-dup-lang-40.6-150400.8.11.noarch.rpm (16/16), 447.0 KiB
Checking for file conflicts: ...........................................................................................................................................................................................................................................[done]
leap154:~ #
Wenn ich deja-dup --backup starte, gibt es im Terminal keine weitere Meldung. In /var/log/messages finde ich, wenn ich versuche, die angeforderte Installation auszuführen, dies:
2023-05-28T14:41:59.073615+02:00 zeus dbus-daemon[1197]: [system] Activating via systemd: service name='org.freedesktop.PackageKit' unit='packagekit.service' requested by ':1.513' (uid=1001 pid=15279 comm="deja-dup --backup ")
2023-05-28T14:41:59.077224+02:00 zeus systemd[1]: Starting PackageKit Daemon...
2023-05-28T14:41:59.082199+02:00 zeus PackageKit: daemon start
2023-05-28T14:41:59.110679+02:00 zeus dbus-daemon[1197]: [system] Successfully activated service 'org.freedesktop.PackageKit'
2023-05-28T14:41:59.111409+02:00 zeus systemd[1]: Started PackageKit Daemon.
2023-05-28T14:42:02.520352+02:00 zeus PackageKit: resolve transaction /1_bccaebaa from uid 1001 finished with success after 3397ms
2023-05-28T14:42:02.528472+02:00 zeus PackageKit: resolve transaction /2_bbecbbed from uid 1001 finished with success after 0ms
2023-05-28T14:42:07.075137+02:00 zeus PackageKit: uid 1001 is trying to obtain org.freedesktop.packagekit.package-install-untrusted auth (only_trusted:0)
2023-05-28T14:42:13.656376+02:00 zeus polkit-agent-helper-1[15615]: gkr-pam: unable to locate daemon control file
2023-05-28T14:42:13.656522+02:00 zeus polkit-agent-helper-1[15615]: gkr-pam: stashed password to try later in open session
2023-05-28T14:42:13.673292+02:00 zeus polkitd[1219]: Operator of unix-session:9 successfully authenticated as unix-user:root to gain ONE-SHOT authorization for action org.freedesktop.packagekit.package-install-untrusted for system-bus-name::1.513 [deja-dup --backup] (owned by unix-user:stephan)
2023-05-28T14:42:13.676564+02:00 zeus PackageKit: new install-packages transaction /3_acbeccda scheduled from uid 1001
2023-05-28T14:42:13.676675+02:00 zeus PackageKit: uid 1001 obtained auth for org.freedesktop.packagekit.package-install-untrusted
2023-05-28T14:42:20.825463+02:00 zeus PackageKit: install-packages transaction /3_acbeccda from uid 1001 finished with failed after 7146ms
2023-05-28T14:42:20.826875+02:00 zeus package-update-[7471]: failed to get transaction results: The packages are already all installed
2023-05-28T14:42:38.879971+02:00 zeus PackageKit: daemon quit
2023-05-28T14:42:38.905231+02:00 zeus systemd[1]: packagekit.service: Deactivated successfully.
Da steht, glaube ich, auch nichts anderes drin als dass deja-dup PackageKit auffordert, duplicity zu installieren und dass PackageKit einen Misserfolg zurückmeldet, weil ja duplicity schon installiert ist. Die Frage ist: warum merkt deja-dup das nicht?
Die deja-dup Einstellungen ändert man mittels dconf; da weiß ich nicht, wie man die Einstellungen sinnvoll löschen (und wieder herstellen) kann.
Ich habe PackageKit entfernt und verwende ausschließlich zypper dist-upgrade. Mir bleibt daher das Grübeln über das rätselhafte Verhalten von PackageKit erspart und ich kann mich mit wichtigeren Dingen beschäftigen:
erlangen:~ # zypper search --details --installed-only packagekit
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+--------------------+---------+-----------+--------+-----------------------
i | libpackagekitqt5-1 | package | 1.1.1-1.1 | x86_64 | Haupt-Repository (OSS)
erlangen:~ #
Es hat nur einmal funktioniert… Bei den nächsten Backupversuchen war es wieder das alte Problem.
Das ist nun mein aktueller Versuch. Déjàdup scheint auf PackageKit nicht angewiesen zu sein, um das Vorhandensein von Duplicity zu überprüfen (wozu braucht man es dann?). Gerade läuft ein Backup, hoffentlich bleibt es dabei.
ich habe genau das gleiche Problem. Die Frage ist für mich wie entferne ich das PackageKit ? und funktioniert dann Déjàdup stabil ?
immer mit yast die Abhängigkeiten brechen nur um dulicity zu deinstallieren ist etwas umständlich.
wenn ich das PackageKit entferne was ändert sich sich dann zum vorherigen System.
Hallo,
Packagekit deinstallieren: sudo zypper rm gnome-packagekit
Danach funktioniert DejaDup wieder. Aber: die automatische Systemaktualisierung zum Beispiel über den “Package Update Indicateor” funktioniert dann nicht mehr. Man muss dann selbst aktiv werden und (siehe Post von karlmistelberger) mit sudo zypper dist-upgrade das System aktuell halten.
Gruß
Stephan
Bei mir kann ich mit rpm -e --nodeps duplicity und dann Neu-Installation das einmalig ans Laufen bringen. Aber auch mit deinstalliertem “gnome-packagekit” muss ich jedes Mal beim Backup zwei mal (für’s Backup und das Überprüfen) duplicity löschen, damit deja-dub das dann wieder neu installiert.
Bin auf Leap 15.5. Frisch installiert hatte ich mal 15.2, glaube ich, seitdem bin ich immer per dist-upgrade migriert.
Ja diese “Lösung” fahre ich auch momentan
ist wahrscheinlich in der Prio nicht so weit oben bei den Entwicklern.
Dabei heißt es doch " Kein Backup - kein Mitleid"
es kann automatisch oder manuell alles oder selbst gewählte Ordner/Dateien in festgelegten Zeiträumen auf Netzlaufwerke verschlüsselt sichern. Inklusive Überprüfung des Backups. Die zeitlichen Abstände zwischen Vollbackup und inkrementell weiß ich leider nicht.
