Bug 230213

Since the number is increased by one on every boot, I am now at eth42 and there has still been no response.

Created attachment 111748 [details]
boot.msg that shows at which point the device is renamed

This is a base-system configuration issue, not a kernel one.

Reassigning the bug...

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

Hello folks,
please take a look at 235244, there is an attached patch that solves the issue (for me). So, big please, Sven, if you were willing to test, please download the patch from 235244 and tell me about.
Take care


Dieter Jurzitza

The patch works for me without any problems, until now. Why are there no developers commenting on this issue apart from re-assigning?

I care for it now.

The patches from bug 230213 are not a fix for this issue, just a workaround. Have a close look at the udev rules files 30-* and 31-*. 
If there is an interface with  a mac address listed in 30-* then this rule calls rename_netiface with two interfaces. And it sets RENAMED=yes. So the rule in 31-* will then no longer match.
If no rule from 30-* matches, then RENAMED stays unset and the rule from 31-* matches. So in this case all interface names from 30-* are for other interfaces. Thus check_if_name_is_used() behavior is correct.

The problem here is that the interface changes its mac address after it had been registered in the kernel. Yes, this happens when firmware is loaded. And it seems to happen just while rename_netiface is running (called from 31-* with just one argument). 

I'll try to reproduce the problem. Stay tuned.

Created attachment 114509 [details]
Finetune the former patch.

Hi Mr. Zoz,
I see your comment - I would help debugging further if only I knew from what program the call to rename_netiface is initiated.

Nevertheless: 
Whatever is being done ahead of the script rename_netiface: it should be self protecting IMHO. Duplicate entries for one MAC address should be impossible.
This is definitively prevented by the patch I provided. The current implementation of rename_netiface is not "save" in this regard.
Until a real fix is found, my patch would help everybody suffering from this.

