| View previous topic :: View next topic |
| Author |
Message |
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
 Posted: Tue Jul 15, 2014 11:58 am Post subject: udev to eudev - error messages in syslog-ng |
 |
|
Hi guys,
I just changed from udev to eudev following the recipe suggested by Tractor Girl here. The system (it is a virtual machine under xen) boots after that, but in my syslog I find a few error messages about two invalid keys resulting in invalid rules which were not there before the switch: | Code: | Jul 15 13:30:24 master kernel: 2.784032] udevd[227]: starting version 1.9
Jul 15 13:30:24 master kernel: [ 2.838949] random: udevd urandom read with 99 bits of entropy available
Jul 15 13:30:24 master kernel: 2.885825] udevd[227]: unknown key 'SYSFS{hardware_id}' in /lib64/udev/rules.d/dahdi.rules:11
Jul 15 13:30:24 master kernel: 2.885832] udevd[227]: invalid rule '/lib64/udev/rules.d/dahdi.rules:11'
Jul 15 13:30:24 master kernel: 2.885839] udevd[227]: unknown key 'SYSFS{location}' in /lib64/udev/rules.d/dahdi.rules:12
Jul 15 13:30:24 master kernel: 2.885843] udevd[227]: invalid rule '/lib64/udev/rules.d/dahdi.rules:12' |
The dahdi.rules file reads as follows (referenced lines marked for easy finding with ==> at the start of the line): | Code: |
ACTION!="add", GOTO="dahdi_add_end"
# DAHDI devices with ownership/permissions for running as non-root
SUBSYSTEM=="dahdi", OWNER="asterisk", GROUP="dialout", MODE="0660"
# Backward compat names: /dev/dahdi/<channo>
SUBSYSTEM=="dahdi_channels", SYMLINK+="dahdi/%m"
# Add persistant names as well
==> SUBSYSTEM=="dahdi_channels", SYSFS{hardware_id}!="", SYMLINK+="dahdi/devices/%s{hardware_id}/%s{local_spanno}/%n"
==> SUBSYSTEM=="dahdi_channels", SYSFS{location}!="", SYMLINK+="dahdi/devices/@%s{location}/%s{local_spanno}/%n"
LABEL="dahdi_add_end"
# hotplug scripts
SUBSYSTEM=="dahdi_devices", RUN="%E{DAHDI_TOOLS_ROOTDIR}/usr/share/dahdi/dahdi_handle_device"
SUBSYSTEM=="dahdi_spans", RUN="%E{DAHDI_TOOLS_ROOTDIR}/usr/share/dahdi/dahdi_span_config" |
Interesting enough dahdi is not active in this virtual machine, so those rules should not fire at all for this virtual machine.
Any ideas what went wrong? Thanks Atom2 |
|
| Back to top |
|
 |
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Jul 15, 2014 9:08 pm Post subject: |
|
|
It appears that asterisk/dahdi had brought in some old/deprecated rules back when I installed it some months ago already. I had to make changes as follows: | Code: | SYSFS{hardware_id} -> ATTR{hardware_id}
SYSFS{location} -> ATTR{location} |
to get rid of the error message.
Still I am however not clear on a few things:
1.) Why did those error messages not show up on my (old) systemd-udevd-212 version which I had used up to today before I changed over to eudev-1.9. Incidentially moving to eudev was my only change today.
2.) While the change to ATTR got rid of the error message, I am not completely sure whether the right change would be for ATTR{...} or ATTRS{...}
Another glitch that I was able to solve with ssuominen's help on the IRC chat was that the new eudev (this time in my xen dom0 - the other stuff I experienced in my domU xen guest systems) logged numerous error message like the following to my syslog: | Code: | Jul 15 21:28:55 vm-host kernel: 12.609949] udevd[361]: failed to execute '/lib/udev/socket:/org/xen/xend/udev_event' 'socket:/org/
xen/xend/udev_event': No such file or directory
Jul 15 21:28:55 vm-host kernel: 12.610044] udevd[360]: failed to execute '/lib/udev/socket:/org/xen/xend/udev_event' 'socket:/org/
xen/xend/udev_event': No such file or directory |
Those were triggered by an (and obsolete) xend.rules file in /lib64/udev/rules.d - but then again, the old version (systemd-udevd-212) did not complain about this unnecessary file or did not try to fire those rules respectively. So there seems to be some discrepancy between systemd-udevd and eudev and contrary to common believe it's not always a simple plugin replacement, although so far nothing too drastic has poped up.
The final issue that I was faced with was the network: eudev sticked to eth0, but my old systemd-udevd had used a name of enp0s25 instead and that was what my /etc/init.d net rules relied upon. It took me a bit to figure out that eudev (or something during the upgrade/change emerge prcoess) had created a new rule under /etc/udev/rules.d/70-persistent-net.rules as follows: | Code: | # This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x1502 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:7d:1d:72:74", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" |
I changed the value of NAME to enp0s25 to get back to the old behaviour - although I am neither sure whether that's the proper way to do it nor why/how the old systemd-udevd-212 automatically came up with enp0s25 (i.e. in which rules file that was recorded).
I guess I need to amend that rule for any new network interface as I actually don't mind the new behaviour with names like enpXsY instead of ethX.
At least the system's netwotk is working again. If there's a better/recommended option to return to my original name, I am happy if somebody could point me towards that.
Regards Atom2 |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Thu Jul 17, 2014 12:52 pm Post subject: |
|
|
Although this thread seems pretty much to be a one-way conversation, I'll nevertheless provide another answer to one point raised in my previous post, namely the one called "final issue" regarding the network naming and the proper way to re-solve this.
It seems as if the renaming of enp0s25 to eth0 through a custom rule under /etc/udev/rules.d was triggered by the default USE flags selected by the package install. The relevant USE flag is "rule-generator". Once i disabled that USE flag (through /etc/portage/package.use) and re-emeged eudev the renaming of enp0s25 to eth0 did no longer happen. Also the auto-generated (and self-modified to what is shown in my previous post) rule under /etc/udev/rules.d/70-persistent-net.rules was no longer required.
So in a nutshell: Tractor Girl's advice originally posted here as follows | Tractor Girl wrote: | Here's little how to:
| Code: | emerge -avC udev
emerge -av eudev
/etc/init.d/udev --nodeps restart
rc-update add udev-postmount default |
optionally: | Code: | | emerge -av @preserved-rebuild |
|
is valid as long as you require/want to stick to the "old" naming conventions for network interfaces of ethX. This functionality is obviously provided through the rule-generator USE flag and by adding the udev-postmount runscript to default.
In case you prefer the "new" naming conventions for network interfaces (which is probably true for everybody switching from a standard, later version systemd-udev installation to eudev: Those people would most likely never have used ethX names for their network devices), you should therefore disable the "rule-generator" USE flag prior to emerging eudev in order to keep your network in a working state and also | Code: | | rc-update add udev-postmount default |
is no longer required; in fact the udev-postmount script will not even be emerged at all without the rule-generator USE flag.
Regards Atom2 |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Jul 18, 2014 1:43 am Post subject: |
|
|
| Using the predictable kernel names is enabled by simply not messing with the names in the first place. The kernel names the devices ethN, and it is up to userspace to rename them to anything else. If your devices are being renamed to enpXs0X and then back to eth0, you have two problems. It is a good bet that people switching to eudev are doing so specifically to get away from the braindead udev behaviors, in which case they probably have and want to keep predictable kernel names. |
|
| Back to top |
|
|
Cyker
Veteran
Joined: 15 Jun 2006
Posts: 1746
|
| Posted: Fri Jul 18, 2014 8:17 am Post subject: |
|
|
Great research Atom2, and thanks for posting back your solutions and findings 
I kinda tripped over this when I was building a new Gentoo box, but the other way around (All the scripts etc. I was porting over were written with eth0, eth1 etc. in mind and I was banging my head against a wall trying to figure out why udev refused to rename my NICs so I wouldn't have to go through all of them  )
I found in the current udev they don't support the ethX naming convention at all and have this awkward enp0s25-type naming system, which is (supposed) to be persistent (i.e. stay the same and not change, which can happen if you let the kernel name the network devices, esp. if you're using modules or you upgrade the kernel!)
eudev (with rule-gen) behaves more like the older udevs, where it detects what name the kernel gives the network interface and then generates a rule so it sticks, and also still allows use of the ethX names. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Fri Jul 18, 2014 8:20 am Post subject: |
|
|
| Cyker wrote: | | I found in the current udev they don't support the ethX naming convention at all and have this awkward enp0s25-type naming system, which is (supposed) to be persistent (i.e. stay the same and not change, which can happen if you let the kernel name the network devices, esp. if you're using modules or you upgrade the kernel!) |
No, they are not supposed to be persistant, they are supposed to be predictable. There is a difference. If you change your hardware, move card from one slot to another, or add new card, or change BIOS setting, the name will change predictably, and is, thus, not persistant. |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Fri Jul 18, 2014 9:01 am Post subject: |
|
|
Hi Hu,
thanks for joining the party.
| Hu wrote: | | Using the predictable kernel names is enabled by simply not messing with the names in the first place |
That was exactly the behaviour up to system-udevd-212 (I did not try any later version): I sticked to the standard (i.e. no change to config files, therefore not messing with the names at all) and had predictable network names like enp0s25 and enp7s0 on my box which I could use and rely on through my /etc/init.d/net.{enp0s25,enp7s0} symlinks to /etc/init.d/net.lo - see extracts from my syslog below: | Code: | Jul 10 01:01:48 vm-host kernel: 11.882220] systemd-udevd[316]: starting version 212
Jul 10 01:01:48 vm-host kernel: 12.418986] systemd-udevd[344]: renamed network interface eth0 to enp0s25 |
Now the syslog output after emerging eudev has not changed substantially (only name and version) as you can see below: | Code: | Jul 17 16:51:12 vm-host kernel: 13.621168] udevd[316]: starting version 1.9
Jul 17 16:51:12 vm-host kernel: 14.008561] udevd[344]: renamed network interface eth0 to enp0s25 |
eudve renamed the network interface from the kernel's name of eth0 to the predictable network name enp0s25. So far so good. But my network did not come up. Upon investigation it turned out that eudev, installed as described by Tractor Girl (including adding udev-postmount to the default runlevel), and emerged with standard use flags as suggested by the package, had created the file /etc/udev/rules.d/70-persistent-net.rules (for its content please see my previous post) and this file - unknown to syslog, therefore no entry about the second rename can be found there - decided to change the name back to eth0.
| Hu wrote: | | If your devices are being renamed to enpXs0X |
that's what eudev and systemd-udev did (and do) automagically (see the extract from my logs) | Hu wrote: | | and then back to eth0 |
that's what the auto-gerenated rule in /etc/udev/rules.d/70-persistent-net.rules did - but only for eudev | Hu wrote: | | you have two problems |
you are right, there were indeed problems, although I only saw (and still see) one: and that was the autogenerated rules file which I attributed to the "rule-generator" USE flag and by having added udev-postmount to the default runlevel.
But in any case, this issue is now sorted (at least for me) by slightly modifying the (very helpful) suggestion from Tractor Girl as described in my last post in case you prefer to stick to predictable network names. My post was mainly to point out that eudev (with standard USE-flags) may not be a simple drop-in replacement in all cases.
Regards Atom2 |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Fri Jul 18, 2014 9:13 am Post subject: |
|
|
Hi Cyker,
| Cyker wrote: | | I kinda tripped over this when I was building a new Gentoo box, but the other way around (All the scripts etc. I was porting over were written with eth0, eth1 etc. in mind and I was banging my head against a wall trying to figure out why udev refused to rename my NICs so I wouldn't have to go through all of them ) |
It probably all depends on where you start from and which names you were presented with when you initally were setting up your boxes network. I have used the predictable network names from start (granted, it was a mess back then because my mind was also used to ethX names) but after having sorted it out, the idea grew on me and now I find those predictable names rather useful. It only was hitting me again when I decided to switch to eudev which I considered as a simple drop-in - which unfortunately it wasn't in my case. But again, all sorted now ...
Regards Atom2 |
|
| Back to top |
|
|
blueness
Developer
Joined: 25 Nov 2009
Posts: 32
Location: Buffalo, NY
|
| Posted: Sun Jul 20, 2014 9:52 pm Post subject: |
|
|
| Atom2 wrote: | It appears that asterisk/dahdi had brought in some old/deprecated rules back when I installed it some months ago already. I had to make changes as follows: | Code: | SYSFS{hardware_id} -> ATTR{hardware_id}
SYSFS{location} -> ATTR{location} |
to get rid of the error message. |
Thanks for finding this and pointing it out. I'll look into it
| Quote: |
Still I am however not clear on a few things:
1.) Why did those error messages not show up on my (old) systemd-udevd-212 version which I had used up to today before I changed over to eudev-1.9. Incidentially moving to eudev was my only change today.
2.) While the change to ATTR got rid of the error message, I am not completely sure whether the right change would be for ATTR{...} or ATTRS{...}
|
eudev-1.9 is approximately equal to systemd-udevd-215, not 212. Maybe this is why, but I'd have to look back at the commits in between 212 to 215 to see where the change happened. I vaguely remember some commits that may be responsible.
| Quote: |
So there seems to be some discrepancy between systemd-udevd and eudev and contrary to common believe it's not always a simple plugin replacement, although so far nothing too drastic has poped up.
|
There are differences so its not a equivalent plugin replacement, but again, I'm not sure for the reasons you state. We'd have to compare udev-215 with eudev-1.9
| Quote: |
The final issue that I was faced with was the network: eudev sticked to eth0, but my old systemd-udevd had used a name of enp0s25 instead and that was what my /etc/init.d net rules relied upon. It took me a bit to figure out that eudev (or something during the upgrade/change emerge prcoess) had created a new rule under /etc/udev/rules.d/70-persistent-net.rules as follows: | Code: | # This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.
# PCI device 0x8086:0x1502 (e1000e)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:18:7d:1d:72:74", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" |
I changed the value of NAME to enp0s25 to get back to the old behaviour - although I am neither sure whether that's the proper way to do it nor why/how the old systemd-udevd-212 automatically came up with enp0s25 (i.e. in which rules file that was recorded).
I guess I need to amend that rule for any new network interface as I actually don't mind the new behaviour with names like enpXsY instead of ethX.
|
This is precisely for backwards compatiblity. See the other posts for how to swtich between predictable and persistant interface naming. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
