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:
/etc/fstab
/boot/grub/menu.lst
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.
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…
> 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