The latest patchversion fixes problems with areadily messed files /etc/udev/rules.d/30... if multiple entries are already present (grep -m 1 instead of grep only). 
Moreover an error of mine with testing the presence of /sys/class/net/<DEVICE> has been fixed: this is a directory, not a file ( if [ -d rather than if [ -x)


Take care


Dieter Jurzitza

Got it. udev/rename_netiface is to fast. Or the kernel to fast.

Udev receives an event for an interface as soon as it was registered. Then udev processes its rules immediately and calls rename_netiface. But then in rename_netiface the renaming fails, because the interface is still not completely ready.

So the solution is that the first rename_netiface (triggered from an existing rule in 30-*) must not fail due to such problems. If if fails for other (maybe still unknown) problems then it should (in a second run triggered from fallback rule in 31-*) of course look for another name. A possible enhancement would be to check 30-* for multiple rules for the same device.

Created attachment 115398 [details]
patch for debugging

This patch solves the problem and shows in debug output how long we have to delay renaming.

Please apply this patch to /lib/udev/rename_netiface do the following steps for debugging:
# udevcontrol log_priority=6
# cd -p /sys/class/net/eth5/device/driver/
In this directory is a link that points to the pci device. Write the name of this link to the file unbind: (example)
# echo -n 0000:02:01.0 > unbind
And then (after a second)
# echo -n 0000:02:01.0 > bind
Now repeat the last two steps and watch in /var/log/messages what rename_netiface does.

Note that this is not a final patch, since it implemets busy waiting.

Of course replace 'eth5' in the cd command above with your current interface name.

Created attachment 115617 [details]
contents of /var/log/messsages

Dear Mr. Zoz,
attached please find the output of your testcase. According to this it takes 10 loops of whatever length to find a "real" name for the interface.
Let me know if there is more information to provide. The bad thing about this is the fact that in principle the driver ought to tell udev that it is ready, one should not need to implement "some" waiting in order to get things going. And because you do not know in advance what interface to expect this is quite difficult, as you do not know in advance what "some" waiting could mean in terms of time.
Take care


Dieter Jurzitza

Created attachment 116268 [details]
Fix for the renaming problem

This patch is a workaround for the problem, that the kernel triggers the hotplug event before the interface is completely ready. It should have no side effects and makes rename-netiface just more rugged.

Created attachment 116273 [details]
This fix avoids duplicate udev rules.

Fix for write_rule(). It will now delete old rules if it adds a new one for a certain device. 
A new rule will be added if the rename_netiface of an existing rule failed (what is less probable with the last patch) or if there was no rule for a device.

Please test both patches and let me know if they work.

NEEDINFO to everyone in cc.

Dear Mr. Zoz,
your patch nearly works :-). One thing is remaining my patch solves, yours does not (yet).
In my system I get a circular renaming issue with your patch, the reason follows.
At first I entered a card, say rt61 which became ra0 that time. I configured it, so the line

SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:0e:2e:b0:c1:9b", IMPORT="/lib/udev/rename_netiface %k ra0"

was entered into 30-net_persistent rules.
IMHO this is the persistent name of this interface. Now I add another card, say rt2500 which became ra0 again (making the rt61 a "should be" ra1. However, the persistent name of the rt61 is ra0, so the new card should be ra1, not vice versa.
Given these entries within 30-net_persistent_names.rule causes an infinite loop:
1st boot ra0-> ra2, ra1 remains.
2nd boot ra2-> ra0, ra1 remains
3rd boot = 1st boot

this should not happen. My patch cared for this: if there was a request for renaming an interface <RAX> to <RAY> out of 30-net_persistent_names.rule, I made this interface free by moving the current owner of <RAY> to the next free interface <RAZ> and moving <RAX> to <RAY> afterwards.

This does not work with your new patch. Since the permanent renaming is not what is intended to happen, please take a look into what I had had done here:

@@ -172,8 +184,22 @@
                error_exit 6 "could not get a free persistent interfacename" \
                         "for $OLDNAME ($DEV_ID)"
        done
-       WRITE_RULE=yes
        info_mesg "$OLDNAME: new persistent name for $DEV_ID is $NEWNAME"
+       # check whether we expect our IF at a certain location!
+       if [ "${PERSISTENT_NAME}" != "" ]; then
+               # check whether the expected name of our IF differs from what we get!
+               if [ ${NEWNAME} != ${PERSISTENT_NAME} ] ; then
+                       if [ -d /sys/class/net/${PERSISTENT_NAME} ]; then
+                               if nameif -r "${PERSISTENT_NAME}" "${NEWNAME}" 2>/dev/null 1>&2; then
+                                       write_rule || error_exit 8 "Name ${PERSISTENT_NAME} for ${DEV_ID} is NOT" \
+                                                               "persistent"
+                                       info_mesg "${NEWNAME} -> ${PERSISTENT_NAME}: immediate success"
+                               fi
+                               usleep $((RANDOM%600+700))000
+                       fi
+                       NEWNAME="${PERSISTENT_NAME}"
+               fi
+       fi
 fi

and maybe you find an easy way to put a similar thing into your new patch.

Anyway: thank you very much for taking care of this, keep me online!
Take care


Dieter Jurzitza

Created attachment 116349 [details]
Nameing conditions after first boot

Here you see that ra0-> ra2, ra1 stays where it was before

Created attachment 116350 [details]
Nameing conditions after second boot

Here you see the nameing back. This oscillates forever now with every new boot.

It is not so easy to reproduce the problem. I have a machine where it happens but very seldom and only if the machine is under high load. Investigating ...

Take your time - and let me know if I can help somehow ...
Take care


Dieter Jurzitza

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

Eike, would you please try the patch from attachment 116268 [details]

And Sven, did it help in your case?

Dieter, in your case it would be of interest how udev invoked rename_netiface. If it calls it with just one argument (the current interface name), then the rule from 30-* did not match. That means that the attribute 'address' from $DEVPATH was not available.

Please add a rule
  SUBSYSTEM=="net", ACTION=="add", IMPORT="/bin/sleep 2"
at the beginning of 30-*. Does it work then?

Hi Mr. Zoz,
yesterday I couldn't test. Today was better. I added several debug-printouts to your script in order to make the processing more transparent.
The result you can see from the attached files called "netifacelog.zozdebug", two subsequent boots, one renaming forward, one renaming back.
The ra61 (with binary firmware image) driver is always getting into the script with a single name only; in contrast, the ra0 driver (not needing the binary image) comes into the script with two names.
In the case for the ra61 your script makes the error because (in the first place) it renames ra0 (what should be ra0 according to 30-net_persistent_names.rules) to ra2, renaming it back to ra0 with the next boot. Obviously there is a timing impact here, because the script rename_netiface is called with two names for the same interface at two subsequent boots.
Maybe you can track things down from here on, I am stuck :-)
I attached the script from you I modified with regard to debugging, too, so you can use it for yourself (if you want to).
Let me know if there is anything else I could do to track this down.
Take care


Dieter Jurzitza

Created attachment 117195 [details]
Outcome when using the debug-version of "my" rename_netiface

This is the "raw" version of my script without delay

Created attachment 117197 [details]
This is the debug output of "my" script using Mr. Zoz's delayloop.

Watchout!
Here the first name of the card with the ra61 driver has changed, probably because the loop introduced some delay from the former call to rename_netiface. This behaviour is similar to what I see with Mr. Zoz's variant including debug outputs.

Created attachment 117199 [details]
This the debug output of Mr. Zoz's script with additional debug features

Here you see two subsequent boot events. In one of them the naming goes ra0 -> ra2, ra1 -> ra1, in the second event the naming goes ra1 -> ra0, ra1 -> ra1. See inside the file, there are additional comments included at certain somewhat significant locations.

Created attachment 117200 [details]
Modified version of Mr. Zoz's script

This script contains "Debuglattenzäune" whoever wants to translate that ... :-)

