Computer name changed

Bug #1268182 reported by Yorkshire Tyke
26
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Déjà Dup
Invalid
Medium
Unassigned
deja-dup (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

I am/was using Deja-Dup (version 26.0) on Fedora 19, I modified my router settings to use openDNS instead of my ISP's DNS.
Then the next time I ran Deja-dup I had the message:-

The existing backup is of a computer named
advancedsearch.virginmedia.com, but the current
computer's name is Zotac-Zbox-ID82. If this is
unexpected, you should backup to a different location.

Since I wasn't asked to specify a computer name, and the underlying "duplicity" (version: 0.6.22) would appear to get the machine name from the wrong file, I understand that the computer name is kept in two files (a bad practice in my mind).

So can the interface be changed to show and or allow one to specify what hostname is used?

Revision history for this message
Christophe Narbonne (christophe31) wrote :

I reinstalled my machine, and changed my hostname in the way (it could have been a new machine).
I didn't used deja-dup for restoration as I restored some things I don't back up (as multi media easy to find elsewhere, binaries folder).

It feel like deja-dup ask me to send to trash all history or change my hostname to match my previous one?

I let you guess what new/lazy user would do.

Vej (vej)
Changed in deja-dup:
status: New → Confirmed
Changed in deja-dup (Ubuntu):
status: New → Confirmed
Changed in deja-dup:
importance: Undecided → Medium
Changed in deja-dup (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Vej (vej) wrote :

This bug report (and its duplicate) deal with two problems (in my opinion):

- Fix the problem, that accepting the changed hostname is not persistent (i.e. that the dialog is showed more than once).

- Find a solution for the problem, that the hostname from socket.getfqdn() does not always match the one from socket.gethostname().

The later one is a problem of duplicity and therefore handled in bug #667885 ("
duplicity prefers fully-qualified-domain-name (fqdn) over hostname").

The first problem might be fixable in Déjà Dup. I will examine this further.

Revision history for this message
Matthew Hitchcock (myflight72510) wrote :

I'm having a similar problem and unable to find a solution so far. I'm running an Ubuntu 18.04 derivative - Peppermint 10 Respin. I damaged my partition and had to install the system again and was able to restore many of my settings and all my files. The problem is that when I installed the system fresh I changed the computer name.

When Déjà-Dup is supposed to run it fails with the error message about the computer name change. I can run it by clicking on "Forward" but would like to have it running on it's own.

Two problems I have with Déjà-Dup. I can't find a way around the computer name change problem and I would like to be able to set a specific time for the backup to occur.

Revision history for this message
Teafx (teafx-deactivatedaccount) wrote :

Just had this happen with internet disconnected. I did no name change of my own.

Reproduce:

Run backups normal with internet.

Keep router connected but pull internet.

Have Deja Dup run backups.

2nd day Deja Dup complains stupidly about a name change.

For whatever reason, the name Duja Dup uses in the backup files contains the a name in reference to the internet for me. No internet, no name.

I don't know why this is even a problem.

Revision history for this message
Teafx (teafx-deactivatedaccount) wrote :

Adding to my last reply:

Re-connect internet and backup continues normally without issue.

Literally, I do no name change but it complains about one. Something is really messed up here.

Revision history for this message
Michael Terry (mterry) wrote :

To Vej's points:

> Fix the problem, that accepting the changed hostname is not persistent

It *should* already be persistent. In the sense that each time duplicity backs up, it writes the current hostname to the manifest and checks against that going forward.

I think it just looks like it's not persistent because the fqdn can frequently change.

> Find a solution for the problem, that the hostname from socket.getfqdn() does not always match the one from socket.gethostname()

I've proposed a MR upstream to use gethostname instead of getfqdn. With this change, hopefully we don't need to do anything on our end.

https://gitlab.com/duplicity/duplicity/-/merge_requests/24

I'll close this deja-dup ticket, since I think we can just let duplicity handle this.

Changed in deja-dup:
status: Confirmed → Invalid
Changed in deja-dup (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Michael Terry (mterry) wrote :

The flatpak and snap releases of Deja Dup now include this duplicity fix.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.