Tag Info

New answers tagged

0

From insmod manpage: insmod is a trivial program to insert a module into the kernel. Most users will want to use modprobe(8) instead, which is more clever and can handle module dependencies. pcnet32 module depends on mii module, which is not loaded when you load pcnet32 using insmod. modprobe pcnet32 should solve the problem. Alternatively you can ...


0

Disable your Network Manager and Configure the devices using files defined in /etc/network/interfaces you can also rename the device name using udev rules as Using Udev rules to rename the devices cd /etc/udev/rules.d/ cat 70-persistent-net.rules edit the 70-persistent-net.rules to change the name of PCI Devices in your case USB device and connect it ...


0

Version 220-7 on Debian dropped the patch that made this opt-in: * Switch to net.ifnames persistent network interfaces (on new installations/for new hardware), and deprecate the old 75-persistent-net-generator.rules. This came about from a proposal in debian-devel list. Systems which were using the old naming won't be renamed until the user migrates. ...


-1

Ubuntu 15 uses biosdevname which doesn't provide predictable network interface names. Even if you remove it (apt-get remove biosdevname) and edit grub (GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=1") and the persistent rules, you still don't get predicatble network interaces. The main reason seems to be backward compatibility. I tested it just now with 2 ...


1

I found solution to (a) atleast. I need to run udevadm test <sys_path_of_Device> This command will run in dry-mode, but will give the correct pointer to rules file.


0

The only issue was that after the product ID the '*' is still required, so in the end the rule looked like: keyboard:usb:v11AAp11AA* [remapping rules] Simple syntax error.


0

I think the command you're looking for here is udevadm. You'll use the trigger and test parameters to trigger a rescan of the udev events, and to test a specific event, respectively. I learned this the hard way when putzing around with the new network device naming in EL 7. Good luck!


0

The scancodes for usb keyboards are not what you would expect, they are not the output of showkey -s. Instead you pretty much have to use evtest to get the scancodes you need. Example output from evtest: Event: time 1399420905.069693, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70004 Event: time 1399420905.069693, type 1 (EV_KEY), code 30 (KEY_A), value 1 ...


0

My issue was putting the wrong scancode, the rule shouldn't be keyboard_key_1b=playcd but keyboard_key_7003a=playcd You really do require evtest for this (the 'scancodes' provided by showkey -s is not the one you're looking for)


0

For those who, for whatever reason, don't want to take the hotplug route, it is still possible to not poll within a script using inotifywait: #!/bin/bash SCREEN_LEFT=DP2 SCREEN_RIGHT=eDP1 START_DELAY=5 renice +19 $$ >/dev/null sleep $START_DELAY OLD_DUAL="dummy" while [ 1 ]; do DUAL=$(cat /sys/class/drm/card0-DP-2/status) if [ "$OLD_DUAL" != ...


1

For those who, for whatever reason, don't want to take the hotplug route, it is still possible to not poll within a script using inotifywait: #!/bin/bash SCREEN_LEFT=DP2 SCREEN_RIGHT=eDP1 START_DELAY=5 renice +19 $$ >/dev/null sleep $START_DELAY OLD_DUAL="dummy" while [ 1 ]; do DUAL=$(cat /sys/class/drm/card0-DP-2/status) if [ "$OLD_DUAL" != ...


0

ATTR{address}=="AA-12-00-00-2B-8B" is not a valid MAC address (replace the - with dots and uppercase with lowercase letters), so the first rule will never match. Fix this and they should work reliably. Anyway, on modern systems (like current RHEL and the next Debian and Ubuntu releases) you cannot rename an interface to a name in one of the kernel ...


2

It appears that the ENV variables are pretty free-form and bound to devices. The only enforced restrictions is that none of these keys may be be used: ACTION, SUBSYSTEM, DEVTYPE, MAJOR, MINOR, DRIVER, IFINDEX, DEVNAME, DEVLINKS, DEVPATH, TAGS. Other than that, interpretation of the environment variables is left to other rules and programs. Use grep -rni ...


1

I can confirm that smstools will not start without the device name at all. So this wont work: devices = GSM* #device = /dev/ttyACM0 You could add both device, but that's not the right solution either. When you have ACM1 and ACM0 used by the smstools then what happen? Yes you wont have the phone available for calls/sms. I could not find the right solution ...


3

I am not sure if this applies, and this is definitely an older post but it came up pretty high my web search for udev info so I thought I might share some knowledge. You can trigger udev rules manually for specific devices. This applies only to redhat-related distros (centos fedora etc etc etc) Once you make the relevant changes in your rules file ...


0

The problem is that udev was not started. /etc/init.d/udev start Conclusion: in case someone experiences any issue related to udev, firstly make sure it has been started.



Top 50 recent answers are included