Bug 383320

*** Bug 378758 has been marked as a duplicate of this bug. ***

I guess it's Yast who adds these incomplete rules. It should better not do that at all, it will get far too complicated to duplicate all the logic we will have in udev.

Kay: no, YaST just edit, not create that rules

I do not think, that udev does create rules like this. :)

Isn't this:
  rules = add(rules, sformat("SUBSYSTEM==\"net\", \
  DRIVERS==\"?*\", %1==\"%2\", NAME=\"%3\"", \
  rule["rule"]:"", rule["value"]:"", rule["name"]:""));
in:
  /usr/share/YaST2/modules/LanUdevAuto.ycp
doing that?

Why is the default install broken then? I do not see any reason for yast to rewrite udev's rules in that case.

Yast can "edit" the file, as long as "edit" means nothing else than changing the NAME= key.

No, there is no facility to compose rules outside of udev. We already needed to change the rule creation logic several times, and will probably need to continue to do so, because of new hardware, buses, which do weird things, we need to work around.

... nothing else than changing the NAME= key.
or rule.

and yes, I see that mechanism should be changed

I rewrited all that code but have some problems with udev:
- there is no "udevtest" tool anymore
- udev rules matches only by MAC address, no BusID (in 10.3 I used KERNELS for that)
- when I change NAME value, it's ignored and created new rule

Kay, can you help here?

(In reply to comment #8 from Michal Zugec)
> I rewrited all that code but have some problems with udev:
> - there is no "udevtest" tool anymore

It is a debugging tool, it may change its output any time. Newer udev versions have only a single binary, which can be called as:
  /sbin/udevadm test <devpath>
But still, do not use it in any software, it's output is not stable in any sense.

> - udev rules matches only by MAC address, no BusID (in 10.3 I used KERNELS for
> that)
> - when I change NAME value, it's ignored and created new rule

If NAME= is set in any earlier rule, the udev persistent net generator should ignore the network interface completely.

I guess yast should create and maintain its own rules file, which comes before 70-persistent-net.rules, instead of patching the udev maintained one.

Thanks for explanation.
udevtest - just to debug, I'm not use it in code

NAME - I have a typo, already fixed


>> I guess yast should create and maintain its own rules file, which comes before
>> 70-persistent-net.rules, instead of patching the udev maintained one.

I don't think we can change it for 11.0 (too late). Why there is comment "You can modify it, as long as you keep each rule on a single line."
But yast code is now much better, it keeps all and change only needed options (ATTR{address}, KERNELS and NAME)

There is only one issue - how to "match by BusID" instead of MAC address? This was probably changed from 10.3 (it works with KERNELS rule)

It sh(In reply to comment #10 from Michal Zugec)
> Thanks for explanation.
> udevtest - just to debug, I'm not use it in code

Ah, good.

> NAME - I have a typo, already fixed

Fine.

> >> I guess yast should create and maintain its own rules file, which comes before
> >> 70-persistent-net.rules, instead of patching the udev maintained one.
> 
> I don't think we can change it for 11.0 (too late). Why there is comment "You
> can modify it, as long as you keep each rule on a single line."
> But yast code is now much better, it keeps all and change only needed options
> (ATTR{address}, KERNELS and NAME)
> 
> There is only one issue - how to "match by BusID" instead of MAC address? This
> was probably changed from 10.3 (it works with KERNELS rule)

It should still work the same way, if the rule still matches and sets NAME=. There is was no change regarding matching parent device properties.

But it's tricky, as there is hardware out, where the same device offers multiple interfaces with the same type. On such boxes, it might not work as expected without figuring out how to distinguish them properly. That's why we are adding all these keys with the new udev rules now.

*** Bug 384660 has been marked as a duplicate of this bug. ***

*** Bug 388439 has been marked as a duplicate of this bug. ***

fixed on running system, but it needs to be fixed in AY-part (to be back-compatible). For AY I created bug #388593