You are not logged in.
Pages: 1
This is on a Eee 701 4g running Kernel-eee.
Sun Mar 25 11:09:29 2012: udevd[89]: error opening ATTR{/sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/sda5/queue/rotational} for writing: No such file or directoryYou can find the complete output from /log/boot here. Thanks!
One thing at a time
Offline
Offline
/etc/udev/rules.d is an empty directory for me, with no hidden files. Perhaps it is related to a bug in kernel-eee, which I recently upgraded
One thing at a time
Offline
Offline
Might want to check /lib/udev/rules.d as well. Make sure all the files in the directory are owned by a package.
Thanks, /lib/udev/rules.d contains lots of rules. I'm reading the wiki and man udev to learn more.
$ ls -la /lib/udev/rules.d/
total 160
drwxr-xr-x 2 root root 4096 Mar 25 10:53 .
drwxr-xr-x 5 root root 4096 Mar 25 07:30 ..
-r--r--r-- 1 root root 6539 Mar 14 15:26 10-dm.rules
-r--r--r-- 1 root root 1286 Jul 7 2010 11-dm-lvm.rules
-r--r--r-- 1 root root 1446 Mar 14 15:26 13-dm-disk.rules
-rw-r--r-- 1 root root 60 Dec 20 10:01 40-hpet-permissions.rules
-rw-r--r-- 1 root root 764 Mar 14 18:25 42-qemu-usb.rules
-rw-r--r-- 1 root root 3660 Mar 14 18:25 50-udev-default.rules
-rw-r--r-- 1 root root 646 Mar 14 18:25 60-cdrom_id.rules
-rw-r--r-- 1 root root 1060 Mar 13 13:05 60-pcmcia.rules
-rw-r--r-- 1 root root 616 Mar 14 18:25 60-persistent-alsa.rules
-rw-r--r-- 1 root root 2400 Mar 14 18:25 60-persistent-input.rules
-rw-r--r-- 1 root root 947 Mar 14 18:25 60-persistent-serial.rules
-rw-r--r-- 1 root root 5968 Mar 14 18:25 60-persistent-storage.rules
-rw-r--r-- 1 root root 1420 Mar 14 18:25 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root 769 Mar 14 18:25 60-persistent-v4l.rules
-rw-r--r-- 1 root root 166 Mar 14 18:25 61-accelerometer.rules
-rw-r--r-- 1 root root 561 Mar 25 01:28 61-eee-ssd.rules
-rw-r--r-- 1 root root 2301 Jan 20 05:38 64-md-raid.rules
-rw-r--r-- 1 root root 174 Mar 9 09:13 69-xorg-vmmouse.rules
-rw-r--r-- 1 root root 2569 Mar 14 18:25 70-udev-acl.rules
-rw-r--r-- 1 root root 570 Mar 14 18:25 75-net-description.rules
-rw-r--r-- 1 root root 255 Mar 14 18:25 75-probe_mtd.rules
-rw-r--r-- 1 root root 570 Mar 14 18:25 75-tty-description.rules
-rw-r--r-- 1 root root 4174 Mar 14 18:25 78-sound-card.rules
-rw-r--r-- 1 root root 565 Mar 14 18:25 80-drivers.rules
-rw-r--r-- 1 root root 9507 Mar 3 06:08 80-udisks.rules
-rw-r--r-- 1 root root 335 Feb 9 09:54 85-regulatory.rules
-rw-r--r-- 1 root root 131 Mar 1 23:35 90-alsa-restore.rules
-r--r--r-- 1 root root 492 Nov 1 2009 95-dm-notify.rules
-rw-r--r-- 1 root root 3328 Mar 14 18:25 95-keyboard-force-release.rules
-rw-r--r-- 1 root root 11643 Mar 14 18:25 95-keymap.rules
-rw-r--r-- 1 root root 155 Mar 14 18:25 95-udev-late.rulesSo the number at the start of each file denotes the program that owns that rule? Example: 95-keymap.rules
Edit: This looks useful
$ less /lib/udev/rules.d/61-eee-ssd.rules
# Ensure our SSD drive is set up as non-rotational
# These rules are derived from the output of a commands such as:
# udevadm info -a --name /dev/sda
# udevadm info --query=property --name=/dev/sda
# Where /dev/sda is the SSD device. SUBSYSTEM, etc. type rules come from the
# former while ENV property matches are derived from the latter.
# Eee 701
ACTION=="add" SUBSYSTEM=="block", ENV{ID_MODEL}=="SILICONMOTION_SM223AC", ATTR{queue/rotational}="0"
# Eee 901
ACTION=="add" SUBSYSTEM=="block", ENV{ID_MODEL}=="ASUS-PHISON_SSD", ATTR{queue/rotational}="0"$ udevadm info -a --name /dev/sda5
Udevadm info 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:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/sda5':
KERNEL=="sda5"
SUBSYSTEM=="block"
DRIVER==""
ATTR{partition}=="5"
ATTR{start}=="5863788"
ATTR{size}=="1943802"
ATTR{ro}=="0"
ATTR{alignment_offset}=="0"
ATTR{discard_alignment}=="0"
ATTR{stat}==" 187 512 1724 296 7 4 58 331 0 497 627"
ATTR{inflight}==" 0 0"
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda':
KERNELS=="sda"
SUBSYSTEMS=="block"
DRIVERS==""
ATTRS{range}=="16"
ATTRS{ext_range}=="256"
ATTRS{removable}=="0"
ATTRS{ro}=="0"
ATTRS{size}=="7815024"
ATTRS{alignment_offset}=="0"
ATTRS{discard_alignment}=="0"
ATTRS{capability}=="50"
ATTRS{stat}==" 3226 626 89634 5767 339 59 4010 126138 0 13567 131887"
ATTRS{inflight}==" 0 0"
ATTRS{events}==""
ATTRS{events_async}==""
ATTRS{events_poll_msecs}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0':
KERNELS=="1:0:0:0"
SUBSYSTEMS=="scsi"
DRIVERS=="sd"
ATTRS{device_blocked}=="0"
ATTRS{type}=="0"
ATTRS{scsi_level}=="6"
ATTRS{vendor}=="ATA "
ATTRS{model}=="SILICONMOTION SM"
ATTRS{rev}=="n/a "
ATTRS{state}=="running"
ATTRS{timeout}=="30"
ATTRS{iocounterbits}=="32"
ATTRS{iorequest_cnt}=="0xe2d"
ATTRS{iodone_cnt}=="0xe2d"
ATTRS{ioerr_cnt}=="0x2"
ATTRS{evt_media_change}=="0"
ATTRS{queue_depth}=="1"
ATTRS{queue_type}=="none"
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0':
KERNELS=="target1:0:0"
SUBSYSTEMS=="scsi"
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2/host1':
KERNELS=="host1"
SUBSYSTEMS=="scsi"
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:1f.2/ata2':
KERNELS=="ata2"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:1f.2':
KERNELS=="0000:00:1f.2"
SUBSYSTEMS=="pci"
DRIVERS=="ata_piix"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2653"
ATTRS{subsystem_vendor}=="0x1043"
ATTRS{subsystem_device}=="0x82d8"
ATTRS{class}=="0x010180"
ATTRS{irq}=="19"
ATTRS{local_cpus}=="1"
ATTRS{local_cpulist}=="0"
ATTRS{dma_mask_bits}=="32"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""So, could you explain a little more on why using a partition (sda5) in udev rules relates to sysfs. Thanks for the assistance!
Last edited by medianmajik (2012-03-27 19:39:46)
One thing at a time
Offline
So the number at the start of each file denotes the program that owns that rule? Example: 95-keymap.rules
No, pacman -Qo tells you who owns a file.. the number to the left is strictly for ordering the files
Edit: This looks useful
You're triggering the rule for every partition of the given block device, when you only want to trigger for the disk itself.. however, why do you need this rule at all? If the disk isn't being detected properly as non-rotational, its a kernel bug. If for some reason you insist on keeping the rules, change them so they only fire for disks...
ACTION=="add", KERNEL="sd[a-z]", SUBSYSTEM=="block", ENV{ID_MODEL}=="SILICONMOTION_SM223AC", ATTR{queue/rotational}="0"So, could you explain a little more on why using a partition (sda5) in udev rules relates to sysfs. Thanks for the assistance!
...because that's what udev mainly operates on. You can think of /dev as being an abstraction of what exists in /sys. An entry exist in sysfs for all of your hardware, but there may not necessarily be a node for it in /dev.
Offline
Pages: 1