Disabling udev Persistent rules (USE flag?)

Message

NiXZe · Post by **NiXZe** » Mon Aug 27, 2007 2:18 pm

So i have tried to find the "right" answer for disabling persistent (network) udev rules, but came up empty.
i edited the 75-persistent-net.generator.rules files and commented everything out, but i found the line

# do not edit this file, it will be overwritten on update

so is there a reason why there is no (gentoo way) USE flag to disable the persistent rules? i find them more being a BUG then a FEATURE.

i haven't tested this yet but i hope it works.
still any input on the "right way" is appreciated.

PaulBredbury · Post by **PaulBredbury** » Mon Aug 27, 2007 2:29 pm

What's the bug? Does your hardware change on every reboot?

Can just use custom udev rules to override that file anyway.

Post by **John R. Graham** » Mon Aug 27, 2007 2:35 pm

Having been bit by this feature myself, I can understand. I still like the persistent net rules feature, mind you, but it did trip me up before I knew about it. Now I've just added a "delete /etc/udev/rules.d/70-persistent-net.rules under certain arcane conditions" rule to my own (human) set of persistent rules.

The persistent rules generator is a udev "extra" feature that is unconditionally built by the Gentoo ebuilds. You should consider writing an updated ebuild that makes it optional via a local USE flag and submit a bug petitioning that the new ebuild feature be included in future releases. After just a quick glance, this does seem like it would be a pretty clean addition to the ebuild.

- John

PaulBredbury · Post by **PaulBredbury** » Mon Aug 27, 2007 2:50 pm

It's not optional because then we'd have dozens of users moaning that their two Ethernet cards get assigned eth0 vs eth1 randomly on each reboot.

So, /etc/udev/rules.d/75-persistent-net-generator.rules exists to fix that bug - because the order of device discovery can be non-deterministic.

Rob1n · Post by **Rob1n** » Mon Aug 27, 2007 3:21 pm

Yeah - it's probably the best approach, though it's not perfect.

I spent quite a while yesterday trying to get my network working properly with a new card. Turns out (probably due to driver problems, though it is an in-kernel driver) that it's not creating a full sysfs hierarchy for the card, so it doesn't link the net device to the PCI bus at all, therefore the sysfs DRIVER entry is empty. The rule added by the presistent-net-generator require it to have a value, so each boot a new entry would be added but wouldn't actually work the next time, so another new entry would get added. Took me a while to figure this out and manually add an entry which works.

s4e8 · Post by **s4e8** » Mon Aug 27, 2007 3:54 pm

Here is my solution:

Code: Select all

cd /etc/udev/rules.d
rm 70-persistent-net.rules
mkdir 70-persistent-net.rules

after that, the world is peaceful again.
All my network is configured as DHCP, and I don't care which one as eth0, and I don't need any firewall, and no endless ethX names.

PaulBredbury · Post by **PaulBredbury** » Mon Aug 27, 2007 4:12 pm

The world would also be peaceful, in a far less bizarre hackish-workaround sort of a way, if you'd just added a custom udev rule

But, this still doesn't answer my question. If you're saying that a bug exists, then state it in plain English. Does the MAC address of your network card change randomly?

devsk · Post by **devsk** » Mon Aug 27, 2007 11:49 pm

PaulBredbury wrote:The world would also be peaceful, in a far less bizarre hackish-workaround sort of a way, if you'd just added a custom udev rule

But, this still doesn't answer my question. If you're saying that a bug exists, then state it in plain English. Does the MAC address of your network card change randomly?

dmesg shows:

Code: Select all

0000:00:0a.0: Invalid Mac address detected: 4x:78:d7:8e:50:0y
Please complain to your hardware vendor. Switching to a random MAC.

this kills the smartass udev rules. so, reboot will get you eth1, next one eth2 and so on...I can crib to Abit but I doubt that will get me anywhere. Neither will cribbing to udev devs because those guys think udev is the next best thing to the sliced bread. So, I hack, like the guy above!

PaulBredbury · Post by **PaulBredbury** » Tue Aug 28, 2007 5:47 am

Then write a udev rule that matches on a field other than the mac address. See thread.

NiXZe · Post by **NiXZe** » Tue Aug 28, 2007 7:56 am

No my problem is not random ethXs however there is some things that is a problem.

First of Vlans. if i asign a vlan to eth0 say eth0.10 this interface is renamed to eth1 - not good
on reboot my eth0.10 is named eth2 and so on. - not good

also i have one disk that is used in some diffrent machines and i want all these to have the first detected interface as eth0

The part with random interfaces - never seen it, is'nt the interfaces created in the order of driver load?, and since the "modules" always is loaded in the same order there shuld be no problem. [edit]true they can be loaded randomly so i can see why the rule was added[/edit]
i can see if you remove eth0 and still want to have eth1 stay as eth1 this can be usefull.

But i still want the option to disable this Feature (in a clean way!) since i like the old way better, and is'nt gentoo all about choices?

and i'm sorry but i dont feel that comfortable with hacking ebuilds :/

