Tag Info

New answers tagged

2

Always mapping a given device to the same location is one of the common uses of udev, indeed. Devices can even have multiple locations, for example a disk partition might be reachable via automated numbering (e.g. /dev/sda1) but also via the label on its filesystem (/dev/disk/by-label/*), via the UUID on its filesystem (/dev/disk/by-uuid/*), and by the ...


1

Plug your usb drive and use udevadm info -a -p /sys/block/sd* where * is your disk assigned number(sda1,sda3,sdb2,etc) Then wrote a udev rule like this KERNEL=="sd*", SUBSYSTEMS==" block", ATTRS{serial}=="**************", SYMLINK+="sdb%n" Of course edit this based on udevadm info Another good solution is to use DISK_UID or LABEL for mount,then ...


0

Using strace udevadm info --query=all --name=/dev/sda I could see that /run/udev/data/b8:0 is also read: open("/run/udev/data/b8:0", O_RDONLY|O_CLOEXEC) = 3 This is an ASCII file: /run/udev/data/b8:0: ASCII text Containing the information you want to see. In your case it is necessary to have /run/udev/data available in your chroot environment aswell ...


1

I'm using a udev rule as follows, to give members of group leds access to all LEDs: SUBSYSTEM=="leds", ACTION=="add|change", RUN+="/bin/chgrp -R leds /sys%p", RUN+="/bin/chmod -R g=u /sys%p" Note the ACTION=="change" is needed to handle dynamically created attributes. For example, if the LED's trigger is set to "timer" (echo timer > trigger), then ...


0

The HID system checks for a specialized driver matching the vendor and product ids, and if there is none it is treated as a generic HID device : the descriptors sent by the device are used to determine what it is. In your case there is a specialized hid driver, but it looks like it wasn't loaded. You can try modprobe hid-dr, but you probably don't have it ...


0

For some reason, I never posted an answer to this, even after I got this working. The following udev rule was what finally worked: SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="COM1", MODE="0666" Note that SUBSYSTEM is tty, not usb, NAME has been changed to SYMLINK+, and serial has been changed to COM1 (to not interfere ...


0

The following udev rule was what finally worked: SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="COM1", MODE="0666" Note that SUBSYSTEM is tty, not usb, NAME has been changed to SYMLINK+, and serial has been changed to COM1 (to not interfere with /dev/serial, as a commenter pointed out.)


0

Ok, I think I figured out the issue. I think the issue is the result of line 157 where I'm redirecting the output to a file; that file happens to be a mounted USB drive. I'm guessing the redirecting is done concurrently, and when product-manifest.sh is complete the script continues, eventually leading to umounting the USB drive before the concurrent write to ...



Top 50 recent answers are included