Udev rules problem (2 webcams, assigning videoX devices)

I've got a built-in webcam (notebook) and an external one connected too, different vendor/product IDs.
I want the built-in cam to be video0 and the external one video1.
I added a file /etc/udev/rules.d/25-name-video-devices.rules containing:
#external cam has ID eb1a:2571
SUBSYSTEM=="video4linux", BUS=="usb", SYSFS{idVendor}=="eb1a", SYSFS{idProduct}=="2571", NAME="video1"
#internal cam has ID 5986:030c
SUBSYSTEM=="video4linux", BUS=="usb", SYSFS{idVendor}=="5986", SYSFS{idProduct}=="030c", NAME="video0"
but it doesn't seem to have effect. After a reboot, the internal cam is now video1 and the external one video0..
any ideas?

SYSFS is deprecated.
Pastebin these somewhere:
udevadm info -a --name /dev/video0
udevadm info -a --name /dev/video1
Edit: This is probably what you want:
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="eb1a", ATTRS{idProduct}=="2571", NAME:="video1"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="5986", ATTRS{idProduct}=="030c", NAME:="video0"
Edit2: Although, messing with the kernel's own names is inelegant (e.g. a third webcam will play havoc with the names until you write a rule for that too), better with symlinks:
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="eb1a", ATTRS{idProduct}=="2571", SYMLINK+="videoext"
SUBSYSTEM=="video4linux", ATTRS{idVendor}=="5986", ATTRS{idProduct}=="030c", SYMLINK+="videoint"
Yet another edit: Specifying SUBSYSTEM is a bit more elegant than:  KERNEL=="video[0-9]*"
Last edited by brebs (2013-04-26 16:38:24)

