Re: udev device-persistence problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>T. Horsnell wrote:
>> FC6 - kernel 2.6.18-1.2798.fc6 - udev-095-14
>> 
>> I'm trying to develop some rules to give me device-name
>> persistence on my SCSI disks. I have a couple of test rules:
>> 
>> BUS=="scsi", PROGRAM="/sbin/scsi_id -g -u"
>> RESULT=="20004cffffe0e0976", NAME="dsk0_%n", OWNER="root", GROUP="root", MODE="0700"
>> RESULT=="SSEAGATE_ST336807LC_3KT0CTTM00007530YTR2", NAME="dsk1_%n", OWNER="root", GROUP="root", MODE="0700"
>> 
>> With these rules disabled, I get:
>> 
>
><-------------[ SNIP ]--------------------------->
>
>
>> Why have I got both sd devices and dsk devices?
>> And what is the second line?
>> Why have I got an entry:
>> crw------- 1 root root 21,  0 Nov 28 11:45 /dev/dsk0_0
>> 
>> This looks like a generic device, but if so, why only one?
>> And where are the normal sg devices?
>> 
>> 
>
><-------------[ SNIP ]--------------------------->
>
>> 
>> 
>> Is this all as expected?
>> Am I going to be screwed later on if I need to do something
>> that requires a generic SCSI device for a particular disk?
>> Why do I still get /dev/sd* entries?
>> Any clues anyone?
>> 
>> Cheers,
>> Terry.
>> 
>> 
>Unless you use OPTIONS="last_rule" in your rule, both your rule and
>the default rule will be used. So you will end up with both sets of
>device entries.
>
>Now, as for the order problem, you may need to change the program
>from "/sbin/scsi_id -g -u" to "/sbin/scsi_id -d %N -s %p" or
>"/sbin/scsi_id -d %N -s %p -g -u". What I suspect is happening is
>that scsi_id is not returning what you expect. From the scsi_id man
>page:
>
>scsi_id  is  one  of  the  tools used in the "Linux Persistent
>Device Names" scheme that creates persistent device links in
>/dev/disk. It is called with the -x option which will print all
>values in a defined format to let udev import it into its own
>environment for later event processing.
>
>An  example custom udev rule using scsi_id, that will name a block
>device and any partitions for the device matching the scsi_id output
>of 312345:
>
>BUS=="scsi", PROGRAM=="/sbin/scsi_id -d %N -s %p", RESULT=="312345",
>NAME="disk%n"
>

Thanks for this advice Mikkel, but so far it doesnt make any difference.
Here's my modified ruleset:

BUS=="scsi", PROGRAM="/sbin/scsi_id -d %N -s %p -g -u"
RESULT=="20004cffffe0e0976", NAME="dsk0_%n", OWNER="root", GROUP="root", MODE="0700", OPTIONS="last_rule"
RESULT=="SSEAGATE_ST336807LC_3KT0CTTM00007530YTR2", NAME="dsk1_%n", OWNER="root", GROUP="root", MODE="0700", OPTI$

And here's the results:
(There is actually a small difference. I now dont have a block-device
for dsk0, partition 1. /dev/disk0_1 has become a character device.)

[root@dev1 ~]# ls -l /dev/sd* /dev/sg* /dev/dsk*
brwx------ 1 root root  8, 16 Dec  4 15:54 /dev/dsk0_
crwx------ 1 root root 21,  1 Dec  4 15:54 /dev/dsk0_1
brwx------ 1 root root  8,  0 Dec  4 15:54 /dev/dsk1_
crwx------ 1 root root 21,  0 Dec  4 15:54 /dev/dsk1_0
brwx------ 1 root root  8,  1 Dec  4 15:54 /dev/dsk1_1
brwx------ 1 root root  8,  2 Dec  4 15:54 /dev/dsk1_2
brwx------ 1 root root  8,  3 Dec  4 15:54 /dev/dsk1_3
brwx------ 1 root root  8,  4 Dec  4 15:54 /dev/dsk1_4
brwx------ 1 root root  8,  5 Dec  4 15:54 /dev/dsk1_5
brwx------ 1 root root  8,  6 Dec  4 15:54 /dev/dsk1_6
brwx------ 1 root root  8,  7 Dec  4 15:54 /dev/dsk1_7
brwx------ 1 root root  8,  8 Dec  4 15:54 /dev/dsk1_8
brwx------ 1 root root  8,  0 Dec  4 15:54 /dev/sda
brwx------ 1 root root  8,  1 Dec  4 15:54 /dev/sda1
brwx------ 1 root root  8,  2 Dec  4 15:54 /dev/sda2
brwx------ 1 root root  8,  3 Dec  4 15:54 /dev/sda3
brwx------ 1 root root  8,  4 Dec  4 15:54 /dev/sda4
brwx------ 1 root root  8,  5 Dec  4 15:54 /dev/sda5
brwx------ 1 root root  8,  6 Dec  4 15:54 /dev/sda6
brwx------ 1 root root  8,  7 Dec  4 15:54 /dev/sda7
brwx------ 1 root root  8,  8 Dec  4 15:54 /dev/sda8
brwx------ 1 root root  8, 16 Dec  4 15:54 /dev/sdb
brwx------ 1 root root  8, 17 Dec  4 15:54 /dev/sdb1

Cheers,
Terry.


>Mikkel
>-- 
>
>  Do not meddle in the affairs of dragons,
>for thou art crunchy and taste good with Ketchup!
>
>-- 
>fedora-list mailing list
>fedora-list@xxxxxxxxxx
>To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux