Hot answers tagged

167

To add variety without adding external dependencies, on Linux you can do: UUID=$(cat /proc/sys/kernel/random/uuid) To propagate bad practices, on FreeBSD, under the linux compatibility layer (linuxulator?), UUID=$(cat /compat/linux/proc/sys/kernel/random/uuid) References: UUID on Wikipedia. FreeBSD Bug #186187 - [linprocfs] [patch] emulate /proc/sys/...


20

If you do not want to depend on other executables, or you cannot use them, here is the pure bash version from here: # Generate a pseudo UUID uuid() { local N B T for (( N=0; N < 16; ++N )) do B=$(( $RANDOM%255 )) if (( N == 6 )) then printf '4%x' $(( B%15 )) elif (( N == 8 )) then ...


19

I have found this script "one-liner" useful where uuidgen is not available. This also bypasses any neccessity to install external modules for Perl or Python. od -x /dev/urandom | head -1 | awk '{OFS="-"; print $2$3,$4,$5,$6,$7$8$9}' Tested on SnowLeopard, Red Hat Valhalla, Solaris 9 4/04 and newer successfully. I am curious if this is prone to non-...


18

If you want to mount the lv's from a clone disk, I found this useful method here http://www.linuxquestions.org/questions/linux-hardware-18/unable-to-change-uuid-of-cloned-drive-device-left-open-4175470893/ vgimportclone -n orignalvgname_clone /dev/sdx [/dev/sdy....] sdx,sdy.. are the cloned disks which make up the vg. vgchange -ay orignalvgname_clone ...


9

What you're after is findmnt. For example: $ findmnt -rn -S UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -o TARGET /mnt/mountpoint or $ findmnt -rn -S PARTUUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -o TARGET /mnt/mountpoint If nothing is mounted matching that UUID, nothing is output and the return code is 1 (failure), otherwise, the mountpoint is output and ...


6

Every time cryptsetup recreates the encrypted swap partition at boot time it generates a new UUID for it! Doh! In /etc/crypttab, use /dev/disk/by-id instead of /dev/disk/by-UUID to refer to your swap partition. For example, your /etc/fstab entry for swap might be #<file system> <mount point> <type> <options> <dump> <pass&...


6

Every filesystem has a UUID, which is stored as part of the partition table on the disk itself, so is "portable" with the disk. Upgrading your OS should only change the UUID of a partition if that partition was formatted.


6

This is possible by adding the parameter as follows to /etc/default/grub. $ echo "GRUB_DISABLE_LINUX_UUID=true" >> /etc/default/grub $ grub2-mkconfig -o /boot/grub2/grub.cfg If you want to double check the result before. $ grub2-mkconfig | less Update To completely disable the UUID in GRUB, you need to add the line as follows to /etc/sysconfig/...


5

Both the label and the UUID are part of the file system, not the partition or something inherent to the disk. The question I linked to and that you deemed not helpful, explained that the UUID is stored in the superblock, which is a part of the file system and fully contained within the partition. So, if you do a dd if=/dev/sda1 of=/dev/sdb1, both sda1 ...


5

The most clean and troublefree solution would be to create a new machine and attach the disks. However, if you want to edit the configuration, there are three UUIDs in a machine's settings. You can delete uuid.location and uuid.bios from .vmx configuration file, for example with the following commands: sed -i '/uuid.location/d' ./*.vmx sed -i '//d' ./*....


4

You won't be able to find this information from within the VM. Are you trying to do this programmatically? If you can deal with a couple of manual steps, you can look at the virtual machine's logs in vSphere under Tasks and Events to see the VM's history. You may also be able to look at the source templates' histories and glean the same information.


4

That's correct. Mounting by UUID is one way to work around the old issue of partition names like /dev/sda1 changing if you put another drive in. device-mapper will persistently name your LVM volumes into /dev/mapper/vg-lv so you can rely on this abstracted name to stay the same, regardless of changes to the underlying storage. The same goes for devices ...


4

A EBS snapshot is a exact block-by-block copy of the original content at the time the snapshot is taken. In other words, the filesystem UUID will remain the same.


3

What you're wanting to do is not really what the fsid is intended for. The fsid is meant to help uniquely identify filesystems which may not have their own unique identifiers, such as clustered filesystems. Among other things, this helps eliminate hung systems due to stale NFS mounts by letting you repair and re-export a failed filesystem from a different ...