And finally:
even if I insert a "sleep 20" at the beginning of rename_netiface ra0 will always come as a single-parameter call to rename_netiface.
To whom it may concern ...

To comment 33:
Sleeping while rename_netiface was already called with just one arg ist to late. Please see comment 27 how to sleep before the rules in 30-* are processed. (IMPORT is executed immediately before next rules are processed.)

This should fix all issues on your side, Dieter.

The basic problem is that the hotplug events are triggered a bit to early. See bug 241982 for this.

The main workaround is the additional rule from comment 27 without any other patch. 

Hi Christian,
would be nice if it did ;-). I did not refer to your suggestion (including a call to /bin/sleep as a rule in the rule-file) but had had tested it before without success. I even prolonged the waiting time up to 20 s without noticing any change in behaviour. This is why I attached the debug logs to this Bug.

And your argument that waiting within rename_netiface does not help does not fit IMHO: if I wait each time rename_netiface is called it does not help for the current device, but the devices that are being processed in subsequent calls to  rename_netiface ought to have more time to initialize. Because (in my case ..) the call with the rt61 device is the third one, this device should have won two times the waiting time within rename_netiface.
Nevertheless, the device that is attached to the rt61 driver is called with a single devicename only, however long I wait. There is something different going wrong.
Would you tell me what program is calling rename_netiface? I unpacked udev, but grepping through it's sources does not yield a result for rename_netiface.
Thank you for taking care of this

CU


Dieter


Dieter

Tonight I looked a little deeper:
I patched udev to printout what it is doing. This relates to udev_device.c and udev_rules.c
So I know I can wait directly where it ought to be of interest. What I find:

Import_program: /lib/udev/trigger_firmware_loading.sh ra1 
Sleeping for two seconds ...
Import_program: /lib/udev/rename_netiface ra1 NOMAC_HACK_APPLIED=no
ADDRESS=00:0e:2e:b0:c1:9b

so, though I sleep between saying "hey, load your firmware" and calling rename_netiface nothing happens (I inserted a sleep(2) there).

Hard to track this further without any documentation. Nevertheless, however long I wait, rename_netiface is always called with one devicename only given the firmware loading needs to be triggered as shown above.

Maybe someone can put me on the track where within udev sources to look to exactly find the point where the decision is made to use a single devicename only.

Take care



Dieter Jurzitza

Created attachment 117827 [details]
Eikes rename_netiface

With this file it is working now. I patched the file manually - partly incorrect - but it works :)
So I will not try what happens if I "correctly" patch it.
Anyway, I get some Errors in boot.messages:
<<<<<
<notice>boot.udev start
Starting udevd udevd-event[916]: import_file_into_env: can't open '/lib/udev/rename_netiface lo': No such file or directory

udevd-event[1895]: import_file_into_env: can't open '/lib/udev/rename_netiface eth1 eth1': No such file or directory

