[Bug 230213] New: Everytime I insert my PCMCIA card, the device number is increased by one
https://bugzilla.novell.com/show_bug.cgi?id=230213 Summary: Everytime I insert my PCMCIA card, the device number is increased by one Product: openSUSE 10.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: sven.burmeister@gmx.net QAContact: qa@suse.de I have a Netgear WG511. Since using it with 10.2 the device-number, i.e. ethx, is increased by one every time I insert it into the slot. It seems to start with eth0 and then switch to the last number plus one, e.g. eth7. The first iwconfig was issued just a few moments after inserting the card, the second one a few seconds later, when the card's LED began to blink. Regarding the directory-listing. I am not sure where the second WLAN-MAC comes from, since I only have one network-card and one WLAN-card and never inserted any others. I am not sure why the device is renamed, but this breaks any application (eg. network-monitor) that works with a manually entered devicename. eth0 NOT READY! ESSID:off/any Mode:Managed Channel:0 Access Point: Not-Associated Tx-Power=31 dBm Sensitivity=0/200 Retry min limit:0 RTS thr=0 B Fragment thr=0 B Encryption key:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 pc192s:/home/rabauke # iwconfig lo no wireless extensions. eth7 IEEE 802.11b/g ESSID:"susaso" Nickname:"pc192s" Mode:Managed Frequency:2.437 GHz Access Point: 00:15:0C:D9:29:45 Bit Rate:54 Mb/s Tx-Power=31 dBm Sensitivity=20/200 Retry min limit:8 RTS thr=2347 B Fragment thr=2346 B Encryption key:xxxx Security mode:restricted Link Quality:248 Signal level:0 Noise level:240 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 pc192s:/etc/sysconfig/network # ls -la insgesamt 96 drwxr-xr-x 6 root root 4096 20. Dez 23:38 . drwxr-xr-x 6 root root 4096 18. Dez 09:28 .. -rw-r--r-- 1 root root 9260 21. Dez 00:23 config -rw-r--r-- 1 root root 6989 18. Dez 00:59 dhcp -rw-r--r-- 1 root root 285 20. Dez 23:38 ifcfg-eth-id-00:50:04:8c:1e:a0 -rw-r--r-- 1 root root 141 25. Nov 13:55 ifcfg-lo -rw-r--r-- 1 root root 27679 25. Nov 13:55 ifcfg.template -rw------- 1 root root 884 20. Dez 23:38 ifcfg-wlan-id-00:09:5b:98:2f:70 -rw------- 1 root root 884 20. Dez 23:38 ifcfg-wlan-id-00:30:b4:00:00:00 drwxr-xr-x 2 root root 4096 25. Nov 22:49 if-down.d -rw-r--r-- 1 root root 239 25. Nov 13:55 ifroute-lo drwxr-xr-x 2 root root 4096 25. Nov 22:49 if-up.d drwx------ 2 root root 4096 25. Nov 22:49 providers -rw-r--r-- 1 root root 0 20. Dez 23:34 routes -rw-r--r-- 1 root root 27 20. Dez 23:34 routes.YaST2save drwxr-xr-x 2 root root 4096 18. Dez 00:59 scripts pc192s:/etc/sysconfig/network # ifconfig eth7 Protokoll:Ethernet Hardware Adresse 00:09:5B:98:2F:70 inet Adresse:192.168.178.23 Bcast:192.168.178.255 Maske:255.255.255.0 UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:211 errors:0 dropped:0 overruns:0 frame:0 TX packets:181 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:157775 (154.0 Kb) TX bytes:19698 (19.2 Kb) Interrupt:9 lo Protokoll:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:30 errors:0 dropped:0 overruns:0 frame:0 TX packets:30 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:1956 (1.9 Kb) TX bytes:1956 (1.9 Kb) From /var/log/messages: Dec 21 13:06:09 pc192s kernel: pccard: CardBus card inserted into slot 0 Dec 21 13:06:09 pc192s kernel: PCI: Enabling device 0000:01:00.0 (0000 -> 0002) Dec 21 13:06:09 pc192s kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 9 (level, Dec 21 13:06:10 pc192s kernel: eth0: resetting device... Dec 21 13:06:10 pc192s kernel: eth0: uploading firmware... Dec 21 13:06:10 pc192s kernel: eth0: firmware version: 1.0.4.3 Dec 21 13:06:10 pc192s kernel: eth0: firmware upload complete Dec 21 13:06:10 pc192s kernel: eth0: interface reset complete Dec 21 13:06:10 pc192s kernel: eth0: islpci_close () Dec 21 13:06:22 pc192s kernel: eth0 renamed to eth7 Dec 21 13:06:24 pc192s ifup: eth7 device: Intersil Corporation ISL3890 [Prism GT/Prism Due Dec 21 13:06:24 pc192s ifup: eth7 configuration: wlan-id-00:09:5b:98:2f:70 Dec 21 13:06:24 pc192s ifup: eth7 is controlled by ifplugd Dec 21 13:06:25 pc192s ifup: eth7 device: Intersil Corporation ISL3890 [Prism GT/Prism Due Dec 21 13:06:25 pc192s ifup: eth7 configuration: wlan-id-00:09:5b:98:2f:70 Dec 21 13:06:26 pc192s kernel: eth7: resetting device... Dec 21 13:06:26 pc192s kernel: eth7: uploading firmware... Dec 21 13:06:27 pc192s kernel: eth7: firmware version: 1.0.4.3 Dec 21 13:06:27 pc192s kernel: eth7: firmware upload complete Dec 21 13:06:27 pc192s kernel: eth7: interface reset complete Dec 21 13:06:27 pc192s ifup-dhcp: Starting DHCP Client Daemon on eth7... Dec 21 13:06:27 pc192s ifup-dhcp: . Dec 21 13:06:28 pc192s ifup-dhcp: . Dec 21 13:06:29 pc192s ifup-dhcp: . Dec 21 13:06:30 pc192s ifup-dhcp: . Dec 21 13:06:31 pc192s ifup-dhcp: . Dec 21 13:06:32 pc192s ifup-dhcp: no IP address yet... backgrounding. Dec 21 13:06:33 pc192s modify_resolvconf: Service dhcpcd modified /etc/resolv.conf. See info block Dec 21 13:06:33 pc192s syslog-ng[2108]: SIGHUP received, restarting syslog-ng Dec 21 13:06:34 pc192s ifdown: eth7 device: Intersil Corporation ISL3890 [Prism GT/Prism D Dec 21 13:06:34 pc192s syslog-ng[2108]: new configuration initialized -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 chrubis@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team- |kernel-maintainers@forge.provo.novell.com |screening@forge.provo.novell| |.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 sven.burmeister@gmx.net changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Major ------- Comment #1 from sven.burmeister@gmx.net 2007-01-07 03:43 MST ------- Since the number is increased by one on every boot, I am now at eth42 and there has still been no response. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #2 from sven.burmeister@gmx.net 2007-01-07 03:48 MST ------- Created an attachment (id=111748) --> (https://bugzilla.novell.com/attachment.cgi?id=111748&action=view) boot.msg that shows at which point the device is renamed -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 gregkh@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel- |bnc-team-screening@forge.provo.novell.com |maintainers@forge.provo.nove| |ll.com | Component|Network |Basesystem ------- Comment #3 from gregkh@novell.com 2007-01-11 18:23 MST ------- This is a base-system configuration issue, not a kernel one. Reassigning the bug... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 kasievers@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kasievers@novell.com |zoz@novell.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 chrubis@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dieter.jurzitza@t-online.de ------- Comment #8 from chrubis@novell.com 2007-01-22 05:28 MST ------- *** Bug 235244 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #9 from dieter.jurzitza@t-online.de 2007-01-22 06:55 MST ------- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #10 from sven.burmeister@gmx.net 2007-01-23 00:16 MST ------- The patch works for me without any problems, until now. Why are there no developers commenting on this issue apart from re-assigning? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #111748|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Comment #11 from zoz@novell.com 2007-01-23 08:32 MST ------- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #12 from dieter.jurzitza@t-online.de 2007-01-23 12:29 MST ------- Created an attachment (id=114509) --> (https://bugzilla.novell.com/attachment.cgi?id=114509&action=view) 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #13 from zoz@novell.com 2007-01-26 04:54 MST ------- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #14 from zoz@novell.com 2007-01-26 05:14 MST ------- Created an attachment (id=115398) --> (https://bugzilla.novell.com/attachment.cgi?id=115398&action=view) 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #15 from zoz@novell.com 2007-01-26 05:17 MST ------- Of course replace 'eth5' in the cd command above with your current interface name. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #16 from dieter.jurzitza@t-online.de 2007-01-26 16:05 MST ------- Created an attachment (id=115617) --> (https://bugzilla.novell.com/attachment.cgi?id=115617&action=view) 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #115617|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #17 from zoz@novell.com 2007-01-30 08:30 MST ------- Created an attachment (id=116268) --> (https://bugzilla.novell.com/attachment.cgi?id=116268&action=view) 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #18 from zoz@novell.com 2007-01-30 08:40 MST ------- Created an attachment (id=116273) --> (https://bugzilla.novell.com/attachment.cgi?id=116273&action=view) 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |sven.burmeister@gmx.net ------- Comment #19 from zoz@novell.com 2007-01-30 08:41 MST ------- Please test both patches and let me know if they work. NEEDINFO to everyone in cc. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #20 from dieter.jurzitza@t-online.de 2007-01-30 12:41 MST ------- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #21 from dieter.jurzitza@t-online.de 2007-01-30 12:46 MST ------- Created an attachment (id=116349) --> (https://bugzilla.novell.com/attachment.cgi?id=116349&action=view) Nameing conditions after first boot Here you see that ra0-> ra2, ra1 stays where it was before -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #22 from dieter.jurzitza@t-online.de 2007-01-30 12:47 MST ------- Created an attachment (id=116350) --> (https://bugzilla.novell.com/attachment.cgi?id=116350&action=view) Nameing conditions after second boot Here you see the nameing back. This oscillates forever now with every new boot. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #116349|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #116350|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #23 from zoz@novell.com 2007-01-31 10:43 MST ------- 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 ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #24 from dieter.jurzitza@t-online.de 2007-01-31 12:30 MST ------- Take your time - and let me know if I can help somehow ... Take care Dieter Jurzitza -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 judas_iscariote@shorewall.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |e.auler@gmx.de ------- Comment #25 from judas_iscariote@shorewall.net 2007-01-31 23:48 MST ------- *** Bug 240865 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Info Provider|sven.burmeister@gmx.net |e.auler@gmx.de ------- Comment #26 from zoz@novell.com 2007-02-01 05:07 MST ------- Eike, would you please try the patch from attachment 116268 And Sven, did it help in your case? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #27 from zoz@novell.com 2007-02-01 08:36 MST ------- 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? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #28 from dieter.jurzitza@t-online.de 2007-02-02 14:00 MST ------- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #29 from dieter.jurzitza@t-online.de 2007-02-02 14:01 MST ------- Created an attachment (id=117195) --> (https://bugzilla.novell.com/attachment.cgi?id=117195&action=view) Outcome when using the debug-version of "my" rename_netiface This is the "raw" version of my script without delay -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #30 from dieter.jurzitza@t-online.de 2007-02-02 14:04 MST ------- Created an attachment (id=117197) --> (https://bugzilla.novell.com/attachment.cgi?id=117197&action=view) 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #31 from dieter.jurzitza@t-online.de 2007-02-02 14:06 MST ------- Created an attachment (id=117199) --> (https://bugzilla.novell.com/attachment.cgi?id=117199&action=view) 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #32 from dieter.jurzitza@t-online.de 2007-02-02 14:07 MST ------- Created an attachment (id=117200) --> (https://bugzilla.novell.com/attachment.cgi?id=117200&action=view) Modified version of Mr. Zoz's script This script contains "Debuglattenzäune" whoever wants to translate that ... :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #33 from dieter.jurzitza@t-online.de 2007-02-02 14:20 MST ------- 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 ... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |241982 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|e.auler@gmx.de | ------- Comment #34 from zoz@novell.com 2007-02-03 06:10 MST ------- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #35 from dieter.jurzitza@t-online.de 2007-02-03 10:11 MST ------- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #36 from dieter.jurzitza@t-online.de 2007-02-05 14:02 MST ------- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #37 from e.auler@gmx.de 2007-02-07 07:00 MST ------- Created an attachment (id=117827) --> (https://bugzilla.novell.com/attachment.cgi?id=117827&action=view) 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 dieter.jurzitza@t-online.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |zoz@novell.com ------- Comment #38 from dieter.jurzitza@t-online.de 2007-02-07 13:35 MST ------- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #39 from dieter.jurzitza@t-online.de 2007-02-07 13:36 MST ------- Created an attachment (id=117938) --> (https://bugzilla.novell.com/attachment.cgi?id=117938&action=view) 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #40 from dieter.jurzitza@t-online.de 2007-02-07 13:39 MST ------- Created an attachment (id=117939) --> (https://bugzilla.novell.com/attachment.cgi?id=117939&action=view) 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ulrich@holeschak.de ------- Comment #41 from zoz@novell.com 2007-02-08 07:52 MST ------- *** Bug 231043 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|zoz@novell.com | Summary|Everytime I insert my PCMCIA|interface number increases everytime/sometimes a |card, the device number is |NIC is activated |increased by one | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #42 from e.auler@gmx.de 2007-02-08 15:34 MST ------- (From update of attachment 116268) 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117195|netifacelog.myscript |text/plain filename| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117197|netifacelog.myscript.delaylo|text/plain filename|op | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117199|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117827|application/x-shellscript |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117939|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117195|application/octet-stream |text/plain mime type| | Attachment #117195|text/plain |netifacelog.myscript filename| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117197|application/octet-stream |text/plain mime type| | Attachment #117197|text/plain |netifacelog.myscript.delayloop filename| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #117200|application/octet-stream |text/plain mime type| | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #43 from dieter.jurzitza@t-online.de 2007-02-11 23:35 MST ------- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 h.weebers@kpnplanet.nl changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |h.weebers@kpnplanet.nl Status|ASSIGNED |NEEDINFO Component|Basesystem |Network Info Provider| |sven.burmeister@gmx.net Priority|P5 - None |P3 - Medium Platform|Other |64bit Found By|Other |Customer ------- Comment #44 from h.weebers@kpnplanet.nl 2007-04-11 14:49 MST ------- 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 < -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 zoz@novell.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED Info Provider|sven.burmeister@gmx.net | ------- Comment #45 from zoz@novell.com 2007-04-12 06:13 MST ------- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 ------- Comment #46 from sean.van.der.smythe@gmail.com 2007-04-20 00:25 MST ------- So will this bug be rectified in the next openSUSE release? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
https://bugzilla.novell.com/show_bug.cgi?id=230213 Christian Zoz <zoz@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|241982 | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=230213#c47 Christian Zoz <zoz@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Component|Network |Network Product|openSUSE 10.2 |openSUSE 10.3 Resolution| |FIXED Version|Final |unspecified --- Comment #47 from Christian Zoz <zoz@novell.com> 2007-07-26 10:07:32 MST --- 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. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=230213#c48 --- Comment #48 from Dieter Jurzitza <dieter.jurzitza@t-online.de> 2007-07-27 03:04:36 MST --- 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 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=230213#c49 Dieter Jurzitza <dieter.jurzitza@t-online.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #49 from Dieter Jurzitza <dieter.jurzitza@t-online.de> 2007-07-27 03:07:22 MST --- Bug should remain open until the issue depicted in #38 and #48 is fixed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=230213#c50 Christian Zoz <zoz@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #50 from Christian Zoz <zoz@novell.com> 2007-07-27 03:12:46 MST --- Read again comment 47: trigger_firmware_loading.sh has gone. Go for Alpha7 in the end of next week. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com