Changing existing home partition UUID to defined value.

[tannington]

Although quite basic I just want to be sure what I’m doing in terms of procedure, is correct.

I have three machines, all have ext4 file systems and a separate /home drive or partition.

I want to change the UUID of /home on two of those to match that of the first, i.e. all three machines have the same UUID for /home. [1]

As I understand it from the “manual”, one can use tune2fs as follows:

tune2fs /dev/{device} -U {uuid}

So I would:

1. boot from a live USB
2. use tune2fs to change /home’s UUID
3. edit the relevant entry in /etc/fstab to reflect the changed UUID

I assume as home is mounted after “switch root” there is no need to mkinitrd ?

4. reboot normally and the new UUID should be in effect

Normally I’d be quite happy to just try, but in this instance I want to be sure I’m not making some basic (stupid) error…

[1] All three machines have an area below ~/ that I keep synchronised using “unison” ( https://software.opensuse.org/package/unison ). In general this works well. However “digikam” (https://software.opensuse.org/package/digikam ) stores within it’s database not only the path(s) to it’s image collection(s) but also the UUID of the partition. Each time digikam is opened following a synchronisation which includes it’s database files from another machine, it is necessary to tell digikam it is dealing with the same collection, as the UUID has changed. My rationale was if /home’s UUID was the same on each machine then digikam would no longer think the collection is (possibly) the wrong one.

[hcvv]

IMO it is not need to boot from a live/reecue system. Bootin in run level 1 (or changing to it when nobody uses the GUI) should be enough to log in as root, umount /home and do the changes.

But I doubt that making the UUIDs the same is a good thing to do. One od de U in there means Unique. And destryoing that capacity would be very counterintuitive.

I am not sure I understand your Digikam case (or it’s connecetion with the way you synchronize things), but to me there is something rotten there.

Oh and BTW, I do not think it is the UUID of the partition, it is the UUID of the file system. (and that is why you want to use tune2fs and not a partitioner of some kind).

[tannington]

@hcvv

IMO it is not need to boot from a live/reecue system. Bootin in run level 1 (or changing to it when nobody uses the GUI) should be enough to log in as root, umount /home and do the changes.

OK, yes probably easier, and certainly faster.

But I doubt that making the UUIDs the same is a good thing to do. One od de U in there means Unique. And destryoing that capacity would be very counterintuitive.

Hmm… I had thought about that, but at the moment, can’t think of a valid reason why they can’t be the same, they are after all different machines.

I am not sure I understand your Digikam case (or it’s connecetion with the way you synchronize things), but to me there is something rotten there.

OK I’ll explain, hopefully more clearly…

Assume just two machines (#1 and #2) , both with identical image collections managed by digikam, located for example at ~/Photos/Digikam

Digikam’s database references that collection as UUID/~/Photos/Digikam - therefore when synced from #1 to #2 digikam’s database on machine #2 then has the UUID of machine #1 (as that’s where that database came from). There’s nothing “rotten” IMHO, it’s just the way digikam works. It assumes as the path to the collection is still the same, only the UUID differs, it is a restored backup or is on removable media, either way it involves “telling” digikam the collections “new” location.

Oh and BTW, I do not think it is the UUID of the partition, it is the UUID of the file system. (and that is why you want to use tune2fs and not a partitioner of some kind).

Yes indeed, my bad. The UUID is created when the file system is formatted, nothing to do with the partition.

Thanks.

[gogalthorp]

You could use label instead those are easy to control. As long as you don’t have the same labels on one machine all is good…

[hcvv]

@tannington

Digikam’s database references that collection as UUID/~/Photos/Digikam -

That is what I call “rotten”.

What is the idea behind that? Digikam is an end-user application. That should not even “know” about file systems. It should work with files and the pathes to it. That is the very idea about the one directory tree in a Unix/Linux system. In day to day operations the whole underlying construction of mounted file systems is unvisible.

I can imagine a lot of actions done by the system manager (adminstrator if you want to use that word) done for the maintenance of the system (changing the use of file systems, e.g. putting the home directory of a user on it.s own file system, changing the size, type, place or what ever of the /home file system) that are all invisible to the end-user. And then this lousy application is telling him that it can not find his photos anymore >:(.

@gogalthorp

You could use label instead those are easy to control. As long as you don’t have the same labels on one machine all is good…

Yes, you can use LABEL (or other identifications) to be used in e.g. /etc/fstab. But we are here talking of the (unexpected) use of the UUID by Digikam.

I have no idea if Digikam can be configured to use LABEL, but then we have the same problem: the three LABELs must be the same. And while this might be less strict then UUIDs, it is a confusing idea to label several file systems in the same environment with the same label.

[malcolmlewis]

Hi
@tannington, I suspect whichever system you change the UUID will break… it’s at a lower level in the system (magic-strings) and used in multiple places…

Maybe these threads offer some insight?
http://digikam.1695700.n4.nabble.com/Syncing-Digikam-collections-and-databases-between-different-computers-td4674927.html
http://pedroivanlopez.com/digikam/

[hcvv]

Reading those links, it seems to be a major flaw in the Digikam design. Somewhere in those texts (I only glanced through them) is mentioned that this is on Unix systems.

It seems that the Digikam people got stuck in the MDS-DOS world, where there is not one directory tree, but there is one for each device (do they call that a file system?) and thus you have to add a device identifier (if I remember correctly from the old days, something like A:, etc.). And they transfered that idea and forced it, with some imagination, upon Unix/Linux.

Very sad for such a fine program.

[nrickert]

@tannington

tune2fs /dev/{device} -U {uuid}

Yes, that should work – as far as I know.

I experimentally installed Mageia two or three years ago. And it reformatted the root partition, but kept the same UUID. I like that. I’m not sure if it still does that.

For your particular issue: Maybe you should consider using a container formatted with “ext4”. And mount that container as needed. Then you can synchronize the container itself between your different systems.

[knurpht]

I wouldn’t mess with the UUID’s either. But, having met things like this in the past, I do see a couple of hacks:

1. Do not sync the digikam db, only the rest. That way all three machines would have their own database. Unison should be able to exclude that database
2. Do it properly: export through NFS server/client. That means you would still have to have the UID’s of the users in sync, and the NFS server machine on before other machines.
3. Do it even more properly: Have a dedicated server, f.e. a Rpi with some external storage is fine for that.

[tannington]

@hcvv

That is what I call “rotten”.

I may be coming round to your way of thinking now…

I have no idea if Digikam can be configured to use LABEL, but then we have the same problem: the three LABELs must be the same. And while this might be less strict then UUIDs, it is a confusing idea to label several file systems in the same environment with the same label.

No, digikam’s behaviour is fixed in that regards, and I don’t see the developers keen to move on the use of the UUID. They do, I think, have a valid point on it’s use for removable media, but it would be better if it wasn’t used for fixed media.

@malcolmlewis

Maybe these threads offer some insight?
http://digikam.1695700.n4.nabble.com/Syncing-Digikam-collections-and-databases-between-different-computers-td4674927.html
http://pedroivanlopez.com/digikam/

Thanks for those, I had read quite a few posts on the digikam mailing list, although not that particular one I believe. This isn’t a new issue by any means, I’ve came across it before when simply restoring a copy from a different machine, also when swapping out a rotating drive for an ssd.

@nrickert

For your particular issue: Maybe you should consider using a container formatted with “ext4”. And mount that container as needed. Then you can synchronize the container itself between your different systems.

Confession, containers are new to me. I may investigate that later.

@Knurpht

I wouldn’t mess with the UUID’s either. But, having met things like this in the past, I do see a couple of hacks:

1. Do not sync the digikam db, only the rest. That way all three machines would have their own database. Unison should be able to exclude that database

Yes, I could easily exclude the digikam database files from the synchronisation… but… then it would be necessary for digikam to scan for new images at start-up, which significantly slows things down; it would also mean that any changes to the database (on the source synchronisation machine) must be written to the image meta-data prior to the sync taking place. No, in this instance, I really want the database files to be synced.

3. Do it even more properly: Have a dedicated server, f.e. a Rpi with some external storage is fine for that.

I have been giving some quite serious thought to using some form of NAS for the “stuff” that I’m currently synchronising…

@all

Thanks for your ideas and input on this.

The general consensus re changing the UUIDs appears to be “don’t do it”. I need to give this more thought before I take any action, for the moment I’ll just continue as is and accept digikams “limitation” in this regard.

[hcvv]

@tannington

The general consensus re changing the UUIDs appears to be “don’t do it”. I need to give this more thought before I take any action, for the moment I’ll just continue as is and accept digikams “limitation” in this regard.

I would say that the risks are definitely lower with file systems other then the UUIDs of the root file system / and Swap. These two are certainly used in other places that just /etc/fstab.

[tannington]

@hcvv

I would say that the risks are definitely lower with file systems other then the UUIDs of the root file system / and Swap. These two are certainly used in other places that just /etc/fstab.

Actually, thinking back on this, and indeed I mentioned in passing in post #10, I have changed the UUIDs of /home in the past with no ill effect; albeit for a different reason, drive replacement.

I’m still thinking, although not a particularly elegant “solution”, it might be the way to go. Provided I make a note of the existing UUID, (or keep a backup of the old fstab) I could always change it back again if there were unexpected problems…

Still thinking :\ …

[malcolmlewis]

@tannington

Actually, thinking back on this, and indeed I mentioned in passing in post #10, I have changed the UUIDs of /home in the past with no ill effect; albeit for a different reason, drive replacement.

I’m still thinking, although not a particularly elegant “solution”, it might be the way to go. Provided I make a note of the existing UUID, (or keep a backup of the old fstab) I could always change it back again if there were unexpected problems…

Still thinking :\ …

Hi
Yes, no issue with in that respect as your adding a new drive/partition when and where the UUID is created… the real issue is the application… fix that…

[tannington]

@malcolmlewis

… the real issue is the application… fix that…

Can’t see that happening … even if I was able to submit a patch I very much doubt it would be accepted, and again, if I was able to, I won’t be forking digikam …

For the moment I’ll probably leave things and just accept this:

https://paste.opensuse.org/view/raw/6ac9ee90

It is after all only a mouse click to accept the new location … but it does rather irk me >:)

[karlmistelberger]

@tannington

Can’t see that happening … even if I was able to submit a patch I very much doubt it would be accepted, and again, if I was able to, I won’t be forking digikam …

For the moment I’ll probably leave things and just accept this:

https://paste.opensuse.org/view/raw/6ac9ee90

It is after all only a mouse click to accept the new location … but it does rather irk me >:)

I use digikam since 12 years with the same images on different drives with different uuids. When appropriate I click ok.

[tannington]

@karlmistelberger

… When appropriate I click ok.

Yes…

If it was just the occasional restoration of a backup from a different drive I wouldn’t mind. However I’ve need to keep three different machines in sync, which is done on a daily basis… All those mouse-clicks add up …