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
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 elsew
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 w
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 rebo
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
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, 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 g
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 -
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 <
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
>>
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
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.
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 su
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
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 networ
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 o
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", SYSF
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 Mana
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, 00:13:8
19 matches
Mail list logo