Archive for May, 2009

Setting UUIDs on new partitions

Wednesday, May 13th, 2009 | linux, web | 2 Comments

If you take a look at /etc/fstab on a recent Linux installation, you may notice it’s using lines like

UUID=663f1349-3d37-4633-af59-849eda89bae4 / ext3 defaults 0  1

instead of the more traditional

/dev/sda1       /               ext3    defaults 0  1

These universally unique identifiers (UUIDs) can be generated by the uuidgen command and can reasonably be considered unique among all UUIDs created on the local system, and among UUIDs created on other systems in the past and in the future (from the uuidgen(1) man page).

Why would you want to use a UUID rather than the far more readable /dev/sda1 (well, readable if you’re somewhat comfortable with Linux anyway)? The problem with traditional device names (like /dev/sda1) is that they are assigned by the Linux kernel at boot-time and depend on the order in which devices are found. So /dev/sda is the name the Linux kernel assigns to the first SCSI or SATA hard drive it finds, /dev/sdb is the name used for the second SCSI or SATA hard drive and so on.

This works very well until the Linux kernel detects your devices in a different order to the usual. In practice, this is a relatively rare event but it is certainly possible when moving between kernel versions and if you make changes to your system hardware (such as adding in a second SATA controller). If your device order does change, all of a sudden, your root device which used to be known as /dev/sda1 becomes /dev/sdb1 or similar. Normally this will cause a kernel panic at boot time as your Linux system attempts to mount a filesystem which doesn’t exist or which doesn’t contain the expected filesystem.

One solution to this is the use of UUIDs. When you create a new filesystem, a UUID is generated and written to the filesystem’s superblock. The /etc/fstab then refers to this UUID which will remain constant regardless of what kernel you are running or how the drive is connected to your system (indeed, if you move the drive to an entirely different system, the UUID will still be valid).

If you only create partitions during the initial installation of your OS – you won’t have to deal with creating UUIDs for your partitions, the installer should take care of it automatically.

If you create any new partitions though, you will need to assign UUIDs to those partitions manually if you wish to refer to those partitions in your /etc/fstab by UUID (you can continue to use a mix of /dev/sda1 type entries and UUID based entries in /etc/fstab if you wish). To assign new UUIDs you need to

  1. Generate new UUIDs with uuidgen
  2. Write this uuid to your new partition (WARNING: Do not run these commands against an existing partition),
    for ext2, ext3 or ext4:
    sudo tune2fs -U f15f8aed-0073-4d2f-abec-aa5da4f72e8c /dev/sdc5

    for xfs:

    sudo xfs_admin -U f15f8aed-0073-4d2f-abec-aa5da4f72e8c /dev/sdc5

    for reiserfs:

    reiserfstune -u f15f8aed-0073-4d2f-abec-aa5da4f72e8c /dev/sdc5

Update: When you  create a new filesystem on a device, the command seems to allocate a uuid at that stage. To view existing uuids (in order to use them in your fstab and so on, run the blkid command).

Tags: , , , ,