LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   How I manage disk device naming (https://www.linuxquestions.org/questions/linux-newbie-8/how-i-manage-disk-device-naming-4175442112/)

kankan55 12-19-2012 03:31 AM

How I manage disk device naming
 
Hi All,

In Redhat 6.3 ,installer sees /dev/sda, but after boot it's /dev/sdb
The /dev/sda is from san storage instead.

How do I order the local disk to be detected as /dev/sda sdb first ... then san storage after all local disk are naming.

PS. My kickstart installation only install on sda. My pxeboot initrd is clean of FC driver. So the local disk only detect as sda.

Regards,
Kan

malekmustaq 12-19-2012 05:44 AM

Quote:

In Redhat 6.3 ,installer sees /dev/sda, but after boot ...
By which means the system booted, PXE? or HDD local?
Quote:


How do I order the local disk to be detected as /dev/sda sdb first ... then san storage after all local disk are naming.

You can control a persistent naming by way of matching hard drive or any block media (attributes) to strings of your choice. Udev rule writing is very easy, a short read here will pay much advantage.

David the H. 12-19-2012 05:59 AM

Don't try to mess with changing the main device names, however. Just have your rules create symlinks to them.

However, for your main internal disks, mounted through fstab, it's generally better to just designate them by UUID instead of dev entry.

http://www.cyberciti.biz/faq/linux-f...-update-fstab/

It's possible to use the device label in fstab in the same way.

Finally, most modern distributions already automatically create symlinks (through udev) in the /dev/disk subdirectory, broken down by UUID, label, device id/serial#, and bus address. You can use any of those to mount the disk as well.

kankan55 12-20-2012 01:13 AM

Quote:

Originally Posted by malekmustaq (Post 4852734)
By which means the system booted, PXE? or HDD local?

I mean after the installation completed , it boot up with /dev/sdb1 which is local disk.

and FYI. I notice that in RHEL 5 ,A local disk is sda.

[root@RHEL5 by-path]# ls -ltr
total 0
lrwxrwxrwx 1 root root 9 Dec 20 06:25 pci-0000:02:00.0-scsi-0:1:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 Dec 20 06:25 pci-0000:02:00.0-scsi-0:1:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Dec 20 06:25 pci-0000:02:00.0-scsi-0:1:0:0-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 Dec 20 06:25 pci-0000:02:00.0-scsi-0:1:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 9 Dec 20 06:25 pci-0000:0c:00.0-fc-0x5006016841e09ae7:0x0000000000000000 -> ../../sdb
lrwxrwxrwx 1 root root 9 Dec 20 06:25 pci-0000:0c:00.0-fc-0x5006016141e09ae7:0x0000000000000000 -> ../../sdc
lrwxrwxrwx 1 root root 9 Dec 20 06:25 pci-0000:0c:00.1-fc-0x5006016041e09ae7:0x0000000000000000 -> ../../sdd
lrwxrwxrwx 1 root root 9 Dec 20 06:25 pci-0000:0c:00.1-fc-0x5006016941e09ae7:0x0000000000000000 -> ../../sde

kankan55 12-20-2012 02:03 AM

And here is in RHEL 6

|-- by-path
| |-- pci-0000:02:00.0-scsi-0:1:0:0 -> ../../sdc
| |-- pci-0000:02:00.0-scsi-0:1:0:0-part1 -> ../../sdc1
| |-- pci-0000:02:00.0-scsi-0:1:0:0-part2 -> ../../sdc2
| |-- pci-0000:02:00.0-scsi-0:1:0:0-part3 -> ../../sdc3
| |-- pci-0000:0c:00.1-fc-0x5006016041e09ae7-lun-0 -> ../../sda
| `-- pci-0000:0c:00.1-fc-0x5006016941e09ae7-lun-0 -> ../../sdb

kankan55 12-20-2012 11:04 AM

It seems like there is no default udev rule for persistance naming of block device in RHEL 6. So the naming of disk device will depends on the kernel, is that right ? For example if the pci bus of fc disk is the first order, this device will be /dev/sda. See below output

sda sdb sdc is san
sde is local disk

[root@RHEL6 ~]# udevadm info -a -n /dev/sda |grep "looking at parent device"
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0/rport-0:0-0/target0:0:0/0:0:0:0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0/rport-0:0-0/target0:0:0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0/rport-0:0-0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0':
looking at parent device '/devices/pci0000:00/0000:00:04.0':
looking at parent device '/devices/pci0000:00':
[root@RHEL6 ~]# udevadm info -a -n /dev/sdb |grep "looking at parent device"
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0/rport-0:0-1/target0:0:1/0:0:1:0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0/rport-0:0-1/target0:0:1':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0/rport-0:0-1':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0/host0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.0':
looking at parent device '/devices/pci0000:00/0000:00:04.0':
looking at parent device '/devices/pci0000:00':
[root@RHEL6 ~]# udevadm info -a -n /dev/sdc |grep "looking at parent device"
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.1/host1/rport-1:0-0/target1:0:0/1:0:0:0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.1/host1/rport-1:0-0/target1:0:0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.1/host1/rport-1:0-0':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.1/host1':
looking at parent device '/devices/pci0000:00/0000:00:04.0/0000:0c:00.1':
looking at parent device '/devices/pci0000:00/0000:00:04.0':
looking at parent device '/devices/pci0000:00':
[root@RHEL6 ~]# udevadm info -a -n /dev/sde |grep "looking at parent device"
looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/host2/target2:1:0/2:1:0:0':
looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/host2/target2:1:0':
looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/host2':
looking at parent device '/devices/pci0000:00/0000:00:1c.0/0000:02:00.0':
looking at parent device '/devices/pci0000:00/0000:00:1c.0':
looking at parent device '/devices/pci0000:00':
[root@RHEL6 ~]#

RHEL 6
[root@RHEL6 rules.d]# ls -ltr
total 32
-rw-r--r--. 1 root root 1060 Jul 25 2010 60-pcmcia.rules
-rw-r--r--. 1 root root 1652 Nov 20 2010 60-fprint-autosuspend.rules
-rw-r--r--. 1 root root 83 May 20 2011 90-hal.rules
-rw-r--r--. 1 root root 53 Dec 8 2011 91-drm-modeset.rules
-rw-r--r--. 1 root root 316 May 1 2012 60-raw.rules
-rw-r--r--. 1 root root 292 Jun 21 17:19 98-kexec.rules
-rw-r--r--. 1 root root 320 Jun 21 21:41 90-alsa.rules
-rw-r--r--. 1 root root 486 Dec 19 06:05 70-persistent-net.rules


RHEL 5
[root@RHEL5 rules.d]# ls -ltr
total 72
-rw-r--r-- 1 root root 1088 Jun 6 2007 60-pcmcia.rules
-rw-r--r-- 1 root root 1823 Nov 5 2008 85-pcscd_ccid.rules
-rw-r--r-- 1 root root 82 Jan 14 2011 90-hal.rules
-rw-r--r-- 1 root root 143 Dec 19 2011 60-net.rules
-rw-r--r-- 1 root root 107 Feb 2 2012 95-pam-console.rules
-rw-r--r-- 1 root root 61 Feb 2 2012 90-dm.rules
-rw-r--r-- 1 root root 471 Feb 2 2012 51-hotplug.rules
-rw-r--r-- 1 root root 16732 Feb 2 2012 50-udev.rules
-rw-r--r-- 1 root root 520 Feb 2 2012 05-udev-early.rules
-rw-r--r-- 1 root root 316 Feb 23 2012 60-raw.rules
-rw-r--r-- 1 root root 992 Aug 2 21:12 40-multipath.rules
-rw-r--r-- 1 root root 175 Aug 9 17:15 88-clock.rules
-rw-r--r-- 1 root root 292 Sep 17 15:50 98-kexec.rules
-rw-rwxr--+ 1 root root 324 Dec 20 06:02 70-persistent-net.rules

PS, sorry for my stupid question. I just want to understand how it works. I think I will use udev to control this scenario.

David the H. 12-20-2012 12:58 PM

As I understand it, yes, the bus address order depends simply on exactly how the kernel's device detection routine is implemented, and things like how fast various devices respond, so different systems and OS's will often show variation.

That's one of the main reasons why the ability to mount devices by UUID and label was implemented. Is there any reason you can't just use that?

And again, I recommend that you DO NOT try to change the default kernel naming scheme. If you have to mess with udev, just have it create symlinks to the devices you want and mount those. Or just use the ones already there in /dev/disk/by-uuid.

kankan55 12-21-2012 12:56 AM

Quote:

Originally Posted by David the H. (Post 4853828)
That's one of the main reasons why the ability to mount devices by UUID and label was implemented. Is there any reason you can't just use that?

And again, I recommend that you DO NOT try to change the default kernel naming scheme. If you have to mess with udev, just have it create symlinks to the devices you want and mount those. Or just use the ones already there in /dev/disk/by-uuid.

Thanks for you reply.

Mounting device by UUID does not meet my requirement which the local boot disk must be /dev/sda.( The custom pxeboot initrd.img does not have any FC modules, So I static the installed OS device to /dev/sda ot /dev/cciss/c0d0). But after installation completed and first reboot, the OS can boot up from the correct OS disk (/boot in fstab is default map UUID device) ,however it's /dev/sd? not /dev/sda as I expected.

Can I just manually create symlink at the installation phase which the root file system is mounted as /mnt/sysimage/ ?

kankan55 12-21-2012 01:43 AM

Quote:

Originally Posted by kankan55 (Post 4854155)
Thanks for you reply.

Can I just manually create symlink at the installation phase which the root file system is mounted as /mnt/sysimage/ ?

I've tried this myself and it's impossible. Once the server is reboot it will be named on exactly how the kernel's device detection routine is implemented.

I'm newbie on writng udev's rule. Can you show me some example for creating symlinks to the devices. Or just use the ones already there in /dev/disk/by-uuid.

Thank you very much

jpollard 12-21-2012 07:15 AM

It is my understanding that the udev rules can only be applied AFTER the system is running...

So the /etc/fstab must use either the UUID= or LABEL= to get mounted. Now, those mounts labeled "noauto" are not under that limitation.

Also, the /dev directory is actually a memory resident filesystem (devtmpfs) so anything you put in the /dev directory will disappear after a reboot.

malekmustaq 12-22-2012 06:42 AM

kankan,

The best way is to bind your disk (any valid attribute will do: SIZE, SERIAL NUMBER, UUID, etc) to a persistent symlink at the udev/rules.d. Probably we can help you if you share us output of these queries:

Code:

udevadm info -a -p  $(udevadm info -q path -n /dev/sd*)
dmidecode -t system

and
Code:

blkid
But one thing to consider first is to examine your pxeboot initrd.img, see if the confusion of naming pattern is not inherited from there.

kankan55 12-24-2012 04:09 AM

Hi Malekmustaq

Here is my rules. But the partition still not sda as expected (df -k and pvscan output)

[root@RHEL6 dev]# cat /etc/udev/rules.d/99-local.rules
KERNEL=="sd*", PROGRAM="/sbin/scsi_id --whitelisted --replace-whitespace /dev/$name", RESULT=="3600508b1001c25b917c0454a97a2a645" NAME:="sda"
KERNEL=="sd*[0-9]", PROGRAM="blkid /dev/$name |cut -d " " -f 2|cut -d "=" -f 2|sed 's/"//g'", RESULT=="8e535539-1f16-4d90-a095-e731fc9fc93d" NAME:="sda1"
KERNEL=="sd*[0-9]", PROGRAM="blkid /dev/$name |cut -d " " -f 2|cut -d "=" -f 2|sed 's/"//g'", RESULT=="eViBqW-CGta-VEyJ-Ptw7-NB0D-dkyL-lMEShc" NAME:="sda2"
KERNEL=="sd*[0-9]", PROGRAM="blkid /dev/$name |cut -d " " -f 2|cut -d "=" -f 2|sed 's/"//g'", RESULT=="eYv5Qv-bpbr-TDmJ-O9zv-KGIZ-GSOB-tMABJ3" NAME:="sda3"

Quote:

[root@RHEL6 dev]# fdisk -l /dev/sda

Disk /dev/sda: 300.0 GB, 299966445568 bytes
255 heads, 63 sectors/track, 36468 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0002e0bf

Device Boot Start End Blocks Id System
/dev/sda1 * 1 66 524288 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 66 4243 33554432 8e Linux LVM
/dev/sda3 4243 36469 258855936 8e Linux LVM

[root@RHEL6 dev]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv
9.9G 1.3G 8.1G 14% /
tmpfs 32G 0 32G 0% /dev/shm
/dev/sdb1 504M 66M 413M 14% /boot

[root@RHEL6 dev]# pvscan
PV /dev/sdb3 VG datavg lvm2 [246.86 GiB / 0 free]
PV /dev/sdb2 VG rootvg lvm2 [32.00 GiB / 0 free]
Total: 2 [278.86 GiB] / in use: 2 [278.86 GiB] / in no VG: 0 [0 ]


Quote:

[root@RHEL6 ~]# udevadm info -q path -n /dev/sda (SAN)
/devices/pci0000:00/0000:00:03.0/0000:04:00.2/host3/rport-3:0-2/target3:0:0/3:0:0:0/block/sda
[root@RHEL6 ~]# udevadm info -q path -n /dev/sdb (LOCAL DISK)
/devices/pci0000:00/0000:00:04.0/0000:03:00.0/host5/target5:0:0/5:0:0:0/block/sdb
[root@RHEL6 ~]# udevadm info -q path -n /dev/sdc (SAN)
/devices/pci0000:00/0000:00:03.0/0000:04:00.3/host4/rport-4:0-2/target4:0:0/4:0:0:0/block/sdc

[root@RHEL6 ~]# blkid
/dev/sdb1: UUID="8e535539-1f16-4d90-a095-e731fc9fc93d" TYPE="ext4"
/dev/sdb2: UUID="eViBqW-CGta-VEyJ-Ptw7-NB0D-dkyL-lMEShc" TYPE="LVM2_member"
/dev/sdb3: UUID="eYv5Qv-bpbr-TDmJ-O9zv-KGIZ-GSOB-tMABJ3" TYPE="LVM2_member"
/dev/mapper/rootvg-rootlv: UUID="16b687c1-9ff9-44cb-83c3-648a1b62aa22" TYPE="ext4"
/dev/mapper/rootvg-swaplv: UUID="9ee2d763-7e48-41cb-9dbf-37ff7b497e48" TYPE="swap"
/dev/mapper/datavg-datalv: UUID="9850a007-f2b5-41df-aa55-c69c3a98e188" TYPE="ext4"
/dev/mapper/rootvg-varlv: UUID="ffa0a372-a88e-4cc6-a78b-354f306d610f" TYPE="ext4"
/dev/mapper/rootvg-homelv: UUID="ab302353-4701-4f43-a7c3-2628e0a71f43" TYPE="ext4"
/dev/mapper/rootvg-perflv: UUID="909d562a-e7ea-4d22-a962-eb379e5fad6e" TYPE="ext4"
/dev/mapper/rootvg-tmplv: UUID="cd832477-cc76-471b-97a3-903ff1c2314d" TYPE="ext4"

malekmustaq 12-24-2012 06:44 AM

Kankan,

Quote:

My pxeboot initrd is clean of FC driver.
Yes... but is your BIOS cleared from giving precedence to the host bus adapter? This is where the issue is. You can neither clear away the fiber channel driver from the BIOS level as this may tend to affect your pxebooting.

You may be able to trick the pxeboot initrd.img by setting the BIOS to deny priority (or set to lower precedence) to your host bus adapter. If it is provided in the BIOS configuration then set it at the boot priority options, give your local disk the highest priority, let alone the SAN's as they are all foreigners, they are only treated as block level local drivers by fiction.

Else, get the world wide name of your host bus adapter and manipulate it from on the BIOS to a lower priority --in any way you can do it there.

Another stupid way (to play with it if you have time) is to deny the SAN arrays at the BIOS level: this way the BIOS and the boot loader will only see one, your local disk, and certainly it will anoint it the rank of /dev/sda. Then, with respect to SAN arrays you can fix them to any string symlink as you like (sdd, sde, sdf, whatever) using udev rules and mount them through /ets/fstab.

The problem cannot be handled from the udev. It is either you will fix your boot loader to boot into /dev/sdb or fix the fiber channel priority from the bios level.

Hope that helps.

Good luck.

m.m.


All times are GMT -5. The time now is 01:04 PM.