Hi all,

I use Slackware 13.37 (but I had this problem with previous versions). I set specific names for my network cards on servers (usually eth0 and eth1) using /etc/udev/rules.d/70-persistent-net.rules. Then on next reboot, udev comes along and makes a mess of the file. Usually deletes both rules I've set and adds an eth2, or switches eth0 to eth1 and so on. I don't understand what's going on.

According the the Slack 13.37 Changes and Hints document:

According to the above, I should be OK to edit the network rules. Why would udev decide to change things - when I have both interfaces listed using their MAC addresses already? Where am I going wrong? I want my interfaces to be named as I decide, not what udev finds convenient. I've been locked out of servers because of interfaces suddenly jumping around on next reboot. Sometimes I have to re-edit the file about 4 times (and reboot in between) until udev finally gives up on interfering.

Thanks for any tips.

When I saw this, I needed to specify the interfaces in the order eth0, then eth1, then eth2 in /etc/udev/rules.d/70-persistent-net.rules.

Thanks allend. I will try specifying them in order next time. It is possible that is the reason udev is re-writing the rule file. It still seems silly to me - if there is a corresponding rule in there somewhere, it should just move on and leave the file alone - in my opinion.

Delete the /lib/udev/rules.d/75-persistent-net-generator.rules, and it won't rewrite the rules anymore.

I would not advocate subverting the udev system. What if you want to add/remove or change a network interface?

Then you add/remove or change a network interface. You don't need udev to do it. And yes, it's completely possible to get them in the right order still. There was a time that udev wasn't around to manage devices. And when udev breaks, even when you are not adding/removing or changing your network setup, then it's just getting in the way-- and I've had that happen just like the original poster.

I was thinking along the same lines. The kernel *will* give names to eth* devices anyway, isn't it? So it's not like they can't exist without udev. In the case of servers, where I want full control over which eth* interface gets what name, it sounds to me like deleting the 75-persistent-net-generator.rules files is just what's required.

Even further than that, I would suggest that the udev rule generator should have never been designed to mess about with a device which already has a naming rule in place. If something is already named, that means somebody (or a piece of software) put it there - it should not be deleted. It reminds of the days I use to work (more) with Windows, when it was damn near impossible to get the system to do what one *actually* wanted it to do. It always seemed to second guess (badly) what was wanted or required.

I have just run some more tests on this server. After about 10 reboots, I pretty much never ended up with an identical /etc/udev/rules.d/70-persistent-net.rules file from one reboot to another. This is utterly ridiculous. This server has two eth* cards and one wlan* adapter. After one reboot the file lists eth2 and wlan0 only, after next reboot only eth1 and nothing else, after another reboot eth1 and wlan0. It just goes on and on. I could never reboot my servers remotely fearing udev will start playing with my network cards naming scheme again and screw things up.

If this is how udev was meant to work - I don't have many good things to say about it. I want a system where *I* do the settings - not some little goblin in the OS. If I wanted a babysitter - I would have returned to the OS Full of Buttons (tm). I am really puzzled as to the thinking behind the udev re-write rules. I would have accepted some scripts that generate rules files *only* the first time a device is detected - letting me change them as I please later, and *not* interfering ever again, unless it detects a device which doesn't have a naming rule in place. But to re-generate the rules on every-single reboot - risking that the order and naming keeps on changing every time - that's not what I would call a recipe for grown up computing.

Well, rant over for now. The rule generator in /lib/udev/rules.d for net devices is on its way to hell and is not going to get its slimy paws on my systems again.

Did any of you submit a bug report?

I am happy to submit a bug report. I only posted here first to make sure it's not something silly that I'm doing. I'd rather not waste developers' time just to find out that I'm not using a piece of software the way it's meant to be used - if I can help it.

Also - does anybody know where the bug report should be submitted - to Slackware or to udev? Is the udev rule re-generator the creation of Slackware packagers, or comes straight upstream from udev?

Hi,

You should read the paragraph following the one you posted in OP;
I do agree that '/etc/udev/rules.d/70-persistent-net.rules' should allow for changes or additions without deleting current configs. Possibly flag the changes or modify allow query to admin. Shuffle a copy to revert or some safe guards. Depth of rules should be up to the local admin not a closed config script (/lib/udev/rules.d/75-persistent-net-generator.rules).

If you follow the rules suggestions within some of the scripts you will find that 90-network.rules states; The option for custom rule is there by providing 90-local.rules within '/etc/udev/rules.d'.

I believe the above quote from 'CHANGES_AND_HINTS.TXT' is a valid alert and everyone should realize the configuration changes can be made by the admin instead of providing a rule.

The depth of control or configuration can be had for '/lib/udev/rules.d/75-persistent-net-generator.rules' but at what expense?

The paragraph that you posted:

would seem to suggest that it is ok to edit any of the two files. That seems misleading and confusing - as both files get overwritten on reboots. It actually should read "there is no point in editing any of the two files, as your changes will most likely be lost on next reboot".

Hi,

Then the option for custom rule is there by providing rule(s) in 90-local.rules within '/etc/udev/rules.d'. This will allow admin to control the installed system devices.

Trace through the scripts and you will see this option.

Hi have done some more research and testing into this. Disabling the udev rule generator does not actually solve the problem. Every few reboots, when the modules for my wired network interfaces get loaded in a different order by the kernel, the boot process hangs for about 50 to 60 seconds, after which I get the error message:

It looks like the kernel gives names to interfaces first, and then udev is incapable of changing these names if the name wanted already exists. Then I wonder what is the point of a software like udev, if it can't deal with a name being in use? It should be able to rename the interface which is already using the name I am after automatically to next available name, and use the name just freed (which is the name I want) for the interface I tell it to.

So udev can rename your interface, as long as it doesn't step on the toes of what the kernel chose in the first place. Marvelous capability that!

I found lots of other people from various distributions with servers with multiple interfaces complaining of this bug online. Every few reboots and udev is either re-writing the network rule, or, if set to static rules, hangs the computer has it can't finish the renaming process according to the rule in place. It is even more annoying, as it is somewhat random, depending on which order the kernel is detecting the interfaces during boot - which can't be predicted. I don't know yet if there is a fix for this bug - as all bug reports I found (mainly on distributions bug reporting systems) were closed without an actual resolution. I'll keep on looking.

If anybody else has info on this or is experiencing this bug - please post here.