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
Benji Weber wrote:
On 26/08/07, Thomas Hertweck [EMAIL PROTECTED] 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
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
On Mon, 27 Aug 2007 22:30:00 +0100, Thomas Hertweck
[EMAIL PROTECTED] 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 -
On 27/08/07, John Andersen [EMAIL PROTECTED] wrote:
On Sunday 26 August 2007, Benji Weber wrote:
On 26/08/07, Thomas Hertweck [EMAIL PROTECTED] 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
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
On 27/08/07, Thomas Hertweck [EMAIL PROTECTED] 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
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
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
On Mon, 27 Aug 2007 23:39:19 +0100, Michael Skiba
[EMAIL PROTECTED] 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
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
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:
[EMAIL PROTECTED]:~ dmesg | grep -i eth
8139too Fast Ethernet driver 0.9.27
eth0: RealTek RTL8139 at 0xf0a16400,
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
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,
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
On 26/08/07, Thomas Hertweck [EMAIL PROTECTED] 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
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
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
On 26/08/07, Thomas Hertweck [EMAIL PROTECTED] 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
On Sunday 26 August 2007, Benji Weber wrote:
On 26/08/07, Thomas Hertweck [EMAIL PROTECTED] 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
20 matches
Mail list logo