FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 02-10-2010, 07:46 AM
Andrei Popescu
 
Default eth0 - eth1 confusion vs. local network

On Tue,09.Feb.10, 23:06:08, Stan Hoeppner wrote:
> Andrei Popescu put forth on 2/9/2010 3:37 AM:
> > On Mon,08.Feb.10, 16:33:39, Stan Hoeppner wrote:
> >
> >> So, are you saying it didn't happen? Couldn't have happened? Shouldn't have
> >> happened? I'm imagining things? Are you kidding?
> >
> > No, I'm saying that under normal circumstances it should work.
>
> I don't recall the exact circumstances.

Do you recall the time frame? The first mention of the
persistent-net-generator.rules in changelog.Debian.gz is from 21 Apr
2006. That means etch was the first stable release to include it.

> I don't know anything about these scripts. When do they run? And are they
> supposed to pin a mac addr to eth* name? That obviously didn't work if that's
> the case. Both these NICs have hard MAC addresses, as is required by the 802
> standard for any add-in ethernet card. It seems clear that the cause of the
> UDEV device naming problem was me swapping cards around.

Yes, the rule is supposed to pin by MAC. There were some issues with
built-in nvidia adapters which had a different MAC on each reboot (some
firmware bug, but I might be wrong)

> > Since your bug is quite unique (or at least no reports here on d-u) I
> > doubt it's good advice to tell someone having troubles with networking
> > to edit udev rules, especially since the OP mentioned the interface
> > names were ok and consistent.
>
> The mere existence of this Debian doc (and others) suggests that this UDEV
> eth0/eth1/etc naming problem is fairly common. Common enough for people to take
> the time to write a lengthy help document.
> http://www.debianhelp.co.uk/udev.htm

I can't find a date on that document.

> This was a pretty lengthy thread, many suggestions were made, and I was not the
> only one looking at udev device naming as potentially part of the OP's problem,
> yet you singled me out....hmm. I find it interesting that you single me out for
> this, given that in one post I firmly identified the root cause of the OP's
> problem, and recommended a solution, whilst telling the OP to come back and look
> at udev _only_ if he had device naming issues _after_ the root problem was solved.

Sorry if it looked like that. It was not my intention.

> Are you a UDEV developer or maintainer by chance Andrei?

Nope

> Did my statement below
> "I hate UDEV for this" strike a nerve and prompt your entry into this thread?
> If so please accept my apologies. I was merely stating _my_ perspective on my
> experience with my udev issue, not making any blanket statement about the
> quality of UDEV. I save that kind of remark for later, in the event I have
> problems with UDEV in the future.

Udev has created (and probably will still create) a lot of problems, no
doubt about it.

> Note how little text I devote to UDEV below, but how much I devote to the
> firmware issue which I correctly identified as the root cause of the OP's
> problem? I think your jumping on my UDEV comments is unjustified given the
> facts in the thread.

I merely tried to point out that the naming issues are a thing of the
past (not counting hidden bugs). Please accept my apologies if I
offended you in any way.

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
 
Old 02-10-2010, 08:50 AM
Alex Samad
 
Default eth0 - eth1 confusion vs. local network

On Wed, Feb 10, 2010 at 10:46:08AM +0200, Andrei Popescu wrote:
> On Tue,09.Feb.10, 23:06:08, Stan Hoeppner wrote:
> > Andrei Popescu put forth on 2/9/2010 3:37 AM:
> > > On Mon,08.Feb.10, 16:33:39, Stan Hoeppner wrote:

[snip]

> > I don't know anything about these scripts. When do they run? And are they
> > supposed to pin a mac addr to eth* name? That obviously didn't work if that's
> > the case. Both these NICs have hard MAC addresses, as is required by the 802
> > standard for any add-in ethernet card. It seems clear that the cause of the
> > UDEV device naming problem was me swapping cards around.
>
> Yes, the rule is supposed to pin by MAC. There were some issues with
> built-in nvidia adapters which had a different MAC on each reboot (some
> firmware bug, but I might be wrong)
so just for clarity, it pins an eth0 to a mac so it doesn't matter when
the kernel sees it it will always keep it ethX name....

>

[snip]

> > Note how little text I devote to UDEV below, but how much I devote to the
> > firmware issue which I correctly identified as the root cause of the OP's
> > problem? I think your jumping on my UDEV comments is unjustified given the
> > facts in the thread.
>
> I merely tried to point out that the naming issues are a thing of the
> past (not counting hidden bugs). Please accept my apologies if I
> offended you in any way.

my 2c =, I have found the udev naming scripts to be very useful, I have
run foul of any problems, except when I forgot that they had run .


>
> Regards,
> Andrei
 
Old 02-10-2010, 03:17 PM
"Boyd Stephen Smith Jr."
 
Default eth0 - eth1 confusion vs. local network

In <20100210084608.GU14264@think.homelan>, Andrei Popescu wrote:
>On Tue,09.Feb.10, 23:06:08, Stan Hoeppner wrote:
>> I don't know anything about these scripts. When do they run?

Udev is a daemon, started fairly early in the boot process. It communicates
with the kernel. It evaluates the rules each time the kernel notifies it of
new hardware.

Udev may not be a panacea, but it is better than a static /dev (what we had in
the bad old days) or even devfs (which the administrator couldn't really
control). They assigned persistent names to devices only because the kernel
hardware probing was synchronous and slow. Of course, that didn't prevent a
USB key from turning into /dev/hda if you booted with it inserted.

Once the 2.6 line introduced asynchronous hardware probing, something like
udev was critically needed. It allows the user to assign persistent names
based on attributes the kernel detects, in a fairly generic fashion. For the
most part it is devfs compatible, since in the absence of rule it uses the
"kernel device name". Most of the problems blamed on udev are not because of
udev, but rather because of changes in the way the kernel probes hardware --
which changes the order devices are discovered in. If you were using devfs or
static /dev you would experience the same "name-changing" behavior, you just
couldn't fix it without a kernel patch.

>> And are
>> they supposed to pin a mac addr to eth* name? That obviously didn't work
>> if that's the case. Both these NICs have hard MAC addresses, as is
>> required by the 802 standard for any add-in ethernet card. It seems clear
>> that the cause of the UDEV device naming problem was me swapping cards
>> around.
>
>Yes, the rule is supposed to pin by MAC. There were some issues with
>built-in nvidia adapters which had a different MAC on each reboot (some
>firmware bug, but I might be wrong)

I had this issue (maybe still have). I have /etc/network/interfaces set my
MAC addresses as the interfaces are brought up, as otherwise the hardware
reports invalid MACs and the kernel randomizes them. I have my own udev rules
that use names based on PCI address.

I remember I got up to eth8/9 before I figured out how to fix it.

Using the MAC addresses seems like a good solution most of the time. It does
normally mean that replacing a NIC results in a new name, but it handles the
case of PCMCIA / USB / Bluetooth NICs quite well.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
 

Thread Tools




All times are GMT. The time now is 04:45 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org