udevd-event[1895]: import_file_into_env: can't open '/lib/udev/rename_netiface eth1': No such file or directory

udevd-event[1828]: import_file_into_env: can't open '/lib/udev/rename_netiface eth0': No such file or directory

done
>>>>>
I don't know what this means, but as it is working by now, it is just to nofify you.

Another thing I tryed out:
I replaced the patched file by the original one and noticed, that ethXX is still incrementing in background - for example:
eth47 (old file)
eth48 (old file)
eth0  (patched file)
eth50 (old file)
...

So, will there be a problem when eth255 is reached - even when it is not displayed as eth255?

Best regards,
Eike

Hi folks, hi Christian,
1.) I finally found the bug. It was buried in trigger_firmware_loading.sh in /lib/udev. As soon as the loop

if [ "${MAC_ADDRESS%00:00:00}" != "${MAC_ADDRESS}" ] ; then
***
is entered, the environment - variable
NOMAC_HACK_APPLIED=yes

*should* be set. This does *not* always happen in the current script, because though you apply the HACK actually, you only set the variable to yes if you apply the HACK *and* enter the inner delay loop, what is wrong. As soon as the hack is applied, the variable NOMAC_HACK_APPLIED should be set to yes.

Given the above mentioned variable is set, when udev returns, rename_netiface writes the appropriate rule into /etc/udev/rules.d/30-net_persistent_names.rules and everything is fine. The ongoing renaming turnarounds I still was confronted with come to an end.

I supply a patch that contains both Christian's and mine fixes. Both of them combined result in a proper function of the scripts as far as I can see. I supply a patched sysconfig.spec file, too - do with it whatever you like.

Christian, you definitively should issue a bugfix release of sysconfig IMHO!

2,) Eike: you must have done something wrong here. The messages sound as if
a.) /lib/udev/rename_netiface does not exist any more
b.) /lib/udev/rename_netiface is not executable
c.) /lib/udev/rename_netiface is not readable.

Created attachment 117938 [details]
Fix both rename_netiface and trigger_firmware_loading.sh

This is a patch that fixes the behaviour of both rename_netiface and trigger_firmware_loading.sh

Created attachment 117939 [details]
This is a modified specfile that would fix the behaviour of sysconfig

This specfile would make sysconfig build in accordance with the recently applied patches.
A bugfix-release for sysconfig should be issued IMHO

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

Comment on attachment 116268 [details]
Fix for the renaming problem

Hallo
Yes i made a mistake, sri i am 67 Years old and try to learn the system.
The file rename_netiface was not executable. 
But the sucsess was: the interface stops increasing with number eth0 
The interface number does not count any more.

Now i have to learn how to patch, i did:

patch < yourfile.cgi in the path of /lib/udev; 

I hope it is ok

Now the sucess: the interface stops counting high with number eth60.
whenn I reboot, the interface don´t count any more. 
The number ist always eth60.
Many thanks for the Help
Eike
df7

Hi Christian,
I got into an off-bugzilla discussions with Eike Auler and found another issue with trigger_firmware_loading.sh.

Eike's WLAN-Card has the MAC-Address 00:30:b4:00:00:00.
This will caus all "if" conditions in trigger_firmware_loading.sh

if [ "${MAC_ADDRESS%00:00:00}" != "${MAC_ADDRESS}" ]; then
....

to fail. Why do you do it this way and don't simply ask for 

if [ "${MAC_ADDRESS}" != "00:00:00:00:00:00" ]; then

?

Because the file /etc/udev/rules.d/30-net_persitent_names.rule contains an entry of the form

SUBSYSTEM=="net", ACTION=="add", ENV{ADDRESS}=="00:30:b4:00:00:00",=IMPORT="/lib/udev/rename_netiface %k eth0"

I do know that trigger_firmware_loading.sh had had been passed by and the variable NOMAC_HACK_APPLIED was set to "yes". Do you consider fixing this?  I would assume that the MAC - address is a valid one, but the comparisons within the script yield erratic results. Is there any reason to *not* use

if [ "${MAC_ADDRESS}" != "00:00:00:00:00:00" ]; then
****
?
Thank you for looking into this,

take care



Dieter

