This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: System Administration

What UUIDs can do for you

By David Pendell on September 11, 2008 (9:00:00 AM)

Share    Print    Comments   

If you've ever looked in your /etc/fstab file, you have may have seen an entry that looks like UUID=62fa5eac-3df4-448d-a576-916dd5b432f2 instead of a more familiar disk drive designation, such as /dev/hda1. Such entries are called universally unique identifiers (UUID). You can use these 128-bit numbers to make hard disk management easier.

Suppose that you have a system that contains two hard drives, traditionally known as /dev/hda and /dev/hdb. /dev/hda contains the root partition and swap, while /dev/hdb1 contains your home directory and encompasses the entire drive. Now say that you want to add another hard drive to the system, and some constraint forces you to add it between /dev/hda and /dev/hdb, thereby moving /dev/hdb to /dev/hdc. Anyone who has ever tried to do something resembling this knows the problem: the mount command checks /etc/fstab and tries to mount the new drive as /home. In this example, to fix the problem, you would have to log in in single-user mode as root and edit /etc/fstab before making the changes in the drive order active or the system would likely return an error when you tried to log in, or, worst case scenario for a root drive, throw a kernel panic. A situation such as this would be a nuisance, but if you consider a machine that has several hard drives containing such directories as /var, /opt, /home, /boot, /usr, and /usr/local, the problem becomes far more complex.

However, if the system administrator opts to use UUIDs, the problem is virtually nonexistent, because the /dev/sd* or /dev/hd* nomenclature almost goes away. Each hard drive is instead given a UUID, stored within the filesystem, and referenced by /etc/fstab, giving the sysadmin the freedom to put any device anywhere within the BIOS chain without affecting where the device is mounted within the Unix filesystem tree.

Under the old system, using JFS, a typical /etc/fstab entry would look something like this:

/dev/sda1 / jfs relatime,errors=remount-ro 0 1

Under the new system, the same entry would look something like this:

UUID=1c0653cd-e897-41af-bd30-55f3a195ff33 / jfs relatime,errors=remount-ro 0 1

The only thing different is the first entry in the table. Instead of /dev/sda1, the UUID 1c0653cd-e897-41af-bd30-55f3a195ff33 now designates the drive. Because of this, it wouldn't matter if the drive were /dev/sdi1; as long as the appropriate modifications to the bootloader config file were made, it would still mount as root and function as expected.

To get started using UUIDs, look at your /etc/fstab file. If there is a line similar to the above UUID example, then you are probably already using UUIDs to mount your drives. To find out for sure, run the command cat /proc/cmdline. If the response contains a UUID, then your system's bootloader passed the command to mount the root filesystem by a UUID, and you are in fact using them. Unfortunately, the mount command itself does not give such information yet -- at least the one on my system doesn't. It and the /etc/mtab file both show the hard drives using the /dev/[hs]d* system. Because of this limitation, consider keeping notes on where each drive and partition is mounted for your own use, though there are commands that show this information, as we'll see in a moment.

If you are not using UUIDs and you would like to, then I suggest that you dig out a hard drive that you can use for testing purposes; do not tinker with a live filesystem, as you may inadvertently damage your system. You also need to know how to relate BIOS drive positions to device nodes, and how to partition and create filesystems. If you do not know what I am talking about, then consult with someone more knowledgable or brush up with a tutorial.

Once you're ready to proceed, mount the hard drive in your system in such a way that it will not disrupt your existing hard drive nodes, then boot the computer and create a partitioning scheme and filesystem on the new drive. It does not matter what filesystem you use; all native Linux filesystems should support UUIDs. I have personally checked ReiserFS, ext2/3, JFS, and XFS, and each has support for UUIDs. FAT and NTFS, by the way, may not have good support for UUIDs; blkid shows a UUID for them, but Microsoft's technical references for NTFS and FAT don't even mention UUIDs. Now, in addition to the filesystem, create a mount point for the new drive. Once these tasks are complete, run the following command: sudo vol_id /dev/your_hard_drive. It should come back with output similiar to the following:

ID_FS_USAGE=filesystem ID_FS_TYPE=jfs ID_FS_VERSION= ID_FS_UUID=1c0653cd-e897-41af-bd30-55f3a195ff33 ID_FS_UUID_ENC=1c0653cd-e897-41af-bd30-55f3a195ff33 ID_FS_LABEL= ID_FS_LABEL_ENC= ID_FS_LABEL_SAFE=

The only information we are currently interested in is the ID_FS_UUID. If the vol_id command did not give you a UUID, then you must generate one and assign it to the drive. uuid is a command that generates UUIDs according to DCE 1.1 methods 1, 3, 4, and 5. Method 1, which is default, uses a combination of time from the system clock and the MAC address of an Ethernet card on your system. MAC addresses are supposed to be unique, but for some people they raise privacy or security concerns as they identify part of the machine they were generated on. Method 3 uses a name-based MD5 hash. Method 4 is random-number-based. Method 5 uses a name-based SHA-1 hash. Methods 3 and 5 require a namespace, such as a URL, in order to function. For most people, methods 1 and 4 suffice.

If you want to generate a random UUID without having to remember which method is random, then use the command uuidgen. It defaults to random, but has the option to generate a UUID based on time and MAC address.

Once you have a UUID, open /etc/fstab and copy that information to a new line. Use the lines already in /etc/fstab as an example, copying the filesystem options to the new line, in a format similar to this:

UUID=1c0653cd-e897-41af-bd30-55f3a195ff33 /your/mount/point file_system_type file_system_options

Make sure to include UUID= at the beginning of the line. Once you are finished, save your work and exit the text editor, and run a command like sudo mount -U /your/mount/point. If all was successful, the command should exit without error. Now run the mount command without parameters and see what the computer shows as being mounted. If your drive shows up in the list, then you were successful!

If you want to see what good your new UUID will do for you, shut down the computer, move the hard drive connection to a new location that will result in a new device node name, and reboot the computer. The new drive should mount in the same location without error.

More utilities

The commands reiserfstune -u UUID /dev/node, tune2fs -U UUID /dev/node, jfs_tune -U UUID /dev/node, and xfs_admin -U UUID /dev/node can all change the UUID on their respective filesystems. If you do this, take care to make sure that /etc/fstab and possibly your bootloader config file match the new UUID, lest you make the new filesystem unusable or, in the case of the root partition, make the system unbootable.

If you want to see the /dev/[hs]d* names along with the UUIDs, you can run sudo blkid. This command shows the devices connected to the system along with their respective UUIDs, and requires root access to work properly. Without root access, it won't error out, but it won't show any information either. Just to be clear: this is not a replacement for mount. It shows a device as long as it is connected to the system, mounted or not.

Finally, sudo findfs UUID=1c0653cd-e897-41af-bd30-55f3a195ff33 returns the device node for the device that matches that UUID. This is handy if you didn't record elsewhere the device node and UUID information in /etc/fstab.

All of this information on what UUIDs are and how to use them to manage your disks should make administrating your disks easier. Just remember to work carefully so that you don't end up with a big headache.

David Pendell has been working with computers for the last 23 years in a variety of capacities, including for programming and audio and video processing. He has been using Linux since Red Hat 5.1 and has used a variety of distros.

Share    Print    Comments   

Comments

on What UUIDs can do for you

Note: Comments are owned by the poster. We are not responsible for their content.

What UUIDs can do for you: break what used to work for me

Posted by: Anonymous [ip: 82.75.123.184] on September 11, 2008 10:01 AM
I've had problems with this, I used to just rsync machines from filesystem to filesystem (kinda like making an 'image'), but I couldn't with this anymore. These days you'll also have to change: /etc/fstab, /boot/grub/menu.lst and possible: /etc/udev/rules.d/70-persistent-net.rules (networkcard eth0 should stay eth0) after you do an rsync.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 202.146.71.121] on September 11, 2008 11:22 AM
isn't this what device labels are for?

#

What UUIDs can do for you

Posted by: Anonymous [ip: 217.8.211.28] on September 11, 2008 11:23 AM
Same here, complications with uuids outweigh my benefits, I then labelled all my partitions,
settling for /etc/fstab entries like

LABEL=HilbertHome /home reiserfs defaults,auto 0 2

my grub kernel line is:

kernel /boot/vmlinuz-2.6.24-2.6.24.4.slh.3-sidux-686 root=/dev/disk/by-label/HilbertRoottRoot ro apm=power-off nomce vga=0x317

and never had problems again.

#

What UUIDs can do for you

Posted by: Johannes Truschnigg on September 11, 2008 11:45 AM
The only thing I personally dislike about UUIDs and/or Filesystem Labels is the fact that you need to use an initrd (Initial Ramdisk) if you want to use those fancy descriptors for the kernel command line's root-parameter. That said, I wouldn't want to miss this very cool feature any more :)

