LinuxQuestions.org - udev keeps changing sd* devices

- Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)

- - udev keeps changing sd* devices (https://www.linuxquestions.org/questions/linux-software-2/udev-keeps-changing-sd%2A-devices-686939/)

udev keeps changing sd* devices

My system has two SATA controllers. Two harddiscs are connected to the onboard (VIA) controller and a DVD-writer is connected to a PCIe-controller with a SIL chipset.

Depending on the "mood of the system" the DVD-writer is either /dev/sda or /dev/sdc. But the HDDs and writer can be used without trouble. I'm already using UUIDs in /etc/fstab.

BUT ...

I run munin to constantly check on the SMART values and this is the part where it's becoming trouble some. Because /dev/sda is not constantly linked to a HDD smartctl fails and cannot track.

Using udev I try to create two extra symlinks to the HDD devices but this is where I fail. With the help of several guides I came up with the following rules, but they don't work. And I simply cannot find out why.

I created an extra rules-file named /etc/udev/rules.d/60-misel.rules. The 60 is taken from the README which suggests to use 60 for "60 rules that add symlinks to device nodes (adds to those set in earlier rules)".

Code:

SUBSYSTEMS=="scsi", ATTRS{model}=="SAMSUNG SP2504C ", SYMLINK+='samsung250'

SUBSYSTEMS=="scsi", ATTRS{model}=="SAMSUNG HD320KJ ", SYMLINK+='samsung320'

From my understanding this should create one extra symlinks for each hard disc. But it doesn't. I know there's a trailing space but this is what "udevinfo -a -p /block/sdb" reports. Trimming this space doesn't help either.

I've also tried other rules that I've came across such as these.

Code:

SUBSYSTEM=="block", ATTR{size}=="488397168", SYMLINK+='samsung250'

SUBSYSTEMS=="scsi", KERNELS=="host5", SYMLINK+="Drawer"

The first one doesn't work at all, too. The second one kinda works but it creates a link to a (seemingly) random partition on that disc. As a result it doesn't work with smartctl.

I'm using Xubuntu 8.10 and it's quite frustrating not to have udevtest around which is mentioned on some sites. So I have to reboot each time I want to test a change. I also don't get very much out of the udev logs.

I fear it's something really obvious but I just can't find it. Can you please help me?

I cannot count the number of udev guides that I already read. And the first link you provided suggests exactly that rule, that I already tried and didn't work.

From the guide:

Code:

SUBSYSTEM=="block", ATTR{size}=="234441648", SYMLINK+="my_disk"

My line

Code:

SUBSYSTEM=="block", ATTR{size}=="488397168", SYMLINK+='samsung250'

Result on my side nothing. :(

I entered a faulty rule in the file and got a message that there is an error. So my own-rules-file is not ignored.

Here's the output of udevinfo for this drive

Quote:

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:0f.0/host4/target4:0:0/4:0:0:0/block/sdb':
KERNEL=="sdb"
SUBSYSTEM=="block"
DRIVER==""
ATTR{range}=="16"
ATTR{removable}=="0"
ATTR{ro}=="0"
ATTR{size}=="488397168"
ATTR{capability}=="12"
ATTR{stat}==" 344132 51878 8115033 2367972 762371 1536011 18410472 8118440 0 2134752 10486852"

looking at parent device '/devices/pci0000:00/0000:00:0f.0/host4/target4:0:0/4:0:0:0/block':
KERNELS=="block"
SUBSYSTEMS==""
DRIVERS==""

looking at parent device '/devices/pci0000:00/0000:00:0f.0/host4/target4:0:0/4:0:0:0':
KERNELS=="4:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{device_blocked}=="0"
ATTRS{type}=="0"
ATTRS{scsi_level}=="6"
ATTRS{vendor}=="ATA "
ATTRS{model}=="SAMSUNG SP2504C "
ATTRS{rev}=="VT10"
ATTRS{state}=="running"
ATTRS{timeout}=="30"
ATTRS{iocounterbits}=="32"
ATTRS{iorequest_cnt}=="0x10ed2f"
ATTRS{iodone_cnt}=="0x10ed2f"
ATTRS{ioerr_cnt}=="0x36c"
ATTRS{modalias}=="scsi:t-0x00"
ATTRS{evt_media_change}=="0"
ATTRS{queue_depth}=="1"
ATTRS{queue_type}=="none"

looking at parent device '/devices/pci0000:00/0000:00:0f.0/host4/target4:0:0':
KERNELS=="target4:0:0"
SUBSYSTEMS=="scsi"
DRIVERS==""

looking at parent device '/devices/pci0000:00/0000:00:0f.0/host4':
KERNELS=="host4"
SUBSYSTEMS=="scsi"
DRIVERS==""

looking at parent device '/devices/pci0000:00/0000:00:0f.0':
KERNELS=="0000:00:0f.0"
SUBSYSTEMS=="pci"
DRIVERS=="sata_via"
ATTRS{vendor}=="0x1106"
ATTRS{device}=="0x0591"
ATTRS{subsystem_vendor}=="0x1106"
ATTRS{subsystem_device}=="0x0591"
ATTRS{class}=="0x01018f"
ATTRS{irq}=="21"
ATTRS{local_cpus}=="00000000,00000003"
ATTRS{local_cpulist}=="0-1"
ATTRS{modalias}=="pci:v00001106d00000591sv00001106sd00000591bc01sc01i8f"
ATTRS{numa_node}=="0"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""

looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""

I know they are diff sizes but are these disks used in a raid?

if not in raid...are they both used in essential fstab mounting system partitions...not data etc?

I am thinking...lets try removing the non-essential from bios...and make a funny udev rule that proves the rule works....and then try again with both drives

Quote:

Originally Posted by aus9 (Post 3359291)

I know they are diff sizes but are these disks used in a raid?

No, they're not part of any RAID system.

Quote:

Originally Posted by aus9 (Post 3359291)

if not in raid...are they both used in essential fstab mounting system partitions...not data etc?

The "samsung250" contains the root and home partition. The "samsung320" contains Windows XP and a data partition.

Quote:

Originally Posted by aus9 (Post 3359291)

I am thinking...lets try removing the non-essential from bios...and make a funny udev rule that proves the rule works....and then try again with both drives

That sounds reasonable. But where do I start? The rules I came up with cannot really be made anything shorter.:confused:

There might be 2 more tools in the udev toolbox, dunno if you have seen them. One is udevtest to see which rules are being applied, the other one is udevtrigger, which let you re-iterate thru the device creation process without actually unplugging the hardware.

Also, you can set the log level to debug an discover why udev renames devices by looking into the logs.

(Set the log level to debug, restart udev, trigger the devices)

There have been some changes in the udev programs, udevtest disappeared in favor of 'udevadm test', etc. Use the man page for udevadm and try to find from there the test and trigger programs I mentioned.

jlinkels