In this short tutorial, you are going to learn how to change the UUID of a Linux partition. This can help you in a less likely to happen scenario when the UUID of two partitions are the same.
In reality, this is really hard to happen, but it is still possible, if for example you copy a partition using dd command.
What is UUID?
UUID stands for Universally Unique IDentifier of a partition. This ID is used in few different places to identify the partition. Most commonly this would be /etc/fstab.
How to Find UUID of Your Filesystems
To find the UUID of your partitions, you can use blkid command as shown.
# blkid|grep UUID
How to Change UUID of Your Filesystems
Changing UUID of a filesystem is fairly easy. To do this, we are going to use tune2fs. For the purpose of this tutorial, I will change the UUID on my second partition /dev/sdb1, yours may vary, thus make sure you are changing the UUID of the desired filesystem.
The partition has to be unmounted prior apply the new UUID:
# umount /dev/sdb1
# tune2fs -U random /dev/sdb1
# blkid | grep sdb1
The UUID has been successfully changed. Now you can mount the filesystem back again.
# mount /dev/sdb1
You can also update your /etc/fstab if needed, with the new UUID.
Conclusion
This was a short tutorial how to change a Linux partition UUID. The scenarios to use this are very rare and chances are that you will most probably use this on a local machine.
This isn’t about changing the partition UUID at all (PARTUUID in blkid output), but the *filesystem* UUID within the partition.
Exactly, I was searching for ways to change a PARTUUID, I already know how to change filesystem UUIDs.
So this page is totally misleading.
You should have mentioned that after changing a system UUID, updating the fstab file will not make you boot into that system. You will need to run a live cd boot repair tool, as the old UUID appears many times in boot/grub/grub.cfg file which cannot be edited.
It is not that straightforward as it may seem after reading this article.
I know this is an old thread, but Ravi is the only one who seems to understand the need for this procedure after trawling the internet for solutions to my issue.
I have recently purchased an M2 drive for my system and cloned my old SSD to it using Clonezilla. Obviously, this produces 2 drives with identical UUIDs.
I have found when testing new distros it is impossible to disable the NVME M2 drive in the bios or any other means except physical removal from the motherboard. That is pretty daft, in most bios, there are options to disable any SATA slot but not the M2 slots.
That means I cannot use my old SATA drive for testing new distros or rectifying issues with my system, I have to experiment using my new M2 NVME drive, not something I want to do.
So using tune2fs seems to offer a solution for my ext4 system, but although it changes the primary address, the secondary one (why the hell do they need 2?) stays the same.
Have you got a solution you can suggest for my issue? I know I am not the only one who needs a solution to the lack of control of the M2 NVME drives, the forums are full of questions about it with not a single practical solution offered anywhere.
Ravi’s idea is the most promising so far.
Tony Brown
I have found the answer to my problem and that of many others struggling with M2-type onboard drives.
See my post here: https://ubuntuforums.org/showthread.php?t=2462553&p=14039565#post14039565
it redirects you to the Ubuntu forums where I give a step-by-step on how to do this.
Cheers tony.
How to change the UUID of the root partition? You cannot unmount it normally. And if forcefully unmount it, things become unusable.
Have you tried booting from a Live CD/USB? Then you can treat the root partition on the hard drive as just another partition.
Typical of Linux advice, many times more wrong instructions and correct ones and NEVER corrected..
@michael,
I always correct articles based on the user suggestions, may I know what errors you have found in this article?
You have a typo.
I don’t believe you intended the second
/dev/sdb1nor the# blkidto appear on the same line.I’ve used this to reduce confusion after copying an image of a partition from an SSD to NVMe during an upgrade. Copying a partition with “dd” leaves two filesystems with the same UUID and this will reduce confusion.
How does having two partitions with the same UUID reduce confusion? How do you know which is the original and which is the copy? The idea is to have all unique UUIDs.
> tune2fs /dev/sdb1 -U random /dev/sdb1That’s not the correct syntax.
> tune2fs -U random /dev/sdb1First, even if you think all your readers will only be using ext2/3/4, you should at least mention that this only works for those filesystems.
Second, you’ve not said anything about *why* someone might want to *change* a UUID! I have never encountered a reason to do this, in real life (and the few instances that this may be needed are NOT for ext2/3/4 systems anyway!)
oops; ignore the second point in my comment
Mainly it happens after you clone a disk or partition with dd. You now have multiple filesystems with the same UUID.
For example, yesterday I copied the system partition to an SSD from an old spin disk. I wanted to preserve the spin disk for a couple of days in order to see SSD is working and all settings were preserved. I want to preserve data partition on the spin disk.
After the copy, the partition with GParted, both partitions, had dame UUID, so this tutorial was very helpful since grub was booting the incorrect partition.
You could also do this to make it easy to remember:
# tune2fs /dev/sda2 -U 12345678-abcd-1234-abcd-12ab34cd56efso, how to change uuid of root
(/)partition?I got a message “The UUID may only be changed when the filesystem is unmounted” when I typed the tune2fs command with parameters.
@Andy,
Follow the instructions given in the article to change the UUID of the root partition.
Sorry, Ravi, but the article does not mention ‘root‘ at all, unless you are referring to “You can also update your /etc/fstab if needed, with the new UUID.”. But to update the /fstab file one needs root privileges.
@Dragonmouth,
If you see clearly, you notice that I have used the root user in the article.