[opensuse] eth0 become eth1 after upgraded
Dear all I've upgraded SuSE 10.2 workstation by changed the motherboard. Both the old motherboard and the new one have on-board ether card. After reboot, ether network stopped working. I go to Yast -> Network devices -> Network card and see two cards there. I remove the old on-board card and select the new on-board card to configure it using DHCP. Reboot the machine I got the new card working as eth1. /sbin/ifconfig -a shows I have only 3 interfaces, eth1, lo, sit0. Then my vmplayer stopped working and complain ether network bridge is not available. Reading vmplayer document I discovered vmplayer always try to build ether network bridge using the first ethernet device, presumably eth0. My eth0 no longer exist and that's why vmplayer doesn't work. The suggested solution is to let me start VMWorkstation and configure it to use eth1. But I don't have VMWorkstation, it's too expensive for me, if I buy a copy of VMWorkstation to fix this issue I can use the money to buy some new computers! Then next solution I think is to make SuSE use ifname "eth0" for the new on-bard card. I noticed dmesg said something strange: zhangweiwu@joe:~> dmesg | grep -i eth 8139too Fast Ethernet driver 0.9.27 eth0: RealTek RTL8139 at 0xf0a16400, 00:13:8f:dd:cc:03, IRQ 201 eth0: Identified 8139 chip type 'RTL-8101' eth0 renamed to eth1 eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 bridge-eth0: peer interface eth0 not found, will wait for it to come up bridge-eth0: attached Seems the on-board card /was/ eth0, it's getting renamed to eth1 for some reason. This behavior is not noticed on other distros. I think I can solve my problem by disabling this rename. I am using traditional ifup and I tried using Network Manager wouldn't help (rename still happen). How can I disable renaming eth0 to eth1? Unfortunately vmplayer is vital to my business; I cannot live a week without Windows that runs on it (live a day without Windows is okay). Too many business application rely on it. Name a few: taobao (monoplay c2c online-trading site in China), governmental tax office website (if I say I cannot pay tax because they require windows, I'll eat tickets), mandatory ICP registration website (without it the website is blocked by GFW). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Aug 26 2007 16:54, Zhang Weiwu wrote:
Then next solution I think is to make SuSE use ifname "eth0" for the new on-bard card. I noticed dmesg said something strange:
zhangweiwu@joe:~> dmesg | grep -i eth 8139too Fast Ethernet driver 0.9.27 eth0: RealTek RTL8139 at 0xf0a16400, 00:13:8f:dd:cc:03, IRQ 201 eth0: Identified 8139 chip type 'RTL-8101' eth0 renamed to eth1 eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 bridge-eth0: peer interface eth0 not found, will wait for it to come up bridge-eth0: attached
Seems the on-board card /was/ eth0, it's getting renamed to eth1 for some reason.
Eh well. What I can think of: you previously had a PCI network card. Since cards on the PCI bus are usually detected before any on-board stuff (rightfully so), eth0 is your PCI card, and eth1 is onboard. SUSE then makes sure this is the case on every boot, even if you remove the PCI one. Does that apply?
How can I disable renaming eth0 to eth1?
Just change it to your preferred name, edit /etc/udev/rules.d/30-net_persistent_names.rules Jan -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Jan Engelhardt wrote:
On Aug 26 2007 16:54, Zhang Weiwu wrote:
[...] Seems the on-board card /was/ eth0, it's getting renamed to eth1 for some reason.
Eh well. What I can think of: you previously had a PCI network card. Since cards on the PCI bus are usually detected before any on-board stuff (rightfully so), eth0 is your PCI card, and eth1 is onboard. SUSE then makes sure this is the case on every boot, even if you remove the PCI one. Does that apply?
By the way: we had the same problem when we upgraded from RHEL4.4 to RHEL4.5. No hardware has been changed during this upgrade. See also [1] for a similar problem. It's a bit more general and not only opensuse related. Th. [1]http://groups.google.com/group/linux.debian.user/browse_thread/thread/653281... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 26/08/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
Jan Engelhardt wrote:
On Aug 26 2007 16:54, Zhang Weiwu wrote:
[...] Seems the on-board card /was/ eth0, it's getting renamed to eth1 for some reason.
Eh well. What I can think of: you previously had a PCI network card. Since cards on the PCI bus are usually detected before any on-board stuff (rightfully so), eth0 is your PCI card, and eth1 is onboard. SUSE then makes sure this is the case on every boot, even if you remove the PCI one. Does that apply?
By the way: we had the same problem when we upgraded from RHEL4.4 to RHEL4.5. No hardware has been changed during this upgrade. See also [1] for a similar problem. It's a bit more general and not only opensuse related.
You shouldn't really rely on the ethX numbering remaining the same, they can change at any time. It depends on what interface comes up first. To refer to the interface in scripts you can use the eth-id or give it a PERSISTENT_NAME ( http://www-uxsup.csx.cam.ac.uk/pub/doc/suse/suse9.3/suselinux-adminguide_en/... ) _ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Benji Weber wrote:
[...]
You shouldn't really rely on the ethX numbering remaining the same, they can change at any time.
No, I expect it to be the same when performing an update (as we did) - if an update causes problems like that, something has gone wrong and the distributor did a bad job. An update is not allowed to change any critical system settings. The situation is different when you perform an upgrade, i.e. you install a complete new version of a distribution... Th. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 26/08/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
No, I expect it to be the same when performing an update (as we did) - if an update causes problems like that, something has gone wrong and the distributor did a bad job. An update is not allowed to change any critical system settings. The situation is different when you perform an upgrade, i.e. you install a complete new version of a distribution...
It's not a critical system setting, it may change just on a reboot, if you change nothing... _ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 August 2007, Benji Weber wrote:
On 26/08/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
No, I expect it to be the same when performing an update (as we did) - if an update causes problems like that, something has gone wrong and the distributor did a bad job. An update is not allowed to change any critical system settings. The situation is different when you perform an upgrade, i.e. you install a complete new version of a distribution...
It's not a critical system setting, it may change just on a reboot, if you change nothing...
Not Critical? Who says its not? The bitching about this name change has been loud and long all over the net for every distro that did not add a feature to nail it down. There are a LOT of utilities that depend on static interface names, and not all of them have been fixed to account for this as the OP has quickly found out. This is another of those caviler changes that Linux is so famous for. No warning, no rationale, so solutions until the bitch level gets high. usbfs-->sysfs Screw-you Vmware smfbs-->cifs Screw-you Win98 shares hda-->sda Screw-you 16partitions YOU-->Zmd Screw you entire userbase -- _____________________________________ John Andersen
On 27/08/07, John Andersen <jsa@pen.homeip.net> wrote:
On Sunday 26 August 2007, Benji Weber wrote:
On 26/08/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
No, I expect it to be the same when performing an update (as we did) - if an update causes problems like that, something has gone wrong and the distributor did a bad job. An update is not allowed to change any critical system settings. The situation is different when you perform an upgrade, i.e. you install a complete new version of a distribution...
It's not a critical system setting, it may change just on a reboot, if you change nothing...
Not Critical? Who says its not?
The bitching about this name change has been loud and long all over the net for every distro that did not add a feature to nail it down.
There is a feature for static names, just the ethX names are not the static ones. I fail to see what your point is, If you want persistent names use the persistent names, if you want non-persistent names use the ethX. _ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Aug 27 2007 23:17, Benji Weber wrote:
There is a feature for static names, just the ethX names are not the static ones.
Says who? There is a __reason__ as to why udev renames it the following way: eth0 renamed to ethxx0 eth1 renamed to ethxx1 ethxx1 renamed to eth0 ethxx0 renamed to eth1 I renames them to ORIGXXN first, so that you _can_ have ethX names the way you want.
I fail to see what your point is, If you want persistent names use the persistent names, if you want non-persistent names use the ethX.
PERSISTENT_NAME in /etc/sysconfig/network/ifcfg-... has been superseded by udev rules in 10.2. Jan -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Benji Weber wrote:
On 26/08/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
No, I expect it to be the same when performing an update (as we did) - if an update causes problems like that, something has gone wrong and the distributor did a bad job. An update is not allowed to change any critical system settings.
It's not a critical system setting, it may change just on a reboot, if you change nothing...
You are a funny guy, right? Have you ever worked in an environment where Linux systems are actually used in production (large-scale)? I guess the obvious answer is no, otherwise you would know that these settings are critical. They are not allowed to change during or after a simple update (patch), certainly not in an enterprise version which (by definition) should provide a stable environment. Sorry, but sometimes I can only shake my head when reading these overly naive statements. Geez, it's time to end this thread... PS: Please do NOT send private copies of list emails. I am reading this mailing list - why do you think I want to receive your emails twice? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
If its so so so so critical, you might as well take your time to read /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names Or hire a system administrator that knows that. Would be important for a system like the one you described. Best regards Marcio On 8/27/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
Benji Weber wrote:
On 26/08/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
No, I expect it to be the same when performing an update (as we did) - if an update causes problems like that, something has gone wrong and the distributor did a bad job. An update is not allowed to change any critical system settings.
It's not a critical system setting, it may change just on a reboot, if you change nothing...
You are a funny guy, right? Have you ever worked in an environment where Linux systems are actually used in production (large-scale)? I guess the obvious answer is no, otherwise you would know that these settings are critical. They are not allowed to change during or after a simple update (patch), certainly not in an enterprise version which (by definition) should provide a stable environment. Sorry, but sometimes I can only shake my head when reading these overly naive statements. Geez, it's time to end this thread...
PS: Please do NOT send private copies of list emails. I am reading this mailing list - why do you think I want to receive your emails twice?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 27 Aug 2007 22:30:00 +0100, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
Sorry, but sometimes I can only shake my head when reading these overly naive statements. Geez, it's time to end this thread...
PS: Please do NOT send private copies of list emails. I am reading this mailing list - why do you think I want to receive your emails twice?
A) Hey, take it easy fella! People only trying to help here, and for free too. If the advice is no good, you could at least say "thanks anyway" and look elsewhere for advice. B) The fact that you get email sent to you as well as the list is to do with some quirk of the "reply all" system. It means that (perhaps only on some clients) you have to remember to remove the poster's name from the To secion and just leave the list address. If you don't notice that or forget, then the sender will get a mail too. Regards, David -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Monday 27 August 2007 17:07, d_garbage wrote:
B) The fact that you get email sent to you as well as the list is to do with some quirk of the "reply all" system. It means that (perhaps only on some clients) you have to remember to remove the poster's name from the To secion and just leave the list address. If you don't notice that or forget, then the sender will get a mail too. Also on some lists (not this list) the list netiquette is to send to both--- thank goodness most list users don't do that.
-- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Am Dienstag, 28. August 2007 00:07 schrieb d_garbage:
A) Hey, take it easy fella! People only trying to help here, and for free too. If the advice is no good, you could at least say "thanks anyway" and look elsewhere for advice. Uhm.. AFAIK Thomas was someone who gave an advice, not the one who asked a question :)
And I can understand him, private emails are disturbing if they appear to often, although, he didn't sound very angry. Greetings Michael
On Mon, 27 Aug 2007 23:39:19 +0100, Michael Skiba <michael@michael-skiba.de> wrote:
Am Dienstag, 28. August 2007 00:07 schrieb d_garbage:
A) Hey, take it easy fella! People only trying to help here, and for free too. If the advice is no good, you could at least say "thanks anyway" and look elsewhere for advice. Uhm.. AFAIK Thomas was someone who gave an advice, not the one who asked a question :)
Greetings Michael
Ah, yes, sorry, bit sleepy here. Yes, read back thought the archive. Heh, anyway, sorry i got that a bit muddled. Wonder what Zhang Weiwu thinks about all this? Are they reading up about static names i wonder? Cheers, David -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 27/08/07, Thomas Hertweck <Thomas.Hertweck@web.de> wrote:
You are a funny guy, right? Have you ever worked in an environment where Linux systems are actually used in production (large-scale)? I guess the obvious answer is no, otherwise you would know that these settings are critical. They are not allowed to change during or after a simple update (patch), certainly not in an enterprise version which (by definition) should provide a stable environment. Sorry, but sometimes I can only shake my head when reading these overly naive statements. Geez, it's time to end this thread...
My point is this particular setting might just change after a reboot, it might have nothing to do with a patch. There are persistent names you can rely on, or you can choose to gamble that the ethX names that are transient may remain the same after a reboot or reloading the driver. _ Benjamin Weber -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Benji Weber wrote:
[...]
My point is this particular setting might just change after a reboot, it might have nothing to do with a patch.
There are persistent names you can rely on, or you can choose to gamble that the ethX names that are transient may remain the same after a reboot or reloading the driver.
You still don't get it. But I don't have time to explain it over and over again. If you don't understand the purpose of an update and why it's important that no settings change during an update, then it's a waste of time anyway. I'll remind you of this thread next time you run YOU and something stops working afterwards... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday 26 August 2007, Zhang Weiwu wrote:
Seems the on-board card /was/ eth0, it's getting renamed to eth1 for some reason. This behavior is not noticed on other distros. I think I can solve my problem by disabling this rename. I am using traditional ifup and I tried using Network Manager wouldn't help (rename still happen).
How can I disable renaming eth0 to eth1?
see the file named /etc/udev/rules.d/30-net_persistent_names.rules The address bit in that file corresponds to your mac address (run /sbin/ifconfig to get the mac). Just change the ethX bit at the end of the line to be what you want, and perhaps delete the other un-wanted one. -- _____________________________________ John Andersen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sunday, 26 August 2007 20:54:59 Zhang Weiwu wrote:
How can I disable renaming eth0 to eth1?
Edit /etc/udev/rules.d/30-net_persistent_names.rules and delete/rename cards as appropriate so that the MAC address and netiface name are what you want. Example: SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:13:d4:b6:ec:44", IMPORT="/lib/udev/rename_netiface %k eth0" Then reboot. Hope this helps. -- Regards Scott Newton -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Thanks for everyone answered my question. The problem is solved by editing /etc/udev/rules.d/30-net_persistent_names.rules as Jan Engelhardt, John Andersen, Scott Newton suggested. Jan Engelhardt said I probably previously had PCI NIC. I am 100% sure it was on-board NIC. Benji Weber made good suggestion that scripts / applications should not assume first available ethernet interface is eth0. I agree on this point but at least two application assumed this: 1) vmplayer; 2) opensuse yast, in 10.0 version it assume eth0 is available made me impossible to dial PPP on a special ether card, but the problem is gone in 10.1 Thanks all again! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (10)
-
Benji Weber -
d_garbage -
Druid -
Jan Engelhardt -
John Andersen -
M Harris -
Michael Skiba -
Scott Newton -
Thomas Hertweck -
Zhang Weiwu