I have a fedora guest OS in VMware. I want to expand /boot partition, so I add another virtual disk to this VM, and try to clone the disk.
After dd if=/dev/sda1 of=/dev/sdb1, blkid report that /dev/sda1 and /dev/sdb1 have same UUID/GUID.
It’s weird that there’re 2 same UUIDs in the universe, how to change one of them to another UUID value?
Update 2017-01-25
Subject changed, UUID here means filesystem UUID, not partition UUID.
Since it’s filesystem UUID, filesystem specific utils are needed to change the UUID, or use hexeditor to modify raw data on disk (DANGEROUS, not recommended unless you know what you are doing).
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
To generate a random new UUID, one can use:
$ uuidgen
To actually change the UUID is file system dependent.
Assuming ext-family filesystem
# tune2fs -U <output of uuidgen> /dev/sdb1
Or if you’re confident uuidgen is going to work:
# tune2fs -U $(uuidgen) /dev/sdb1
Assuming btrfs filesystem
# btrfstune -U $(uuidgen) /dev/sdb1
The UUID is stored in the superblock, so a byte-for-byte copy of the filesystem will have the same UUID.
Method 2
Use:
tune2fs -U random /dev/sdb1
if it’s an ext filesystem, or
xfs_admin -U generate /dev/sdb1
if it’s an xfs filesystem.
The reason the second partition has the same UUID is because dd just copies data from one file to another (dd if=/dev/sda1 of=/dev/sdb1 = cat /dev/sda1 > /dev/sdb1); dd doesn’t know what a partition is, or how to generate a UUID, so it just copied all the data as-is, including the UUID, which is stored in the filysystem superblock near the start of the partition.
By the way,
I also think UUID (Universally Unique IDentifier) is a weird name. It should be called PGUID (Possibly Globally Unique IDentifier), or even better, just ARLN (A Reasonably Large Number).
Method 3
Besides of ext2 /ext3 / ex4 and xfs, you can also change UUID of the following filesystem or block device or PARTUUID of GPT partition.
Swap
swaplabel -U $NEW_UUID
Software RAID (md raid)
For MD RAID, you must stop the RAID first, then update the UUID when re-assembling. So if your RAID is mounted to /, you can’t stop it, you need update UUID in offline mode — use a live CD/USB to do it.
mdadm --stop $RAID_DEVICEmdadm --assemble $RAID_DEVICE --update=uuid --uuid=$NEW_UUID $MEMBER_DEVICES...
Example:
mdadm --stop /dev/md127mdadm --assemble /dev/md127 --update=uuid --uuid=2A1D2A1D-2A1D-2A1D-2A1D-2A1D2A1D2A1D /dev/sda2 /dev/sdb2
After UUID been updated, you may need to update grub.cfg (rd.md.uuid=$NEW_UUID in linux/linuxefi/linux16 command line) and/or fstab and/or mdadm.conf and/or update-initramfs (Debian family) and/or dracut --force (Red Hat family) so that you can boot successfully next time.
LUKS (cryptsetup)
cryptsetup luksUUID --uuid=$NEW_UUID $LUKS_DEVICE
Example:
cryptsetup luksUUID --uuid=e0c0e0c0-e0c0-e0c0-e0c0-e0c0e0c0e0c0 ~/encrypted-LUKS.loop
NTFS file system
There’s ntfslabel utility (thanks to ntfs-3g) to change UUID of NTFS file system. See abchk1234’s answer.
In case you wanna change the whole UUID of NTFS file system instead of --new-half-serial, use the --new-serial option.
Example:
ntfslabel --new-serial=1122334455667788 /dev/sda3
FAT / exFAT file system
This is another story here, currently there’re no utilities to modify the filesystem UUID of these filesystems (See reichhart’s answer — the mlabel tool), but we can modify raw data on disk to do this.
WARNING, it’s dangerous to modify raw data on disk, and could lost data without careful operation.
Here’s detail steps to modify raw data on disk using hexedit.
-
blkid, write down the UUID of filesystem to paper, or remember it. The UUID string of FAT / exFAT looks like1122-3344, UUID string of NTFS looks like1122334455667788. -
Open partition device using hexedit
hexedit <partition device such as /dev/sda1> -
Press /, enter the UUID in reverse order (if
blkidreported1234-ABCD, then searchCDAB3412) to search the UUID data on disk. - Once UUID is located, change them, press F2 to save and exit.
-
blkidto verify the UUID. -
Once UUID is modified, you may need to update
grub.cfgand/orfstabso that you can boot successfully next time. -
Execute
fsck <partition device such as /dev/sda1>and see a “There are differences between boot sector and its backup” message. In order to solve it, select “1) Copy original to backup”, and if you are asked “Perform changes ? (y/n)” you press y.
PARTUUID of GPT partition
A short story: I never thought I will need to touch PARTUUID of GPT partition, until now, when I try to migrate Windows from a small disk to a large disk, Windows failed to boot on the large disk and it can’t even be repaired automatically. The reason is that changing UUID of NTFS file system to the original one isn’t enough for Windows + UEFI, you also need to change the PARTUUID of GPT partition – PARTUUID matter. (After changed PARTUUID to the original one, Windows successfully booted from the large disk.)
There’s already an answer here on askubuntu.com to show how to change PARTUUID of GPT partition using gdisk utility.
The current version of fdisk (2.35.2 in Fedora 32 repositories at the time of editing) from util-linux can do that too in expert mode, in fact, starting from util-linux v2.23, fdisk has been GPT-enabled.
Here’s an example of changing PARTUUID using util-linux fdisk utility:
# truncate -s 200M /tmp/file-as-a.disk
# LANG=en_US.UTF-8 fdisk /tmp/file-as-a.disk
Welcome to fdisk (util-linux 2.35.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xc0fc8503.
Command (m for help): g
Created a new GPT disklabel (GUID: 4CD23B97-80C5-BD42-8466-1B9476653A92).
Command (m for help): n
Partition number (1-128, default 1):
First sector (2048-409566, default 2048):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-409566, default 409566):
Created a new partition 1 of type 'Linux filesystem' and of size 199 MiB.
Command (m for help): i
Selected partition 1
Device: /tmp/file-as-a.disk1
Start: 2048
End: 409566
Sectors: 407519
Size: 199M
Type: Linux filesystem
Type-UUID: 0FC63DAF-8483-4772-8E79-3D69D8477DE4
UUID: 7265D7C3-6277-DE4B-956C-41E3BFFF8E0D
Command (m for help): w
The partition table has been altered.
Syncing disks.
# LANG=en_US.UTF-8 fdisk /tmp/file-as-a.disk
Welcome to fdisk (util-linux 2.35.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): x
Expert command (m for help): m
Help (expert commands):
GPT
i change disk GUID
n change partition name
u change partition UUID
l change table length
M enter protective/hybrid MBR
A toggle the legacy BIOS bootable flag
B toggle the no block IO protocol flag
R toggle the required partition flag
S toggle the GUID specific bits
Generic
p print the partition table
v verify the partition table
d print the raw data of the first sector from the device
D print the raw data of the disklabel from the device
f fix partitions order
m print this menu
Save & Exit
q quit without saving changes
r return to main menu
Expert command (m for help): u
Selected partition 1
New UUID (in 8-4-4-4-12 format): 11223344-5566-7788-9900-AABBCCDDEEFF
Partition UUID changed from 7265D7C3-6277-DE4B-956C-41E3BFFF8E0D to 11223344-5566-7788-9900-AABBCCDDEEFF.
Expert command (m for help): w
w: unknown command
Expert command (m for help): r
Command (m for help): w
The partition table has been altered.
Syncing disks.
# losetup --partscan /dev/loop101 /tmp/file-as-a.disk
# blkid /dev/loop101*
/dev/loop101: PTUUID="4cd23b97-80c5-bd42-8466-1b9476653a92" PTTYPE="gpt"
/dev/loop101p1: PARTUUID="11223344-5566-7788-9900-aabbccddeeff"
Method 4
For XFS, use: xfs_admin -U <uuid> <device>
Use xfs_admin -u <device> to view a UUID (note lower case option to view, versus upper case option to set). Another post on U&L pointed out the blkid command for viewing all or some of the UUIDs on the system.
Method 5
Partial Answer for VFAT
For ext* and xfs file systems there are already fine answers.
But for VFAT I strongly recommend to use mlabel of the mtools package. Using hex editors is DANGEROUS.
Use something like this to create a new UUID:
echo 'drive d: file="/dev/sdb3" exclusive' >>/etc/mtools.conf mlabel -n d:
Method 6
BTRFS
sudo btrfstune -u /dev/sdaX sudo btrfstune -U 0de6bd81-7013-49a8-bdc5-d832ed209d2c /dev/sdaX
Running btrfsck is recommended because changing UUID in BTRFS is not an atomic operation.
Method 7
To change the dd command resulting duplicated disk partion UUID/s – Use GParted.
From the GParted user interface, select drive,
select partition, unmount partition. From the ‘Partition folder’ choose ‘NEW UUID’, repeat until all dd drive duplicated partition uuid/s are marked for replacement. For bootable disks, do not replace the UEFI partition uuid.
Review the selected drive letter and partition/s – All OK ? …
Click the ‘Apply All Operations’ icon on the GParted user interface.
For bootable disks, edit the /etc/fstab file UUID=string/s and mount point/s.:
Method 8
For NTFS check this thread for details.
Summary:
sudo ntfslabel --new-half-serial /dev/sdXN
Method 9
Under Fedora 27 I found that the order of the arguments plays a crucial role … You have to write the device first, otherwise the UUID is not changed. For example
tune2fs /dev/sdb1 -U random
Method 10
exFAT
If you are fine just changing the volume label, just use exfatlabel /dev/sda1 newlabel.
However, I didn’t found a tool to easily set the UUID/VolumeSerialNumber of exFAT to a specific value and LiuYan’s answer didn’t work for me as it keeps you left with a wrong boot sector checksum.
Using the exFAT spec I figured out the proper way to change the UUID. Here the result in pure bashism
# set exFAT UUID to aabb-ccdd
$ dd if=/dev/sda1 of=fshead bs=512 count=24
# best keep a backup if something goes wrong
$ cp fshead fshead.bak
# set UUID in main boot sector (in reversed order (little endian))
$ echo "000064: ddccbbaa" | xxd -r - fshead
# set UUID in backup boot sector
$ echo "001864: ddccbbaa" | xxd -r - fshead
# run fsck to get the checksum
$ fsck.exfat fshead
exfatfsck 1.2.5
ERROR: invalid VBR checksum 0x276e3c6f (expected 0x2771966f).
# fix the checksum (again in reversed order (little endian))
$ python -c "print('1600: '+'6f967127 '*64)" | xxd -r -c 256 - fshead
$ python -c "print('1700: '+'6f967127 '*64)" | xxd -r -c 256 - fshead
$ python -c "print('2e00: '+'6f967127 '*64)" | xxd -r -c 256 - fshead
$ python -c "print('2f00: '+'6f967127 '*64)" | xxd -r -c 256 - fshead
# check checksum (then cancel with CTRL-C)
$ fsck.exfat fshead
exfatfsck 1.2.5
WARN: file system is larger than underlying device: 256087425024 > 12288.
^C
# checksum is ok, so lets flash it back
dd if=fshead of=/dev/sda1 bs=512 count=24
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0