Create, Convert Disks to Persistent Device Names


By: variia

February 5, 2009 12:45 pm





Problem description

In traditional Linux, disk devices are recognized by the kernel at the boot process and accessed via a “virtual” block device file residing in the /dev directory. These were created as static devices during installation. For example:

/dev/sda – first SCSI hard drive or CDROM
/dev/hda – first IDE hard drive or CDROM
/dev/sdb – second SCSI hard drive or CDROM
and so forth.

It could become a problem when you move the disks around the BUS or just simply transfer the OS to a new hardware because there’s no guarantee that the hardware layout, driver, etc. will be the same and these static device names may refer to non existing hardware causing system boot failure.

udev for the rescue

To avoid such issues, kernel developers created udev software to manage these device descriptions dynamically.

Therefore in most Linux distributions including SLES the /dev directory is actually tmpfs, a temporary file system which gets created by udev every time the system boots.

Apart from the traditional device names udev creates persistent device names as well. These could be unique UUID numbers or strings generated from the combination of hard drive vendor’s name and serial numbers, etc. It makes “permanent” your device’s description on the kernel’s level.

The point is that if we refer to our devices by these persistent device names in our configurations there’s a very small chance that we run into problems if we change the hardware layout hence it has become the default for most Linux distributions nowadays including SLES10.

Create, convert to persistent device names

I have been upgrading my SLES10 installations since GA release, at that time the installer didn’t use persistent names in default so I had to convert my existing configurations.

Note: it’s quite common that fiber channel and iSCSI SAN LUNs still appear as /dev/sda,sdb,sdc… devices. When I add these to my configuration I use persistent device names also. NO need for doing this for EVMS or LVM2 volumes, they have kernel and userland components and dynamically managed by the dm-layer already.

I had the following disk arrangement:

sles10:~ # fdisk -l /dev/cciss/c0d0 

Disk /dev/cciss/c0d0: 73.3 GB, 73372631040 bytes 
255 heads, 32 sectors/track, 17562 cylinders 
Units = cylinders of 8160 * 512 = 4177920 bytes 

           Device Boot      Start         End      Blocks   Id  System 
/dev/cciss/c0d0p1               1       17562    71652928+   f  W95 Ext'd (LBA) 
/dev/cciss/c0d0p5               1         258     1052194+  82  Linux swap / Solaris 
/dev/cciss/c0d0p6             258        1288     4200966   83  Linux 
/dev/cciss/c0d0p7            1288        2513     4997984   83  Linux 
/dev/cciss/c0d0p8            2513        2758      999584   83  Linux 
/dev/cciss/c0d0p9            2758       17562    60402089   83  Linux

To find out your persistent device name for a certain partition:

sles10:~ # udevinfo -q symlink -n /dev/cciss/c0d0p1 
disk/by-id/cciss-3600508b1001035303620202020200003-part1 disk/by-path/pci-0000:06:00.0-cciss-0:40000000-part1

For this particular device there’s no UUID (usually there is) and I prefer always the disk “by-id” names. WARNING: the UUID changes when you format the file system hence not very ideal.

Now find out all of your new IDs for all of your partitions then replace the corresponding fstab entries. Keep the /dev/ bits and add the rest as udev returns, mine looks like this:

sles10:~ # vi /etc/fstab 
/dev/disk/by-id/cciss-3600508b1001035303620202020200003-part6    /                    ext3       acl,user_xattr        1 1 
/dev/disk/by-id/cciss-3600508b1001035303620202020200003-part8    /tmp                 ext3       acl,user_xattr        1 2 
/dev/disk/by-id/cciss-3600508b1001035303620202020200003-part7    /var                 ext3       acl,user_xattr        1 2 
/dev/disk/by-id/cciss-3600508b1001035303620202020200003-part5    swap                 swap       defaults              0 0 

You must replace all entries in your grub configuration as well:

sles10:~ # vi /boot/grub/menu.lst
	module	/boot/vmlinuz-	root=/dev/disk/by-id/cciss-3600508b1001035303620202020200003-part6	vga=0x317	resume=/dev/cciss/c0d0p5 splash=silent  showopts
	kernel	/boot/vmlinuz-	root=/dev/disk/by-id/cciss-3600508b1001035303620202020200003-part6 vga=0x317 resume=/dev/cciss/c0d0p5 splash=silent  showopts
	kernel	/boot/vmlinuz-	root=/dev/disk/by-id/cciss-3600508b1001035303620202020200003-part6 vga=normal showopts ide=nodma apm=off acpi=off noresume nosmp noapic maxcpus=0 edd=off 3

Make sure that every entry is typo free!!! If you made a mistake your system may fail to boot!

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Tags: ,
Categories: SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else in the SUSE Blog, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.


  1. By:kjhurni

    We had a situation where we upgraded the firmware for our Xiotech SAN. The result was that SCSI-3 specs were implemented which actually changed the uids and as a result, udev saw diff. id’s and so we couldn’t mount any disks without re-editing the grub files.

  2. By:variia


    Thanks for the heads up and your comment. It would be good to figure out if such a change affects “by-id” names. These usually use the vendor’s name and the serial number along with partition number so I guess it should be safe.


  3. By:fpernet

    but I’m not sure you don’t have to recreate the initrd if you want to be sure that you are using “purely” uuid names …

    Anyhow, good article and comment … thx

  4. By:razghe

    Links are not working anymore 🙂