#

What UUIDs can do for you

Posted by: Anonymous [ip: 84.40.234.119] on September 11, 2008 02:27 PM
Is it possible to specify UUIDs in drive declaration in /etc/crypttab ? I have an encrypted root partition.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 74.227.149.126] on September 11, 2008 02:32 PM
Personally Ive found uuids to create all kinds of annoyances from being unable to recognise partitions to leaving a system completely unbootable. In my case I run multiboot systems so that may have something to do with it. I also would like to say that uuids are the main reason I dont use debian or debian based distros.

#

Re: What UUIDs can do for you

Posted by: Anonymous [ip: 157.203.42.50] on September 11, 2008 03:41 PM
"I also would like to say that uuids are the main reason I dont use debian or debian based distros."
This seems a bit extreme when you can easily change to using labels or devices.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 80.254.84.83] on September 11, 2008 02:57 PM
I used to get bitten by the fact that formatting a disk changes the UUID...Never used them again, then.

#

Re: What UUIDs can do for you

Posted by: Anonymous [ip: 12.226.91.188] on September 11, 2008 11:20 PM
Exactly...The UUID needs to be based on something (like the drive serial #?) so that no matter what is done to the drive, the UUID is ALWAYS the same! I have a multi-boot system set up here, and occasionally I will try a new Linux Distro that sounds interesting. Each time, the UUID for the partition the new distro is on is different, so that when I boot into one of the other distros I have installed, the partition with the new distro is not recognized until I change it in the Fstab file in all the other distros. BIG pain in the ASS.

Personally, I only use Debian based distros...change the UUID in Fstab once to /dev/(sd??, or hd?? depending on the actual drive # and partition on the drive) No further problems.

#

UUIDs and SWAP

Posted by: Anonymous [ip: 74.220.13.196] on September 11, 2008 03:46 PM
When you install a new OS it will reformat the swap space(s) and give them new UUIDs. Once done the old OS no longer has swap space because it refers to an obsolete UUID!
After debugging this I stopped letting installs use UUID in /etc/fstab

#

What UUIDs can do for you

Posted by: Anonymous [ip: 192.168.0.11] on September 11, 2008 04:51 PM
UUID sucks. What happens when you format those partitions? How is UUID easy on me?

Use labels or LVM. THAT is easy.

Bye.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 207.140.140.193] on September 11, 2008 08:49 PM
I never had this on other Unix systems. What would be the best solution is to make sure that the disk install process does not change existing device designations, unless If it is smart enough to do hdb when you add drive #2, it should be able to make drive #3 hdc ( or hdd, given that you have to make a cd or dvd work too ).

#

What UUIDs can do for you

Posted by: Anonymous [ip: 192.55.20.36] on September 11, 2008 09:34 PM
I have many external drives that I used whenever I need to, so is it possible to use this UUID and have each drive with a persistent naming scheme; for example drive A would be always /dev/sdc1 and drive B always /dev/sdd1. If so does it work also with autofs?

Thanks

#

Re: What UUIDs can do for you

Posted by: Anonymous [ip: 93.197.52.207] on September 12, 2008 02:02 AM
I use UUIDs to mount my external drives on fixed mountpoints, for instance /media/mp3 for my mp3 player and /media/backup for the drive I use for backups, and this is quite sufficient for my purposes. I don't know however whether persistent device labels are possible.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 10.0.1.38] on September 11, 2008 09:50 PM
Like others, I much prefer using human-readable labels to refer to disks. I mean, UUIDs might be useful internally, but why would you ever want to deal with them as a user, if alternatives exist? Do they have *any* advantages over labels?

#

Re: What UUIDs can do for you

Posted by: Anonymous [ip: 70.74.221.102] on September 12, 2008 12:20 AM
Security. e.g. just one example: say someone plugs in an external hdd with some malicious programs owned by root with SUID bit set and its mounted by the fstab without a NOSUID option.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 192.168.0.8] on September 12, 2008 06:57 AM
Isn't it just easier to use sda sdb as always. I get into more trouble with UUID's
Adiitionally the support program

#

Re: What UUIDs can do for you