Similar Messages

  • UDEV rules for Xilinx FPGA devices

    I recently purchased a Digilent Nexys3 FPGA board with a Xilinx Spartan 5 FPGA on it. I finally got around to finding some time to using it, and setting up the development environment under Arch linux.
    After spending ages reading around about various problems and workarounds, I finally managed to get Xilinx ISE Webpack installed and working, as well as Digilent Adept software for downloading the designs to the development board. One issue still remains though. I am unable to download the designs to the FPGA as a normal user, but only as root.
    I'm pretty sure this is a udev rules problem. Digilent supplies a rules file (attached below) which is supposed to grant permissions to all users to access the FPGA devices over USB. I placed this rule file under /etc/udev/rules.d, but I am still unable to access the devices as normal user due to the following error:
    $ djtgcfg enum
    libusb couldn't open USB device /dev/bus/usb/001/003: Permission Denied.
    libusb requires write access to USB device nodes.
    $
    I believe that udev rules syntax changed since the last time I had a look at it, so maybe the supplied rules file still uses the old syntax? Any suggestions to fixing this rules file (attached below)?
    # 52-digilent-usb.rules -- UDEV rules for Digilent USB Devices #
    # Author: MTA #
    # Copyright 2010 Digilent Inc. #
    # File Description: #
    # This file contains the rules used by UDEV when creating entries for #
    # Digilent USB devices. In order for Digilent's shared libraries and #
    # applications to access these devices without root privalages it is #
    # necessary for UDEV to create entries for which all users have read #
    # and write permission. #
    # Usage: #
    # Copy this file to "/etc/udev/rules.d/" and execute #
    # "/sbin/udevcontrol reload_rules" as root. This only needs to be done #
    # immediately after installation. Each time you reboot your system the #
    # rules are automatically loaded by UDEV. #
    # Revision History: #
    # 04/15/2010(MTA): created #
    # 02/28/2011(MTA): modified to support FTDI based devices #
    # Create "/dev" entries for Digilent device's with read and write
    # permission granted to all users.
    SYSFS{idVendor}=="1443", MODE="666"
    ACTION=="add", SYSFS{idVendor}=="0403", SYSFS{manufacturer}=="Digilent", MODE="666", RUN+="/usr/local/sbin/dftdrvdtch %s{busnum} %s{devnum}"
    # The following rules (if present) cause UDEV to ignore all UEVENTS for
    # which the subsystem is "usb_endpoint" and the action is "add" or
    # "remove". These rules are necessary to work around what appears to be a
    # bug in the Kernel used by Red Hat Enterprise Linux 5/CentOS 5. The Kernel
    # sends UEVENTS to remove and then add entries for the endpoints of a USB
    # device in "/dev" each time a process releases an interface. This occurs
    # each time a data transaction occurs. When an FPGA is configured or flash
    # device is written a large number of transactions take place. If the
    # following lines are commented out then UDEV will be overloaded for a long
    # period of time while it tries to process the massive number of UEVENTS it
    # receives from the kernel. Please note that this work around only applies
    # to systems running RHEL5 or CentOS 5 and as a result the rules will only
    # be present on those systems.
    Thanks!
    -Igor
    Last edited by UQ-igor (2011-12-24 03:56:10)

    Try this
    Use ATTR or ATTRS.
    -SYSFS{idVendor}=="1443", MODE="666"
    -ACTION=="add", SYSFS{idVendor}=="0403", SYSFS{manufacturer}=="Digilent", MODE="666", RUN+="/usr/sbin/dftdrvdtch %s{busnum} %s{devnum}"
    +ATTRS{idVendor}=="1443", MODE="666"
    +ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{manufacturer}=="Digilent", MODE="666", RUN+="/usr/sbin/dftdrvdtch %s{busnum} %s{devnum}"
    +ATTR{idVendor}=="1443", MODE="666"
    +ACTION=="add", ATTR{idVendor}=="0403", ATTR{manufacturer}=="Digilent", MODE="666", RUN+="/usr/sbin/dftdrvdtch %s{busnum} %s{devnum}"

  • UDev rules not working for MidiSport 2x2 usb midi device

    I installed arch a couple of months ago and am loving it so far.  Any problems I've had so far have already been solved in the forums, but this one's really got me.  I have a MidiSport 2x2 that I want the firmware to be loaded on everytime I plug it in.  I installed (there's not an arch package) a package that is supposed to do just that.  (It's called midisport-firmware-1.2.tar.gz).  However, the package seems to be out of date (2006) and I even had to modify a couple places in the configure script to get it to work with current program revisions.  However, once installed, it does nothing.  It installed firmware files and udev rules for the device into a couple of directories.  When I run the command that is supposed to load the firmware, it works fine.  But for some reason, (I even checked the udev kernel log) it's like the event isn't even being triggered.  Here's part of the original file that came with the package that's supposed to load the firmware:
    # midisport-firmware.rules - udev rules for loading firmware into MidiSport devices
    # DEVPATH=="/*.0" selects interface 0 only
    # (some udev versions don't work with SYSFS{bInterfaceNumber})
    # MidiSport 2x2
    ACTION=="add", SUBSYSTEM=="usb", DEVPATH=="/*.0", ENV{PRODUCT}=="763/1001/*", RUN+="/sbin/fxload -s /usr/local/share/usb/maudio/MidiSportLoader.ihx -I /usr/local/share/usb/maudio/MidiSport2x2.ihx"
    # vim: ft=conf
    And here's what I modified it to in an attempt to make it work:
    # MidiSport 2x2
    ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0763", ATTR{idProduct}=="1001", RUN+="/sbin/fxload -D /dev/%k -s /usr/local/share/usb/maudio/MidiSportLoader.ihx -I /usr/local/share/usb/maudio/MidiSport2x2.ihx"
    I would really appreciate help from anyone who knows about this kind of thing, as I can't figure out what's going wrong.  If it's something wrong with the config, please let me know.  Actually, some HAL events popped up when I was testing this out.  Is it possible HAL is blocking  the udev event somehow?

    Hi,
    The firmware files must be put in /lib/firmware so they can be found by the kernel. Are they being put there?

  • [Solved] udev rules: serial for persistent device naming disappeared

    Hello,
    since the latest upgrade of udev and kmod I cant't mount my external e-SATA hard disk with my working udev rules.
    This is my udev rule:
    $ cat /etc/udev/rules.d/66-persistent_esata.rules
    KERNEL=="sd?1", SUBSYSTEMS=="block", ENV{ID_SERIAL_SHORT}=="S1VSJ1LS301247", NAME="aluguard"
    When plugged in, I could decrypt and mount it with "sudo cryptsetup luksOpen /dev/aluguard aluguard && mount /mnt/aluguard".
    Since the update above I get "Device /dev/aluguard doesn't exist or access denied."
    While I re-checked https://wiki.archlinux.org/index.php/Ma … _with_udev, I discovered, that the serial entry in the output of udevadm has vanished:
    $ udevadm info -a -p $(udevadm info -q path -n /dev/sdg)
    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:09.0/host3/target3:0:0/3:0:0:0/block/sdg':
    KERNEL=="sdg"
    SUBSYSTEM=="block"
    DRIVER==""
    ATTR{range}=="16"
    ATTR{ext_range}=="256"
    ATTR{removable}=="0"
    ATTR{ro}=="0"
    ATTR{size}=="1953525168"
    ATTR{alignment_offset}=="0"
    ATTR{discard_alignment}=="0"
    ATTR{capability}=="50"
    ATTR{stat}==" 96 24 762 780 0 0 0 0 0 780 780"
    ATTR{inflight}==" 0 0"
    ATTR{events}==""
    ATTR{events_async}==""
    ATTR{events_poll_msecs}=="-1"
    looking at parent device '/devices/pci0000:00/0000:00:09.0/host3/target3:0:0/3:0:0:0':
    KERNELS=="3:0:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS=="sd"
    ATTRS{device_blocked}=="0"
    ATTRS{type}=="0"
    ATTRS{scsi_level}=="6"
    ATTRS{vendor}=="ATA "
    ATTRS{model}=="SAMSUNG HD103SI "
    ATTRS{rev}=="1AG0"
    ATTRS{state}=="running"
    ATTRS{timeout}=="30"
    ATTRS{iocounterbits}=="32"
    ATTRS{iorequest_cnt}=="0xa2"
    ATTRS{iodone_cnt}=="0x98"
    ATTRS{ioerr_cnt}=="0xc"
    ATTRS{evt_media_change}=="0"
    ATTRS{queue_depth}=="31"
    ATTRS{queue_ramp_up_period}=="120000"
    ATTRS{queue_type}=="simple"
    looking at parent device '/devices/pci0000:00/0000:00:09.0/host3/target3:0:0':
    KERNELS=="target3:0:0"
    SUBSYSTEMS=="scsi"
    DRIVERS==""
    looking at parent device '/devices/pci0000:00/0000:00:09.0/host3':
    KERNELS=="host3"
    SUBSYSTEMS=="scsi"
    DRIVERS==""
    looking at parent device '/devices/pci0000:00/0000:00:09.0':
    KERNELS=="0000:00:09.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="ahci"
    ATTRS{vendor}=="0x10de"
    ATTRS{device}=="0x0554"
    ATTRS{subsystem_vendor}=="0x1849"
    ATTRS{subsystem_device}=="0x0554"
    ATTRS{class}=="0x010601"
    ATTRS{irq}=="23"
    ATTRS{local_cpus}=="00000000,00000003"
    ATTRS{local_cpulist}=="0-1"
    ATTRS{numa_node}=="0"
    ATTRS{dma_mask_bits}=="64"
    ATTRS{consistent_dma_mask_bits}=="64"
    ATTRS{enable}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""
    looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""
    What is the reason for this strange behaviour, and how can I get back the serial entry?
    Thank in advance!
    Last edited by indianahorst (2012-01-31 13:03:20)

    $ udevadm info -q all -n /dev/sdg1
    P: /devices/pci0000:00/0000:00:09.0/host3/target3:0:0/3:0:0:0/block/sdg/sdg1
    N: sdg1
    S: disk/by-id/ata-SAMSUNG_HD103SI_S1VSJ1LS301247-part1
    S: disk/by-id/scsi-SATA_SAMSUNG_HD103SIS1VSJ1LS301247-part1
    S: disk/by-id/wwn-0x50024e900136a03e-part1
    S: disk/by-path/pci-0000:00:09.0-scsi-3:0:0:0-part1
    S: disk/by-uuid/bb024e1b-78a5-4ed0-9e80-aaa7633aa493
    E: DEVLINKS=/dev/disk/by-id/ata-SAMSUNG_HD103SI_S1VSJ1LS301247-part1 /dev/disk/by-id/scsi-SATA_SAMSUNG_HD103SIS1VSJ1LS301247-part1 /dev/disk/by-id/wwn-0x50024e900136a03e-part1 /dev/disk/by-path/pci-0000:00:09.0-scsi-3:0:0:0-part1 /dev/disk/by-uuid/bb024e1b-78a5-4ed0-9e80-aaa7633aa493
    E: DEVNAME=/dev/sdg1
    E: DEVPATH=/devices/pci0000:00/0000:00:09.0/host3/target3:0:0/3:0:0:0/block/sdg/sdg1
    E: DEVTYPE=partition
    E: ID_ATA=1
    E: ID_ATA_DOWNLOAD_MICROCODE=1
    E: ID_ATA_FEATURE_SET_AAM=1
    E: ID_ATA_FEATURE_SET_AAM_CURRENT_VALUE=254
    E: ID_ATA_FEATURE_SET_AAM_ENABLED=1
    E: ID_ATA_FEATURE_SET_AAM_VENDOR_RECOMMENDED_VALUE=254
    E: ID_ATA_FEATURE_SET_APM=1
    E: ID_ATA_FEATURE_SET_APM_ENABLED=0
    E: ID_ATA_FEATURE_SET_HPA=1
    E: ID_ATA_FEATURE_SET_HPA_ENABLED=1
    E: ID_ATA_FEATURE_SET_PM=1
    E: ID_ATA_FEATURE_SET_PM_ENABLED=1
    E: ID_ATA_FEATURE_SET_PUIS=1
    E: ID_ATA_FEATURE_SET_PUIS_ENABLED=0
    E: ID_ATA_FEATURE_SET_SECURITY=1
    E: ID_ATA_FEATURE_SET_SECURITY_ENABLED=0
    E: ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN=194
    E: ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN=194
    E: ID_ATA_FEATURE_SET_SMART=1
    E: ID_ATA_FEATURE_SET_SMART_ENABLED=1
    E: ID_ATA_SATA=1
    E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1
    E: ID_ATA_SATA_SIGNAL_RATE_GEN2=1
    E: ID_ATA_WRITE_CACHE=1
    E: ID_ATA_WRITE_CACHE_ENABLED=1
    E: ID_BUS=ata
    E: ID_FS_TYPE=crypto_LUKS
    E: ID_FS_USAGE=crypto
    E: ID_FS_UUID=bb024e1b-78a5-4ed0-9e80-aaa7633aa493
    E: ID_FS_UUID_ENC=bb024e1b-78a5-4ed0-9e80-aaa7633aa493
    E: ID_FS_VERSION=1
    E: ID_MODEL=SAMSUNG_HD103SI
    E: ID_MODEL_ENC=SAMSUNG\x20HD103SI\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
    E: ID_PART_ENTRY_TYPE=0x83
    E: ID_PART_TABLE_TYPE=dos
    E: ID_PATH=pci-0000:00:09.0-scsi-3:0:0:0
    E: ID_PATH_TAG=pci-0000_00_09_0-scsi-3_0_0_0
    E: ID_REVISION=1AG01131
    E: ID_SCSI_COMPAT=SATA_SAMSUNG_HD103SIS1VSJ1LS301247
    E: ID_SERIAL=SAMSUNG_HD103SI_S1VSJ1LS301247
    E: ID_SERIAL_SHORT=S1VSJ1LS301247
    E: ID_TYPE=disk
    E: ID_WWN=0x50024e900136a03e
    E: ID_WWN_WITH_EXTENSION=0x50024e900136a03e
    E: MAJOR=8
    E: MINOR=97
    E: PART_ENTRY_DISK=8:96
    E: PART_ENTRY_NUMBER=1
    E: PART_ENTRY_OFFSET=63
    E: PART_ENTRY_SCHEME=dos
    E: PART_ENTRY_SIZE=1953520002
    E: SUBSYSTEM=block
    E: UDEV_LOG=3
    E: UDISKS_PARTITION=1
    E: UDISKS_PARTITION_ALIGNMENT_OFFSET=0
    E: UDISKS_PARTITION_NUMBER=1
    E: UDISKS_PARTITION_OFFSET=32256
    E: UDISKS_PARTITION_SCHEME=mbr
    E: UDISKS_PARTITION_SIZE=1000202241024
    E: UDISKS_PARTITION_SLAVE=/sys/devices/pci0000:00/0000:00:09.0/host3/target3:0:0/3:0:0:0/block/sdg
    E: UDISKS_PARTITION_TYPE=0x83
    E: UDISKS_PRESENTATION_NOPOLICY=0
    E: USEC_INITIALIZED=6897248001
    OK, there is the serial.... but the problem persists - udev doesn't execute the rule and doesn't create /dev/aluguard.

  • Problem with udev rule to disable touchpad when USB mouse connects

    Hi, I've been running Arch on this laptop, but I can't get this udev rule to work properly.
    What I want to happen is: when I plug in my usb mouse, the laptop touchpad is disabled, and the left and right buttons are reversed (I'm left handed)
    After following several tutorials, both from the arch wiki and other sites, I've come up with this udev rule:
    ACTION=="add", SUBSYSTEM=="input", RUN+="/usr/local/bin/USBMouse.sh"
    ACTION=="remove", SUBSYSTEM=="input", RUN+="/usr/local/bin/USBMouse.sh"
    And here's the script it links to (USBMouse.sh):
    #!/bin/bash
    export DISPLAY=:0.0
    synclient TouchPadOff=$(/usr/bin/lsusb | grep "Microsoft Corp.\
    Nano Transceiver v1.0 for Bluetooth" | wc -l)
    if [[ $(/usr/bin/lsusb | grep "Microsoft Corp.\
    Nano Transceiver v1.0 for Bluetooth" | wc -l) == 1 ]]
    then
    xmodmap -e 'pointer = 3 2 1'
    fi
    if [[ $(/usr/bin/lsusb | grep "Microsoft Corp.\
    Nano Transceiver v1.0 for Bluetooth" | wc -l) == 0 ]]
    then
    xmodmap -e 'pointer = 1 2 3'
    fi
    Running the script from a terminal returns no errors and works as expected. The problem is when I plug/unplug the mouse from the usb port, nothing happens.
    I appreciate any insight you might have about how to fix this, and thank you in advance

    This has already been done. And another relevant thread.

  • [SOLVED]system fails to boot since adding udev rules for automounting

    Hello
    I have recently been trying to use udev rules to automount, and putting together stuff from the wiki, forums and general googling around have produced the following set of rules:
    # automounts usb hdd and pendrives as usbhd-sdx; no messing around with
    # volume labels or other confusing stuff
    # matches all sdx devices except the internal hdd, sda
    KERNEL=="sd[b-z]", NAME="%k", SYMLINK+="usbhd-%k", GROUP="users", OPTIONS="last_rule"
    # imports filesystem information
    ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"
    # creates mount points and sets up symlinks
    ACTION=="add", KERNEL=="sd[b-z][0-9]", SYMLINK+="usbhd-%k", GROUP="users", NAME="%k"
    ACTION=="add", KERNEL=="sd[b-z][0-9]", RUN+="/bin/mkdir -p /media/usbhd-%k"
    ACTION=="add", KERNEL=="sd[b-z][0-9]", RUN+="/bin/ln -s /media/usbhd-%k /mnt/usbhd-%k"
    # global mount options
    ACTION=="add", ENV{mount_options}="relatime"
    # filesystem-specific mount options (777/666 dir/file perms for ntfs/vfat)
    ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},gid=100,dmask=000,fmask=111,utf8"
    # automount ntfs filesystem with ntfs-3g driver
    ACTION=="add", KERNEL=="sd[b-z][0-9]", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/mount -t ntfs-3g -o %E{mount_options} /dev/%k /media/usbhd-%k", OPTIONS="last_r$
    # automount all other file systems
    ACTION=="add", KERNEL=="sd[b-z][0-9]", ENV{ID_FS_TYPE}!="ntfs", RUN+="/bin/mount -t auto -o %E{mount_options} /dev/%k /media/usbhd-%k", OPTIONS="last_rule"
    # unmounts and removes the mount points
    ACTION=="remove", KERNEL=="sd[b-z][0-9]", RUN+="/bin/rm -f /mnt/usbhd-%k"
    ACTION=="remove", KERNEL=="sd[b-z][0-9]", RUN+="/bin/umount -l /media/usbhd-%k"
    ACTION=="remove", KERNEL=="sd[b-z][0-9]", RUN+="/bin/rmdir /media/usbhd-%k", OPTIONS="last_rule"
    This seemed to be working very well unitl I tried to boot this morning and the boot process stopped at "processing UDev events" with the following message:
    iTCO_wdt: Unexpected close, not stopping watchdog!
    It pauses at this point for 10-15 seconds and then reboots.
    Having searched a bit, I found the following similar post on the forums:  http://bbs.archlinux.org/viewtopic.php?pid=459375
    Which suggests that the problem might lie with this line:
    ACTION=="add", IMPORT{program}="/sbin/blkid -o udev -p %N"
    I have renamed the file so that it no longer has the udev .rules extension and now the system boots fine.  Does anyone have any suggestions as to why the above rules might be causing this behaviour and how I might go about fixing it?
    Thanks
    Last edited by useradded (2010-07-02 22:58:14)

    Hey falconindy
    That was the final kick up the logical a$$ that I needed to get some kind of grip on udev rules.  I now have a fully functional rule that applies only to /dev/sdxy and not to everything else as well, so no more boot trauma, THANK YOU.
    I will mark this thread as solved and post my new rule for the benefit of anyone who might read this.
    New rule (no boot problems):
    # automounts usb hdd and pendrives as label or as usbhd-sdxy if no label present
    # ensures the following is _only_ run for sdxy devices excluding internal hdd, sda
    KERNEL!="sd[b-z][0-9]", GOTO="personal_usb_automount_settings_end"
    # imports filesystem information
    # provides access to following variables:
    # ID_FS_UUID; ID_FS_UUID_ENC; ID_FS_VERSION; ID_FS_TYPE; ID_FS_VERSION; ID_FS_LABEL
    # accessible via ENV{variable}; $env{variable}|%E{variable}
    IMPORT{program}="/sbin/blkid -o udev -p %N"
    # Get a label if present, otherwise name usbhd-%k
    ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}"
    ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k"
    # creates mount points and sets up symlinks
    ACTION=="add", SYMLINK+="%E{dir_name}", GROUP="users", NAME="%k"
    ACTION=="add", RUN+="/bin/mkdir -p /media/%E{dir_name}"
    ACTION=="add", RUN+="/bin/ln -s /media/%E{dir_name} /mnt/%E{dir_name}"
    # global mount options
    ACTION=="add", ENV{mount_options}="relatime"
    # filesystem-specific mount options (777/666 dir/file perms for ntfs/vfat)
    ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},gid=100,dmask=000,fmask=111,utf8"
    # automount ntfs filesystem with ntfs-3g driver
    ACTION=="add", ENV{ID_FS_TYPE}=="ntfs", RUN+="/bin/mount -t ntfs-3g -o %E{mount_options} /dev/%k /media/%E{dir_name}", OPTIONS="last_rule"
    # automount all other file systems
    ACTION=="add",ENV{ID_FS_TYPE}!="ntfs", RUN+="/bin/mount -t auto -o %E{mount_options} /dev/%k /media/%E{dir_name}", OPTIONS="last_rule"
    # unmounts and removes the mount points
    ACTION=="remove", RUN+="/bin/rm -f /mnt/%E{dir_name}"
    ACTION=="remove", RUN+="/bin/umount -l /media/%E{dir_name}"
    ACTION=="remove", RUN+="/bin/rmdir /media/%E{dir_name}", OPTIONS="last_rule"
    # exit
    LABEL=="personal_usb_automount_settings_end"
    Last edited by useradded (2010-07-02 22:59:20)

  • Udev rules not applied during bootup

    I don't know if this problem is associated with the lates kernel-upgrade to 2.6.21 but I didn't have it before.
    My problem:
    I have an external USB-harddrive that gets mounted everytime I boot because it is listed in my fstab. To avoid confusion with other external storages (such as USB-sticks etc.) I worte an udev rule for it:
    # Externe USB-Festplatte von TrekStor
    BUS=="usb", KERNEL=="sd?1" SYSFS{serial}=="307541703010",SYMLINK+="externe"
    As I've said this worked well before but now I get a message during the booting process saying that /dev/externe couldn't be found. But it actually IS recognised by udev. I just have to do a
    mount -a
    after the booting process and everything works again.
    Does anyone have an idea what the problem could be? It seems to me that all the devices listed in fstab get mounted before the udev rules are applied.

    Ok, I solved my problem: I'm not mounting my USB-HD through fstab anymore. I'm using udev-rules as described here.
    Still I'd be interesting to know what went wrong.
    Last edited by mata_svada (2007-05-21 05:11:06)

  • UDev rules as packages?

    Hi everyone!
    I've a Shuttle-Barebone with a LCD display for Freevo. Freevo includes a plugin to access this LCD display and shows some status information, unfortunately the permissions on the device are to restrictive.
    To remedy the problem I've written (or better adapted) an udev rule to give users the permissions to write to the device:
    /etc/udev/rules.d/82-vfd.rules:
    SYSFS{idVendor}=="051c", SYSFS{idProduct}=="0005", MODE="0666", GROUP="users"
    Is this a good way to give permissions, and would it be a good idea to provide a package in AUR with this, and similar, rules?
    Thanks!

    IMO a package is overkill for udev rules, unless you find yourself with dozens of them. Even then, they are likely to be specific to your requirements, and may not be of interest to many other users.
    Just my €0.02 though - go ahead with the package if you wish.

  • Udev update: udev.rules file contains errors [was: dbus+hal update]

    I am aware of the fact that there are already a few topics and a bug report (http://bugs.archlinux.org/task/6351) concerning the recent dbus & hal upgrades. However, my case seems different and more complex. I am not even sure if this is directly related to the others' issues.
    Since the update to dbus-1.0.2-2 my system does not follow some dbus rules any more. The recent follow-up update to dbus-1.0.2-3 did not remedy my problems, either.
    I think that this is due to the /etc/udev/rules.d/udev.rules file having become corrupted with the recent updates. Under the sections
    #pty and tty legacy devices
    and
    #vc devices
    several KERNEL=[...] lines have errors, at least the final double quotation marks are missing!
    So far my problems are as follows:
    - Intel i810 video driver fails to load: "No matching device [...] found".
    - Thinkpad's nvram is not get created in /dev
    - no pty devices / no ttyp devices are created in /dev. Therefore, none of my X-based consoles will start. Konsole, for example, exits with "Konsole is unable to open a PTY [...]".
    I will investigate further and report. Anyone eslse experiencing similar problems?
    Btw., contrary to the experience of others, removable devices are recognized and mounted.
    Last edited by mutlu_inek (2007-02-07 02:52:34)

    Those errors I found were actually introduced a few days ago by udev-105-1! The /etc/udev/rules.d/udev.rules provided by that package has errors!
    Correcting those errors brought back my beloved pseudo teletypes in /dev/pts/X. But the nvram device is still not created.
    Update:
    Here is the diff output of udev-105-1's udev.rules compared with what it should be:
    --- udev.rules 2007-02-06 21:20:06.000000000 -0500
    +++ udev.rules_corrected 2007-02-06 21:16:36.000000000 -0500
    @@ -143,8 +143,8 @@
    SUBSYSTEMS=="scsi", KERNEL=="sg[0-9]*", ATTRS{type}=="6", GROUP="scanner"
    # pty and tty legacy devices
    -KERNEL=="pty[a-z][a-z,0-9]*", NAME="legacy/%k", OPTIONS="last_rule
    -KERNEL=="tty[a-z][a-z,0-9]*", NAME="legacy/%k", OPTIONS="last_rule
    +KERNEL=="pty[a-z][a-z,0-9]*", NAME="legacy/%k", OPTIONS="last_rule"
    +KERNEL=="tty[a-z][a-z,0-9]*", NAME="legacy/%k", OPTIONS="last_rule"
    # md block devices
    KERNEL=="md[0-9]*", NAME="md%n", SYMLINK+="md/%n"
    @@ -166,8 +166,8 @@
    KERNEL=="vcs[0-9]*", NAME="vcc/%n", OPTIONS="last_rule"
    KERNEL=="vcsa", NAME="vcc/a0", OPTIONS="last_rule"
    KERNEL=="vcsa[0-9]*", NAME="vcc/a%n", OPTIONS="last_rule"
    -KERNEL=="ptmx", MODE="0666", OPTIONS="last_rule
    -KERNEL=="tty", MODE="0666", OPTIONS="last_rule
    +KERNEL=="ptmx", MODE="0666", OPTIONS="last_rule"
    +KERNEL=="tty", MODE="0666", OPTIONS="last_rule"
    # video devices
    SUBSYSTEM=="video4linux", GROUP="video"
    Last edited by mutlu_inek (2007-02-07 02:44:24)

  • Trying to disable a Udev rule. Deleting it is not working.

    I am trying to configure my sound. I have a usb sound card I want it to be default.
    I followed the procedure as described here .
    So, my default soundcard was my usb soundcard!
    But, did this,
    Hot-plugging a USB sound card
    The following udev rule can be used to automatically make a USB sound card the primary output device when the card is plugged in. To do so, create the following file with the specified contents and.
    /etc/udev/rules.d/00-local.rules
    KERNEL=="pcmC[D0-9cp]*", ACTION=="add", PROGRAM="/usr/bin/sh -c 'K=%k; K=$${K#pcmC}; K=$${K%%D*}; echo defaults.ctl.card $$K > /etc/asound.conf; echo defaults.pcm.card $$K >>/etc/asound.conf'"
    KERNEL=="pcmC[D0-9cp]*", ACTION=="remove", PROGRAM="/usr/bin/sh -c 'echo defaults.ctl.card 0 > /etc/asound.conf; echo defaults.pcm.card 0 >>/etc/asound.conf'"
    For information regarding loading udev rules see the following: Udev#Loading_new_rules
    But it was a mistake.. So, I wanted to correct this. I deleted this file.
    rm -rf /etc/udev/rules.d/00-local.rules
    after that, as mentioned here
    udevadm control --reload
    udevadm trigger
    After reboot, I was having again the file
    /etc/asound.conf
    which is created after the rule is triggered.
    So, what can i Do ?

    MoonSwan wrote:
    I may be mis-understanding your problem, zabrielza, so please correct me if I am off base here.
    You have 2 soundcards, yes?  One is a HDA Intel on-board and the other is your USB card.  You want the USB card to be the default all the time, correct?  If that is true then I suggest using this little part of the Alsa Wiki article to set your default card: https://wiki.archlinux.org/index.php/Ad … sound_card  I have used that part of the wiki successfully to set my default card, as I also have two sound cards, and I've had few issues since then. 
    As I said when I began this post, I may be wrong here so please say so if I am.  You might also want to start over and re-state exactly what your goal is because I see some posters are confused about what it is you're trying to accomplish.
    Yes you are right. You described my situation perfectly.  Firstly I started this topic to learn/know How should i disable correctly udev rules. It turns out that my udev rule is disabled. I have this file
    /etc/modprobe.d/alsa-base.conf
    configured correctly. Before I create the rule I had sound correctly but I never followed this.
    Select the default PCM via environment variable
    In your configuration file, preferably global, add:
    pcm.!default {
        type plug
        slave.pcm {
            @func getenv
            vars [ ALSAPCM ]
            default "hw:Audigy2"
    You need to replace the default line with the name of your card (in the example is Audigy2). You can get the names with aplay -l or you can also use PCMs like surround51. But if you need to use the microphone it is a good idea to select full-duplex PCM as default.
    Now you can start programs selecting the sound card just changing the environment variable ALSAPCM. It works fine for all program that do not allow to select the card, for the others ensure you keep the default card. For example, assuming you wrote a downmix PCM called mix51to20 you can use it with mplayer using the commandline ALSAPCM=mix51to20 mplayer example_6_channel.wav
    Instead of using new variables, you could set one of those mentioned in default global configuration.
    /usr/share/alsa/alsa.conf
    Variable name # Definition
    ALSA_CARD # pcm.default pcm.hw pcm.plughw ctl.sysdefault ctl.hw rawmidi.default rawmidi.hw hwdep.hw
    ALSA_CTL_CARD # ctl.sysdefault ctl.hw
    ALSA_HWDEP_CARD # hwdep.default hwdep.hw
    ALSA_HWDEP_DEVICE # hwdep.default hwdep.hw
    ALSA_PCM_CARD # pcm.default pcm.hw pcm.plughw
    ALSA_PCM_DEVICE # pcm.hw pcm.plughw
    ALSA_RAWMIDI_CARD # rawmidi.default rawmidi.hw
    ALSA_RAWMIDI_DEVICE # rawmidi.default rawmidi.hw
    Note: Pay attention to default addressing type.
    So, Should I try it now? Do I have to reset alsa-installation first ( I do not know how to do this ) or not?

  • Udev rules and group / permission errors [solved] [outdated]

    Latest udev is a miracle to me. It ignores every group ore permission settings. Anyone else having same experiences?
    Last edited by Moo-Crumpus (2008-09-29 05:17:40)

    Let's assume that you have two files with udev rules. The basic udev.rules and 00.udev.rules (with custom rules).
    Udev first reads all rules from 00 file and then rules from the basic file.
    This means that if you have a custom rule for a given device you should copy all rules that apply to it from the basic file to the 00 file (not only lines with GROUP). This is because with OPTIONS="last_rule" udev will stop processing rules for this device.
    All rules are read and then applied in the order from the top to bottom except SUBSYTEM which is applied as the last rule (kind of held in a buffer). This is the reason why my cd burner /dev/hdc had permissions for disk group and not optical.
    This is my 00.udev.rules (it still needs some cosmetic changes but it works and of course I don't have all the devices):
    SUBSYSTEM="video4linux", GROUP="users"
    SUBSYSTEM="sound", GROUP="users"
    SUBSYSTEM="printer", GROUP="users"
    SUBSYSTEM="block", GROUP="disk"
    BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
    BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-devfs.sh %k %b %n", SYMLINK="%c{1} %c{2}"
    BUS="ide", KERNEL="hdc", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="users", SYMLINK="nagrywarka dvd cdrw", OPTIONS="last_rule"
    BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", GROUP="users", OPTIONS="last_rule"
    BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-floppy.sh %k", RESULT="floppy", NAME{all_partitions}="%k", GROUP="users", OPTIONS="last_rule"
    BUS="scsi", KERNEL="sr[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
    BUS="scsi", KERNEL="scd[0-9]*", PROGRAM="/etc/udev/cdsymlinks.sh %k", SYMLINK="%c{1} %c{2} %c{3} %c{4} %c{5} %c{6}"
    BUS="scsi", KERNEL="sr[0-9]*", SYSFS{type}="5", NAME="scd%n", GROUP="users", OPTIONS="last_rule"
    BUS="scsi", KERNEL="sg[0-9]*", SYSFS{type}="5", NAME="%k", GROUP="users", OPTIONS="last_rule"
    KERNEL="fd[0-9]*", NAME="fd%n", GROUP="users", SYMLINK="floppy/%n fd%nu1440 fd%nu720 fd%nh1200 fd%nu360", OPTIONS="last_rule"
    BUS="usb", SYSFS{serial}="CN16J1Q3HWSX", KERNEL="lp[0-9]*", NAME="usb/%k", GROUP="users", SYMLINK="drukarka_hp_845c drukarka", OPTIONS="last_rule"
    BUS="usb", KERNEL="sd*", PROGRAM="/etc/udev/usb-storage.sh %k", RESULT="1", NAME="%k", GROUP="users", OPTIONS="last_rule"
    KERNEL="rtc", NAME="misc/%k", SYMLINK="%k", GROUP="users", MODE="0664", OPTIONS="last_rule"
    KERNEL="agpgart", NAME="misc/%k", SYMLINK="%k" GROUP="users", OPTIONS="last_rule"
    KERNEL="nvidia*", GROUP="users", OPTIONS="last_rule"
    KERNEL="fb[0-9]*", NAME="fb/%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="card[0-9]*", NAME="dri/%k", GROUP="users", OPTIONS="last_rule"
    KERNEL="3dfx*", NAME="%k", GROUP="users", OPTIONS="last_rule"
    KERNEL="dvb*", PROGRAM="/etc/udev/dvb.sh %k", NAME="%c", GROUP="users", OPTIONS="last_rule"
    KERNEL="video[0-9]*", NAME="v4l/video%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="radio[0-9]*", NAME="v4l/radio%n", GROUP="users", SYMLINK="radio%e", OPTIONS="last_rule"
    KERNEL="vbi[0-9]*", NAME="v4l/vbi%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="vtx[0-9]*", NAME="v4l/vtx%n", GROUP="users", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="controlC[0-9]*", NAME="snd/%k", OPTIONS="last_rule"
    KERNEL="hw[CD0-9]*", NAME="snd/%k", OPTIONS="last_rule"
    KERNEL="pcm[CD0-9cp]*", NAME="snd/%k", OPTIONS="last_rule"
    KERNEL="midi[CD0-9]*", NAME="snd/%k", OPTIONS="last_rule"
    KERNEL="timer", NAME="snd/%k", OPTIONS="last_rule"
    KERNEL="seq", NAME="snd/%k", OPTIONS="last_rule"
    KERNEL="audio*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="dmmidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="admmidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="dsp*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="adsp*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="midi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="amidi*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="mixer*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="sequencer*", NAME="sound/%k", SYMLINK="%k", OPTIONS="last_rule"
    KERNEL="pktcdvd", NAME="pktcdvd/control", GROUP="users", MODE="0660", OPTIONS="last_rule"
    KERNEL="pktcdvd[0-9]*", NAME="pktcdvd/pktcdvd%n", GROUP="users", MODE="0660", OPTIONS="last_rule"
    The problem with /dev/hdc was that first udev (version 057) was reading a rule from my 00 file (BUS="ide", KERNEL="hdc"...) with GROUP=users. Then it was reading SUBSYSTEM="block", GROUP="disk" rule from the basic file (but it wasn't executed at that time). And then it was reading BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1"... with GROUP=optical. Then it was executing SUBSYTEM rule (hdc is a block device). That's why only disk group had an access to /dev/hdc (with OPTIONS="last_rule" in the basic file in the GROUP="optical" line it would ignore SUBSYSTEM rule).
    There are also other rules that you should add (IMO) to your custom rules if  you are changing something. In my case it's for example BUS="ide", KERNEL="hd[a-z]", PROGRAM="/etc/udev/cdsymlinks.sh %k"... which creates symlinks for cd drives. This rule must be above other rules (the number of the symlinks is now unlimited - previously it was 5 IIRC).
    So now the rules are mixed together in the lexical order (except SUBSYTEM rules which are executed at the end) unless OPTIONS="last_rule" is used or second (and other) rule has a NAME filed (only one rule for a given device can have NAME filed. Every other rule for the same device with NAME field is ignored IIRC). It also means you can now split rules for a device into several rules - only one of them can have NAME filed and the last should have OPTIONS="last_rule".
    Since in your case you have custom rules only for a well defined usb devices (not /dev/sd*) IMO it should work as you think (only add OPTIONS="last_rule").
    I hope it's now perfectly clear  8) 

  • [SOLVED] automatic usb-backup with udev-rules + script

    I would like to have my usb-harddrive automatically start a backup as soon as it is plugged in.  And finally a bell is supposed to ring.
    I've created an udev-rule and a backup-script as shown below.
    However, instead of creating /dev/backup-drive first something strange is happening:
    The bell rings 3 times, followed by the backup, followed by a 4th ring.
    What's going on?
    Here's may udev-rule:
    ## /etc/udev/rules.d/95-backup.rules
    SUBSYSTEMS=="usb", ATTRS {serial}=="100", SYMLINK=="backup-drive", RUN+="/usr/local/bin/backup-thumb.sh"
    fstab:
    /dev/backup-drive    /media/backup   ext3     rw,user    0 0
    and my script:
    #!/bin/bash
    sleep 10
    rsync -vrtolgh --exclude '/.VirtualBox/' --delete /home/myhome /media/backup-drive
    aplay /usr/share/sounds/phone.wav
    Last edited by mehldutt (2007-07-03 20:28:27)

    The syntax of your udev rule is all wrong - for example after SYMLINK you should use "+=" or ":=". "==" is for comparing to some value.
    I think in rsync command line you want -H not -h (help) option. Also -v (verbose) is useless since you'll never see the output.
    Another thing which will prevent running rsync properly is /media/backup-drive while you use /media/backup in fstab.
    I suggest that you first try running rsync command from the command line "manually" and try if it works at all. After you'll make it work try the below suggestions.
    Another problem: what makes the backup drive mounted under /media/backup directory when you plug it into usb slot ? Are you doing it somehow "manually" in the 10 second period after plugging ? Do you use automounter of some kind ?
    If you intend to use ext3 as the backup drive filesystem you should also add sync command after rsync to make sure no data stays in RAM cache.
    I think you need to read udev manpage first.
    I can also advice you to read my udev rules for automounting usb devices (it's for any type of filesystem and any number of partitions):
    KERNEL=="sd[b-z]", NAME:="%k", SYMLINK+="usbhd-%k", GROUP:="users", OPTIONS="last_rule"
    ACTION=="add", KERNEL=="sd[b-z][0-9]", SYMLINK+="usbhd-%k", GROUP:="users", NAME:="%k"
    ACTION=="add", KERNEL=="sd[b-z][0-9]", RUN+="/bin/mkdir -p /media/usbhd-%k"
    ACTION=="add", KERNEL=="sd[b-z][0-9]", RUN+="/bin/ln -s /media/usbhd-%k /mnt/usbhd-%k"
    ACTION=="add", KERNEL=="sd[b-z][0-9]", PROGRAM=="/lib/udev/vol_id -t %N", RESULT=="vfat", RUN+="/bin/mount -t vfat -o rw,noauto,flush,dirsync,noexec,nodev,noatime,dmask=000,fmask=111 /dev/%k /media/
    usbhd-%k", OPTIONS="last_rule"
    ACTION=="add", KERNEL=="sd[b-z][0-9]", RUN+="/bin/mount -t auto -o rw,noauto,async,dirsync,noexec,nodev,noatime /dev/%k /media/usbhd-%k", OPTIONS="last_rule"
    ACTION=="remove", KERNEL=="sd[b-z][0-9]", RUN+="/bin/rm -f /mnt/usbhd-%k"
    ACTION=="remove", KERNEL=="sd[b-z][0-9]", RUN+="/bin/umount -l /media/usbhd-%k"
    ACTION=="remove", KERNEL=="sd[b-z][0-9]", RUN+="/bin/rmdir /media/usbhd-%k", OPTIONS="last_rule"
    I think it could be simplified and modified for your backup device like this:
    SUBSYSTEMS=="usb", ATTRS(idVendor)=="XXXX", ATTRS(idProduct)=="YYYY", KERNEL=="sd[a-z]", NAME:="%k", SYMLINK:="backupdevice", OPTIONS="last_rule"
    SUBSYSTEMS=="usb", ATTRS(idVendor)=="XXXX", ATTRS(idProduct)=="YYYY", ACTION=="add", KERNEL=="sd[a-z]1", SYMLINK:="backuppartition", GROUP:="users", NAME:="%k"
    SUBSYSTEMS=="usb", ATTRS(idVendor)=="XXXX", ATTRS(idProduct)=="YYYY", ACTION=="add", KERNEL=="sd[a-z]1", RUN+="/bin/mount -t auto -o rw,noauto,async,dirsync,noexec,nodev,noatime /dev/%k /media/backup-drive"
    SUBSYSTEMS=="usb", ATTRS(idVendor)=="XXXX", ATTRS(idProduct)=="YYYY", ACTION=="add", KERNEL=="sd[a-z]1", RUN+="/usr/local/bin/backup-thumb.sh", OPTIONS="last_rule"
    SUBSYSTEMS=="usb", ATTRS(idVendor)=="XXXX", ATTRS(idProduct)=="YYYY", ACTION=="remove", KERNEL=="sd[a-z]1", RUN+="/bin/umount -l /media/backup-drive", OPTIONS="last_rule"
    assuming that you have a single partition backup drive formatted as ext3 (or at least it's the first partition).
    Also another assumption is that idVendor and idProduct are unique to your backup drive. If not you should add some extra ATTRS parameters that will ensure this combination is unique.
    The directory /media/backup-drive must already exist (remove your fstab line - it's not needed in this case because mount command is run directly from the udev rule).
    Replace all XXXX and YYYY with the values from lsusb for your backup device - plug it in, run lsusb and copy values which look like XXXX:YYYY near to the name of your backup device.
    Anyway, you can play with different options and try to modify it yourself. The automounting rules work for me very well for some time (including flush option). The backup rules you need to test yourself :-)
    Last edited by lanrat (2007-05-05 17:20:51)

  • [solved] /etc/udev/rules.d/10-network.rules ignored

    Hi.
    I have 4 nics (eth0, eth1, eth2, eth3) mapped to MAC addresses in  /etc/udev/rules.d/10-network.rules.
    Some months ago, I had to symlink /etc/udev/rules.d/80-net-name-slot.rules to /dev/null in order to use these static names.
    Now it doesn't work anymore (again and again and again) after a full update (kernel and I assume systemd).  The "nic-names" are completely wrong.  You call this "predictable". I call this "unpredictable". The only thing which is predictable is that after a kernel update, the network will stop working. It has been that way for months and months ... fortunately I don't update other machines anymore.
    Was this non sense really necessary?
    Anyway, if you could tell me what to do now to get my network rules applied again, I would really appreciate.
    Right now all ethX/MAC are wrong and none of them gets an IP (had to set an IP manually to post here).
    * I know what "predictable Network Interface Names" is about. I don't want this bullshit. It's much worse as it used to be. Keep it simple, folks!
    Last edited by Agnelo de la Crotche (2013-03-27 07:14:05)

    tomegun wrote:To narrow down the problem you are experiencing: What do you mean when you say that the names are "wrong"? Are they still eth0, eth1,... just in the wrong order, or are you actually seeing the "weird" new names given by udev?
    To answer this question more precisely.
    * with  /etc/udev/rules.d/80-net-name-slot.rules => /dev/nul and /etc/udev/rules.d/10-network.rules posted earlier  (in #4)
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    5: eth3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
    link/ether 66:64:b3:6a:26:61 brd ff:ff:ff:ff:ff:ff
    The rules are ignored.
    * after deleting   /etc/udev/rules.d/80-net-name-slot.rules
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: enp6s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    3: enp6s1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    4: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    5: enp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
    link/ether a2:ee:ec:d1:65:2d brd ff:ff:ff:ff:ff:ff
    The rules don't apply.
    * with  /etc/udev/rules.d/80-net-name-slot.rules => /dev/nul and after replacing eth0, eth1, eth2, eth3 with arbitrary names net0, net1, net2, net3 in  /etc/udev/rules.d/10-network.rules
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    2: net1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:24:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    3: net3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:0a:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    4: net2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:06:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    5: net0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000
    link/ether 00:1b:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT
    link/ether ea:63:09:b7:1b:1b brd ff:ff:ff:ff:ff:ff
    But the rules were applied in this case!
    It solved the problem described originally.  I think I was hit by the race condition after upgrating to kernel 3.8.4-1. This was actually my first 3.8 kernel.
    With kernel 3.7, the rules were working even if the devices were named eth0, eth1, etc.
    Those names don't work anymore, at least in my case.
    Further I  created this file for static ips:
    # cat /etc/systemd/system/network.service
    [Unit]
    Description=Wired Static IP Connectivity
    Wants=network.target
    Before=network.target
    BindsTo=sys-subsystem-net-devices-net0.device
    After=sys-subsystem-net-devices-net0.device
    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStart=/sbin/ip link set dev net0 up
    ExecStart=/sbin/ip addr add 192.168.101.9/24 dev net0
    ExecStart=/sbin/ip link set dev net1 up
    ExecStart=/sbin/ip addr add 192.168.102.9/24 dev net1
    ExecStart=/sbin/ip link set dev net2 up
    ExecStart=/sbin/ip addr add 192.168.104.9/24 dev net2
    ExecStart=/sbin/ip link set dev net3 up
    ExecStart=/sbin/ip addr add 192.168.105.9/24 dev net3
    ExecStart=/sbin/ip route add default via 192.168.101.1
    ExecStop=/sbin/ip addr flush dev net0
    ExecStop=/sbin/ip link set dev net0 down
    ExecStop=/sbin/ip addr flush dev net1
    ExecStop=/sbin/ip link set dev net1 down
    ExecStop=/sbin/ip addr flush dev net2
    ExecStop=/sbin/ip link set dev net2 down
    ExecStop=/sbin/ip addr flush dev net3
    ExecStop=/sbin/ip link set dev net3 down
    [Install]
    WantedBy=multi-user.target
    I disabled netcfg and enabled network.service.
    Problem is solved now.

  • [SOLVED] udev rule launch graphical app

    How can I make a udev rule launch a graphical application, like, for instance, feh?
    I've tried creating a rule detects when a specific mass storage device is connected and executes a script (/root/.scripts/feh-camera.sh). The script exports DISPLAY and XAUTHORITY and everything seems to work.
    However when I restarted a black screen appeared right after Loading Modules (that appears after Starting udev events). Removing the udev rule solved the problem, so I must be doing something wrong.
    What's the right way of doing this?
    Thanks in advance.
    Last edited by Vieira (2010-05-06 22:38:49)

    Device was not connected at boot but I'll try what you suggested anyway. Thanks for your help.
    EDIT:
    It's solved. It turns out the underlying problem was that exporting DISPLAY breaks the udev environment. For future reference solved it with:
    45-foobar.rules
    ATTRS{product}=="DSLR-A330", ATTR{removable}=="1", ENV{REMOVE_CMD}="/bin/umount /media/camera", RUN+="/bin/mount <bla bla>", RUN+="/bin/su vieira -c '/etc/udev/rules.d/45-foobar.sh'"
    and the script, where the problem was, must not export anything, just set inline, i.e.
    #!/bin/sh
    HOME=/home/vieira DISPLAY=:0 /usr/bin/feh -r /mnt/camera
    Last edited by Vieira (2010-05-06 22:35:39)

  • Udev rule question.

    Hello,
      I have written a udev rule to change the name of the external hard disk to /dev/external.
    SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{model}=="ST3120827AS", NAME="external"
    The code is like the above. That works also. But the problem is that. without that rule my device creates 2 device nodes.
    1. sdb for the drive
    2. sdb1 for the one partition in it.
      The mount command without the rule will show that the device sdb1 is mounted on /media. But after adding that rule only one device node is created at /dev/external and there is no second device like I expected ( ie /dev/external1 ). Why it is like that ? Any idea ?
      Is there anything wrong in my udev rule ?

    try this:
    SUBSYSTEM=="block", SUBSYSTEMS=="scsi", ATTRS{model}=="ST3120827AS", KERNEL=="sd*", SYMLINK+="external%n"

Maybe you are looking for