Mounting file-systems by label rather than device name 

http://www.debian-administration.org/articles/522#comment_15

by Steve on 1 May 2007

*Tags*: filesystems, grub, blkid obtian list disk by uuid,

When you're dealing with multiple drives, both fixed and removable, it can get hard to remember which is which. Remembering to mount /dev/sda1 in one place and /dev/sdc5 in another. The solution to this problem is to use labels instead of partition names when referring to them, and here we'll show how that can be done.

There are two things you need to do to start using labels:

To add a label you must use the tune2fs command, specifying the partition to modify and the label to add.

Upon my home system I have only a single disk /dev/sda which has three partitions:

   Name        Flags           Size (MB)
-------------------------------------------
   sda1        Linux ext3       20003.89
   sda2        swap              3002.23
   sda3        Linux LVM       297064.22

To add the label "root" to my root partition, /dev/sda1, I'd run:

root@mine:~# tune2fs -Lroot /dev/sda1

Once I've got a label in place it becomes visible in my partition list when I run "cfdisk /dev/sda", so I know it has worked.

Once the label has been put into place there are now two places which I need to update the system in order to use it:

In both cases the change is the same, instead of specifying /dev/sda1 I specify LABEL=root.

My /etc/fstab file now looks like this:

#
# /etc/fstab - static file system information.
#
LABEL=root      /        ext3    defaults,errors=remount-ro 0       1
/dev/sda2       none     swap    sw                         0       0
...
...

The grub configuration file was updated to change:

# kopt=root=/dev/sda1 ro acpi=off noapic

into this:

# kopt=root=LABEL=root ro acpi=off noapic

Once this was done the kernel(s) can be updated by running update-grub. This updated my Xen kernels and my Debian kernels to include the new root - for example:

title           Xen 3.0.3-1-amd64 / Debian GNU/Linux, kernel 2.6.18-4-xen-amd64
root            (hd0,0)
kernel          /boot/xen-3.0.3-1-amd64.gz
module          /boot/vmlinuz-2.6.18-4-xen-amd64 root=LABEL=root ro acpi=off noapic console=tty0
module          /boot/initrd.img-2.6.18-4-xen-amd64
savedefault

The advantage of doing this is that I can now use identical configuration files upon each of my hosts, and rely upon the labels to make sure the correct partition is used as my root filesystem. This is very useful when you're configuring your systems via CFEngine, or similar.

Mounting file-systems by label rather than device name 

 

By mounting using labels, does it mean that if I were to move the partitions around, for e.g. move my root partition from /dev/hda6 to /dev/hda7 without making changes to GRUB or /etc/fstab, that my Linux will start up without any problems?

 
 -- ramsamba

Label disk/partitions are nice, but it's kinda dangerous when you move your disk from one machine to another, specially with common names for partitions such as 'root', 'usr', 'var', etc…

Mounting file-systems by label rather than device name 

 
> Label disk/partitions are nice, but it's kinda dangerous...

Yes.

In addition to that, it can be a security problem, i.e. people can intentionally label their partitions in a way that would create name clashes with vital partitions.

I don't know what bad could be done with that, but I suppose that, for example, a USB disk labelled "root", "var", etc., could be used to gain access to a system: even if booting from a USB disk is disabled, having the device plugged at boot time may allow the partition to be mounted instead of the expected one (root partition, /var, etc.).

 
 -- davux

You could use UUIDs instead (which can be gathered by running /sbin/blkid).

The only problem I've found is with Linux RAID1 devices - you have to specify /dev/md0 or whatever, otherwise the boot process may try to mount one of the mirrors first (/dev/sda1 for example) and then when the raid tries to assemble, it fails, halting the boot process.

by Anonymous (72.66.xx.xx) on Mon 7 May 2007

documented on: 2007.07.29