Posted by: Anonymous [ip: 70.74.221.102] on September 13, 2008 05:51 AM
re: Isn't it just easier to use sda sdb as always. I get into more trouble with UUID's
Well that's assuming that they won't change. Say those drives are on two separate controllers e.g. a sata, and a scsi drive. Now you add a PATA drive - your sd{} labelling may change possibly resulting in a unbootable system until you get a boot disk and manually update the fstab.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 86.15.169.110] on September 12, 2008 09:27 AM
So going from

UUID=/dev/sda1 / jfs relatime,errors=remount-ro 0 1

to

UUID=1c0653cd-e897-41af-bd30-55f3a195ff33 / jfs relatime,errors=remount-ro 0 1

is supposed to be better?

I think I'll stick with the old way. This is a case of people with nothing better to do, so they implement a pointless and fr more complicated
solution/idea to a problem that does'nt exist. A bit like the team that was going to use xml messaging to replace X messages on the
network ;)




#

What UUIDs can do for you

Posted by: Anonymous [ip: 71.131.181.8] on September 13, 2008 05:08 AM
Based on the number of complaints about this concept, I'd say the article should be renamed "What UUIDs Can Do TO You"...:-)

#

What UUIDs can do for you

Posted by: Anonymous [ip: 212.214.78.162] on September 13, 2008 08:16 AM
This is really helpful if you, like me, have lots of USB-devices. Before I'd use semothing like:

dmesg | tail
mount /dev/sdxn /mnt/xxx -t xx -o xxx

Now I simply use:
mount /mnt/external, mount /mnt/ipod, mount /mnt/xdcard... and so on.

I don't use it on my root and swap devices, though. As people have said earlier, that can lead to problems.

#

What UUIDs can do for you

Posted by: Anonymous [ip: 84.202.157.247] on September 14, 2008 11:07 AM
UUIDs creates huge mess and extra work.
I quite often need to install new versions of OpenSUSE, Fedora and Ubuntu to test our software. So I have 5 - 6 LInux-partitions to keep track of. Each time I install a new distro it re-formats the partition and formating creates a new UUID. It can be very annoying because I have to manually change /etc/fstab in every Linux-distro. I want to access every partition though /etc/fstab. So it's much better to use /dev/sdXX name instead of volatile UUID. /dev/sdXX name practically never changes.

#

Well guess is can....

Posted by: Anonymous [ip: 82.182.32.28] on September 14, 2008 09:26 PM
I think this article fell short on describing how and why this is a feature for today's systems, I personally believe it fixes an ancient problem in the Linux management.
I believe this feature is best descibed for SCSI subsystems and such. If you have SAN or SCSI attached disks and have to rescan the chain, the disks can change place so sdb is moved to another id. And that can be a bit of a problem.
A case study.
I built a XEN Enterprise pool using SAN as shared storage. XEN uses LVM volumes for managing virtual host storage and to make sure a attached storage LUN did not get reconfigured it was presented to XEN using UUID.
In case you have 3 disks (sda, sdb, sdc) mounted as /dev/sda1 /mnt/disk1, /dev/sdb1 /mnt/disk2, /dev/sdc1 /mnt/disk3 and detach sdb and make a scsi rescan. Your disks will be shown as /dev/sda and /dev/sdb. This means that the disk you previously had mounted as /mnt/disk3 now is mounted as/mnt/disk2 and if unlucky you can trash what you are running on that system.
An even worse case would be if you have a whole bunch of disks in an storage (for backup or whatever) and the disks gets reorganized because of a rescan.
By mounting the disks by its UUID you make sure the right disk still is mounted on the expected place, even after a system re-configure.
In the XEN case it makes it possible for XEN to _not_ loose all of its configuration as you increase/decrease your storage.
And if unsure, you can look at to which device the UUID is soft linked by issuing:
$ cd /dev/disk/by-uuid/
$ ls -l
lrwxrwxrwx 1 root root 10 2008-09-14 20:24 68f57034-51ae-11dd-882c-63be9b0f4c9d -> ../../sda8
$ grep "68f57034-51ae-11dd-882c-63be9b0f4c9d" /etc/fstab
UUID=68f57034-51ae-11dd-882c-63be9b0f4c9d /home ext3 noatime 1 2

Or you can label the disks yourself and find them in:
$ ls -l /dev/disk/by-label/

#

What UUIDs can do for you

Posted by: Anonymous [ip: 86.15.169.110] on September 15, 2008 09:35 PM
Explanation by (Anonymous [ip: 82.182.32.28]) very good. Still think for normal desktop (1-2 fixed disks) old way better, but for servers with multi-disks and scsi makes sense.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya