From: "Mark Haney" <mhaney@ercbroadband.org>
To: <gentoo-amd64@lists.gentoo.org>
Subject: Re: [gentoo-amd64] Re: server setting up funny interfaces
Date: Tue, 18 Nov 2008 13:54:22 -0500 [thread overview]
Message-ID: <49230F5E.6020002@ercbroadband.org> (raw)
In-Reply-To: <pan.2008.11.18.18.21.33@cox.net>
Duncan wrote:
> Bob Sanders <rsanders@sgi.com> posted 20081118163554.GB160178@sgi.com,
> excerpted below, on Tue, 18 Nov 2008 08:35:54 -0800:
>
>> Bob Sanders, mused, then expounded:
>>> Actually, it's even easier - just delete
>>> /etc/udev/rules.d/70-persistent-net.rules and reboot. Udev will create
>>> a new /etc/udev/rules.d/70-persistent-net.rules with the correct
>>> information.
>>>
>> I'll caveat this a bit. It works fine in simple cases - onboard GigE.
>> But in systems with add-in ethernet, GigE, or 10GigE cards,
>> /lib/udev/write_net_rules will usually make the add-in card eth0. Some
>> Quad GigE cards have rather weird port setups or PCI-bridge addressing
>> schemes that end up with port 2 of 4 as eth0.
>>
>> In those cases, it's best to write 70-persistent-net.rules the way you
>> want it. But remember - the mac addr has to be lower case, and all the
>> syntax correct or udev will re-write it.
>
> It's also worth noting for those using ~arch udev, that there was an
> issue with persistent-net.rules in udev-132, which is now masked.
>
> I run an all ~arch system, and while I didn't configure a persistent net
> (only one Ethernet interface to worry about, eth0 it should be and has
> been), udev-132 caused problems for me due to that file anyway. For some
> reason, with udev-132, my Broadcom Tigon-3 based device was triggering
> two different entries, the first a generic entry matching the MAC
> address, the second also matching the MAC address but with a bit more
> detail. The first was setup as eth0, so when the second, apparently the
> actually active one, appeared, it got set to eth1.
Duncan, the server I had this trouble with only had one interface. It's
a blade and it started acting up well over a year ago with this problem.
I don't use DHCP on that server, and hard coded the IP and default gw on
it and still had it acting up. I didn't do anything specific it, it's a
setup I've done a hundred times before on those blades. Weird.
--
Frustra laborant quotquot se calculationibus fatigant pro inventione
quadraturae circuli
Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415
Call (866) ERC-7110 for after hours support
prev parent reply other threads:[~2008-11-18 18:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-18 13:24 [gentoo-amd64] server setting up funny interfaces Mark Haney
2008-11-18 13:27 ` Qian Qiao
2008-11-18 13:30 ` Raffaele BELARDI
2008-11-18 14:21 ` Mark Haney
2008-11-18 16:03 ` Bob Sanders
2008-11-18 16:35 ` Bob Sanders
2008-11-18 18:21 ` [gentoo-amd64] " Duncan
2008-11-18 18:54 ` Mark Haney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49230F5E.6020002@ercbroadband.org \
--to=mhaney@ercbroadband.org \
--cc=gentoo-amd64@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox