Hi Marco,
Sorry for the delay in my response. I tried s/ATTR/SYSFS/ on my eth0
rule, removing the new one, and it worked perfectly at next reboot (as
expected).
I left the rules for the other devices unchanged so I can verify that
the SYSFS-ATTR change is correctly performed on next upgrade. Anyway, I
do not use those devices anymore.
Wondering if the solution would be that simple... What would happen if a
new rule had already been generated, and it is not removed as I did
myself? Which one would get matched? The old one or the new one?
Kind regards,
--
Antonio Fiol
Marco d'Itri escribió:
On Apr 25, Antonio Fiol <anto...@fiol.es> wrote:
ATTR and an added ATTR{type}=="1"). If I understand this correctly, the
"missing" ATTR{type} would match any ATTR{tpye} so it's not that. Then
it must be that udev stopped understanding the SYSFS syntax ??
Interesting, SYSFS{} is supposed to be still supported.
Please check if rules like this work or not (remove the new ones):
ACTION=="add", SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0f:ea:3e:40:84",
NAME="eth0"
s/SYSFS/ATTR/g in the user-generated rules files looks like a good idea
anyway, I need to write some code to do it.
Also it might be related to the upstream change from from v135 to v136:
"require non-SYSFS_DEPRECATED 2.6.20+ kernel". Since v129 (which I never
It is not.
On Apr 25, Yann Dirson <ydir...@altern.org> wrote:
This looks the same as 521521, claimed fix in 0.140, but I'm running
But it is something totally different.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
