So I've been working on migrating my primary desktop from XP to Lubuntu (while keeping dual-boot ability). This has involved a number of partition migrations/copies/moves as I've sorted out what can be migrated directly to ext4 and what has to stay ntfs for now. I did the moves as gparted copies, expecting to keep the original as a backup copy... and discovered that gparted copies the UUID as well. From my searching it seems this is a common problem (example). On 2 of the copies I was able to change the UUID via gparted, but one fails without providing any useful info. I actually don't want to change the UUID of the XP system disk, nor it's backup copy, since MS has a nasty habit of tying the licensing to it. All of the labels on the original-now-backup copies have been changed to have "Bck" added at the end.

So my next thought was that I would just specify the device by it's UUID *and* it's PARTUUID... but I can't find any examples of fstab using multiple identifiers in specifying the device. Man and everything else I've found all say "this" OR "that" but not "this" AND "that". So, OK, I can use just the PARTUUID or the label...

But here's my question: if 2 devices have the same UUID, but different labels, do they both have to be identified by their labels? As opposed to one specified by the UUID and the other by the label? If the Bck copy is set to noauto by it's label first, can the working copy then be mounted by it's UUID? Also, the man pages say the PARTUUID is supported for GPT, but these are MBR disks, so can I still use the PARTUUID?

Just to clarify, what I want to do for the 4 "Bck" partitions is to put entries in fstab with noauto, to keep them from mounting by auto or accident. Once I'm sure things are working as expected then these Bck copies will be removed. For the working copy of the XP system disk, I want to mount it read only.

I think that there are about 4 unique ways to identify and they can be mixed depending on OS.


One of the gotcha's when making clones is that all unique data is copied. You'd therefor make them back to some generic naming before clone or fix after clone.

Maybe don't even put any entry for it in fstab to solve automounting.

Don't use UUID in fstab. Simple. initrd may be more of a problem, as well as grub.
If you have multiple filesystems with the same UUID you cannot guarantee which will be mounted/used.
PARTUUID is gpt specific - some linux tools (blkid for instance) appear to show PARTUUID on MBR, but it's a fudge; just diskid appended with partition number. Don't attempt to use it.

1 members found this post helpful.

I thought if there was nothing in fstab then it could still be mounted by the file manager, but if there was a noauto in fstab then the file manager wouldn't mount it. So then if you did want to mount it you'd need to do it specifically. Have I gotten that wrong?

Thanks for the info on partuuid, good to know. So it sounds like if the UUID isn't unique then I shouldn't use it at all for those disks. Which makes sense.

On the manage flags option (in gparted) there is a hidden. Is that anything I could use to keep Linux from mucking with those 4 Bck partitions? I mean, does it hide it from the OS or just from the user?


Edited 11/29/2016:

Note: if Gparted cannot change the UUID of an ntfs partition, make sure the partition hasn't been flagged for error checking. Especially given that gparted likes to flag the target drive in a copy as dirty. Once I ran chkdsk I was able to use gparted to change the UUID on the drive that I hadn't been able to change earlier.

However, while running chkdsk on all of the ntfs partitions I noticed that the the serial numbers on all of the clone source/target pairs were still identical, even though 2 of the pairs had had their UUID's changed, which I confirmed with blkid. So I'm not sure where the UUID is stored, but it seems to be a Linux-internal thing. Which makes syg00's comment, "initrd may be more of a problem, as well as grub." make a lot more sense. I hadn't understood the implications.

Of the 4 partitions that got cloned, 2 have changed considerably since the pre-migration backups and having mid-migration copies of them seems like a really good idea. So I am moving the copies to an old IDE drive I have, and removing them from the system. The other 2 partitions are static and haven't changed since the last backup - I was just keeping the copies because, well, they were there.

Oh, I did try setting one of the copies to "hidden" but it didn't seem to hide it the way I was hoping it would. When I checked the docs it sounds like the flag is more for supporting that option in some boot loaders. Presumably the boot loader then hides it from the OS in some fashion. But just setting the flag isn't enough.

So I don't know if I should flag this as solved, since the solution is basically "don't do that". Or do I just leave it unsolved so that future searchers don't come here thinking there IS a solution?

Thanks for the help guys!