3

The answer by trekkerboy / modonnell @ linuxquestions is most straightforward, use vgimportclone. Note also that after you create the clone, you have to activate it with vgchange -a y newvgname, and you have to clean up oldvgname's device nodes with dmsetup remove /dev/oldvgname/*. For reference, what follows is a more manual method, which apparently ...


3

apt-get install uuid Worked for me, then i did run uuid


2

To find the actual device from the UUID, blkid may be better than your readlink solution, which relies on udev. myuuid="7DCD-9380" mydev=$(blkid -l -o device -t UUID="$myuuid") To get the mount point for this device, you can use this: grep $mydev /proc/mounts | cut -d' ' -f 2 or df -P | grep $mydev | awk '{print $6}' The latter is more portable, ...


2

something like this one liner will run 'hdparm -W 0' on all devices that are used for md raid. blkid | awk -F: '/linux_raid_member/ {print $1}' | xargs -r -n 1 hdparm -W 0 if you use partitions rather than whole disks for raid then you'll need to strip off the partition numbers from the device names (and unique sort them so you don't e.g. get sda three ...


2

You've tried to use hdparm on the by-uuid device file corresponding to your RAID array (md0). Instead, try running it on the ones corresponding to the physical disks.


2

According to its man page, the command vgimportclone will do the work for you: vgimportclone /physical/volume/path This is used for importing a volume group (VG) from a cloned physical volume (PV), e.g. after a snapshot or other duplicated PV.


2

You'd only ever shoot yourself in the foot if you wanted to rename the volume group or logical volume later....(lvrename or vgrename). Forgetting whatever reason you renamed the vg or lv, the action would screw up your mounts and exports. LVUUID remains persistent through vg and lv rename commands. It may be good to use UUID for this reason alone, ...


2

After the fact, you may have difficulty identifying the source template from within the VM unless you add some file to the template that identifies its source. If you don't have access to relevant vSphere logs, you may be out of luck.


2

A filesystem's UUID is generated by mkfs, so a reformat will change the UUID. One option is to create a label when you make the filesystem and look in /dev/disk/by-label rather than /dev/disk/by-uuid. An advantage of using a label is that you can re-label a filesystem after the fact if you need to. A disadvantage is that you are now responsible for ...


2

For /boot you should be able to label the filesystem and then refer to it by label. Indeed, by default RHEL already labels /boot as /boot. e2label /dev/disk/by-uuid/**** /boot will change the disk's label to /boot. You can then refer to it in /etc/fstab: LABEL=/boot /boot ext3 rw,relatime 0 2 LVM volumes should just be ...


2

You can find this information from the ESXi host directly by examining the serverIp parameter in /etc/vmware/vpxa/vpxa.cfg. grep serverIp /etc/vmware/vpxa/vpxa.cfg This should also be available via API.


2

Yes, you can use UUID's with Linux software raid. But rather than using the UUID of the filesystem (which can show up as non-unique in case of software raid mirroring) you should use the UUID of the RAID device in your /etc/fstab as that will be unique for sure. mdadm --detail /dev/md0 will display the UUID of the /dev/md0 block device. I think blkid ...


1

If there is no specific reason for exclusively using UUID, you might consider alternatives like using /dev/disk/by-partuuid. It relies on information stored in the GPT rather than in the partition itself, so the identifier should remain fixed when you only reformat the partition. /dev/disk/by-id might also be interesting, it uses the hardware serial number. ...


1

UUID's (which you can see by running blkid) are assigned to a filesystem when you create it (e.g. when you run mkfs.ext4 or mkswap). Mounting by UUID is appropriate for what you want to do.


1

The UUID of a partition is stored in the "header" of the filesystem structure - as in it is inside the partition data, not in the MBR or any other partitioning scheme. Long story short, it won't change unless you manually change it or reformat the whole partition. The /dev/disk/by-id/ structure is, by definition, dependent on what ID the kernel gives to the ...


1

Per Gabor Vincze, the script from Ubuntu forums seems to do a decent code: #!/bin/bash # This script will change all entries of the form /dev/sd* in /etc/fstab to their appropriate UUID names # You must have root privelages to run this script (use sudo) if [ `id -u` -ne 0 ]; then # Checks to see if script is run ...


Only top voted, non community-wiki answers of a minimum length are eligible