Post by **John R. Graham** » Tue Aug 28, 2007 9:45 am

To support Paul's general thesis a bit, Gentoo never has been about bad choices.

Still, I think it might be reasonable to disable (via a USE flag) an optional feature of a package that causes problems under special circumstances. How many (non-hackish, perfectly implemented) custom udev rules have to be written to justify that? Dunno.

- John

mastermind456 · Post by **mastermind456** » Tue Sep 04, 2007 7:14 am

devsk wrote:
Code: Select all
0000:00:0a.0: Invalid Mac address detected: 4x:78:d7:8e:50:0y
Please complain to your hardware vendor. Switching to a random MAC.
this kills the smartass udev rules. so, reboot will get you eth1, next one eth2 and so on...I can crib to Abit but I doubt that will get me anywhere. Neither will cribbing to udev devs because those guys think udev is the next best thing to the sliced bread. So, I hack, like the guy above!

You're using an NForce chipset, correct? This error has been showing on a number of systems up due to a bug in BIOS. The forcedeth driver >=v0.57 should compensate for this. Try upgrading your kernel version, or backport the forcedeth source.

devsk · Post by **devsk** » Tue Sep 04, 2007 7:24 am

mastermind456 wrote:
devsk wrote:
Code: Select all
0000:00:0a.0: Invalid Mac address detected: 4x:78:d7:8e:50:0y
Please complain to your hardware vendor. Switching to a random MAC.
this kills the smartass udev rules. so, reboot will get you eth1, next one eth2 and so on...I can crib to Abit but I doubt that will get me anywhere. Neither will cribbing to udev devs because those guys think udev is the next best thing to the sliced bread. So, I hack, like the guy above!
You're using an NForce chipset, correct? This error has been showing on a number of systems up due to a bug in BIOS. The forcedeth driver >=v0.57 should compensate for this. Try upgrading your kernel version, or backport the forcedeth source.

Code: Select all

forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.

looks like I am already upgraded.

schachti · Post by **schachti** » Sat Sep 22, 2007 1:03 pm

Same here with nForce 560 chipset and sys-kernel/gentoo-sources-2.6.22-r6. Any solution how to fix this (apart from the udev hack)?

funkadil · Post by **funkadil** » Sat Sep 22, 2007 5:11 pm

There should be a config option to turn this off. Or the generator should be able to be turned off by a config setting.

I'm having an issue where I need to deploy this image to 25 or so machines with different mac adresses. This means that the generator creates a new rule which assigns them all to eth1. All I can think of is wiping the rules file before I take the image, but that just seems like one more annoying thing to remember.

Any Ideas?

Perhaps writing a different rule and putting it after the persistent net-rules script, based on something about mac adresses? I would edit the generator-rules file but I have a feeling it would be replaced when updating udev.

EDIT: oops sorry I just realized this was a portage thread and not a udev thread. I'm still looking for a decent answer.

MOL_PL · Post by **MOL_PL** » Tue Sep 25, 2007 9:08 am

I have the same problem. Gentoo read the mac address from end to the begining (for example real mac address is 00:0A:CD:13:B7:4C but liveCD see 4C:B7:13:CD:0A:00)

How to fix it ?

NiXZe · Post by **NiXZe** » Tue Sep 25, 2007 9:23 am

If you only have one eth interface and want it to stay as eth0 even if you change network card or have a buggy hardware,
the best solution right now is to use s4e8 way se below

But i still thing there shuld be a USE flag to disable the default of installing these udev rules! however i'm not confident that i'm the right person to make a patch for the ebuild!.

s4e8 wrote:Here is my solution:
Code: Select all
cd /etc/udev/rules.d
rm 70-persistent-net.rules
mkdir 70-persistent-net.rules
after that, the world is peaceful again.
All my network is configured as DHCP, and I don't care which one as eth0, and I don't need any firewall, and no endless ethX names.

MOL_PL · Post by **MOL_PL** » Tue Sep 25, 2007 10:10 am

I have found something like this:

Code: Select all

udevinfo -a -p /sys/class/net/eth0

and you are looking for ATTRS{device}=="0x0450"

next edit /etc/udev/rules.d/70-persistent-net.rules and change

Code: Select all

 ATTRS{address}=="xx:0a:cd:13:b7:xx"

into

Code: Select all

 ATTRS{device}=="0x0450"

and it will work !

tuxmin · Post by **tuxmin** » Sat Sep 29, 2007 5:01 pm

Hi folks...

I'd like to bump this up again as this persistent net rules thingy is really bugging me...
Among others I have 2 Gentoo's with 4 VNICs each running inside M$ Virtual Server. The server assigns the VMs MAC addresses dynamically on every boot (I could use static addreses, however, I want it this way)
As you can guess I have no use for persistent net rules and second the suggestion to have a USE flag that diables persistend rules.
As for now I've deleted 75-persistent-net-generator.rules and 70-persistent-net.rule.
Hopefully htis fixes it because I cannot reboot the VMs at the moment.

Best regards, Alex!