This is what happens to my computer.
I hav a new ASUS MB with onboard a NVIDIA network chip running with forcedeth module.
For one or other reason the MAC address is wrong and a random MAC address is generated. My PC also generates increasing numbers ethx at start up. And avery time a new rule is added to /etc/udev/rules.d/30-net_persitent_names.rule.

How can I avoid this? I don't knowe wher to look at.

Regards,
Henk

<6>forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
<4>ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 21
<6>GSI 18 sharing vector 0xE1 and IRQ 18
<6>ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [LMAC] -> GSI 21 (level, low) -> IRQ 225
<7>PCI: Setting latency timer of device 0000:00:07.0 to 64
<6>forcedeth: using HIGHDMA
<3>0000:00:07.0: Invalid Mac address detected: 99:74:a8:f3:18:00
<3>Please complain to your hardware vendor. Switching to a random MAC.
.....
<6>hdb: ATAPI 126X DVD-ROM drive, 256kB Cache, UDMA(66)
<6>Uniform CD-ROM driver Revision: 3.20
<6>8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
<7>ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
<6>eth0: forcedeth.c: subsystem: 01043:8234 bound to 0000:00:07.0
....
<6>eth0 renamed to eth16
<

Henk, you may just set this:
/etc/sysconfig/network/config:FORCE_PERSISTENT_NAMES=no
or:
remove all rules containing "rename_netiface" from 30-*.rules and 31-*.rules
or:
manually write a rule for your device in 30-* that does match the pci bus location instead of the MAC address. See 'man udev' for details. It must contain the IMPORT=... keywork like in the autogenerated rules.

So will this bug be rectified in the next openSUSE release?

Finally back again on this one. Resolution: obsolete

We don't longer use rename_netiface. For 10.3 we change to the newer upstream solution (/lib/udev/write-net-rules, 70*net* und 75*net*). So all patches for rename_netiface are obsolete.

The timing problem (comment 15) is handled in bug 241982. Please add your comments there if this still happens in newer version. (THis is a difficult problem, because it happens rarely and is therefore not easy to reproduce.)

To Eikes trigger_firmware_loading problem: Yes, checking only the second part of the mac address was intention. There were some drivers which assigned faked addresses of this form if no firmware was loaded.
But since it is hard to see if such workarounds are still needed with newer drivers (we just don't have all possible devices around), we removed this workaround for 10.3 completely. If it still needed we will add a replacement for trigger_firmware_loading in udev.

Last but not least will YaST learn how to add/change/delete such persistent name rules and will also be able to write rules based on device location.

For 10.2 wont be fixed regarding this problem, but in 10.3 everything should work.

Hi Christian,
I see your words but still think that if what you say refers to what is currently in opensuse factory the bug I referred to in #38 is present:

- If trhgger_firmware_loading.sh is started you set NOMACK_HACK_APPLIED=no
- at the end you ask if [ "${MAC_ADDRESS%00:00:00}" != "$MAC_ADDRESS" ]; then

IMHO you *should* set NOMACK_HACK_APPLIED=yes immediatly not only if you enter the delay-loop and find the condition once again. On my system this exactly was the bug why wrong entries found their way into /etc/udev/rules/30... - and it actually doesn't matter whether you write to 30.... or to whatever ... in /etc/udev/rules.d.

The appropriate way how this ought to look is depicted below:

--- trigger_firmware_loading.sh.original        2006-11-10 13:09:39.000000000 +0100
+++ trigger_firmware_loading.sh 2007-07-27 11:00:57.000000000 +0200
@@ -25,11 +25,11 @@
        ip link set up dev $INTERFACE
        ip link set down dev $INTERFACE
+       NOMAC_HACK_APPLIED=yes
        # Do we have to wait some time?
        for i in 0 1 2 3 4 5 6 7 8 9; do
                MAC_ADDRESS=`cat /sys/class/net/$INTERFACE/address`
                info_mesg "waiting for a usefull mac address: $MAC_ADDRESS"
                if [ "${MAC_ADDRESS%00:00:00}" != "$MAC_ADDRESS" ] ; then
-                       NOMAC_HACK_APPLIED=yes
                        break
                fi
                sleep 1

Bug should remain open until the issue depicted in #38 and #48 is fixed.

Read again comment 47: trigger_firmware_loading.sh has gone.

Go for Alpha7 in the end of next week.