eth0 - eth1 confusion vs. local network
in [Debian]
|
From: Frank Miles on 8 Feb 2010 23:30 I won't belabor this. Putting in a different NIC fixed things. No fuss, though interesting that it (presumably udev) wanted to call it eth2. I can live with that. Thanks again, everyone! -Frank -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Andrei Popescu on 9 Feb 2010 04:40 On Mon,08.Feb.10, 20:07:36, Frank Miles wrote: > I won't belabor this. > > Putting in a different NIC fixed things. No fuss, though interesting that it > (presumably udev) wanted to call it eth2. I can live with that. Of course it did, eth0 and eth1 were already taken ;) Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
From: Andrei Popescu on 10 Feb 2010 03:50 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
From: Alex Samad on 10 Feb 2010 05:00 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
From: Boyd Stephen Smith Jr. on 10 Feb 2010 11:20
In <20100210084608.GU14264(a)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(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/ |