[gentoo-amd64] server setting up funny interfaces

[gentoo-amd64] server setting up funny interfaces

[Mark Haney]

I've got a server doing something weird with it's network interfaces. 
It's got one NIC in it, and from the live CD it sees that NIC as ETH0.

However, no matter what I do on boot from the HDD, it sees that 
interface as ETH1.  Even though it was originally setup as ETH0.  And 
now, on a reboot, none of the networking services starts up because the 
system thinks eth0 does not exist.

I can start eth1, but then ssh and all the other services (SSH and BIND 
mostly) refuse to start because they are looking for eth0.

Any ideas on how to fix this?


-- 
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

Re: [gentoo-amd64] server setting up funny interfaces

[Qian Qiao]

On Tue, Nov 18, 2008 at 13:24, Mark Haney <mhaney@ercbroadband.org> wrote:
> I've got a server doing something weird with it's network interfaces. It's
> got one NIC in it, and from the live CD it sees that NIC as ETH0.
>
> However, no matter what I do on boot from the HDD, it sees that interface as
> ETH1.  Even though it was originally setup as ETH0.  And now, on a reboot,
> none of the networking services starts up because the system thinks eth0
> does not exist.
>
> I can start eth1, but then ssh and all the other services (SSH and BIND
> mostly) refuse to start because they are looking for eth0.
>
> Any ideas on how to fix this?

I assume you use udev, if that's the case, take a look at
/etc/udev/rules.d/SOME_NUMBER-persistant-net.rules

HTH.

Joe

-- 
There are 3 kinds of people in the world: those who can count, and
those who can't.

Re: [gentoo-amd64] server setting up funny interfaces

[Raffaele BELARDI]

Mark Haney wrote:
> I've got a server doing something weird with it's network interfaces.
> It's got one NIC in it, and from the live CD it sees that NIC as ETH0.
>
> However, no matter what I do on boot from the HDD, it sees that
> interface as ETH1.  Even though it was originally setup as ETH0.  And
> now, on a reboot, none of the networking services starts up because the
> system thinks eth0 does not exist.

Check
/etc/udev/rules.d/70-persistent-net.rules

there will probably be another interface with the "eth0" name. Just
delete it and move the eth0 name to your current interface.

raf

Re: [gentoo-amd64] server setting up funny interfaces

[Mark Haney]

Raffaele BELARDI wrote:

> 
> Check
> /etc/udev/rules.d/70-persistent-net.rules
> 
> there will probably be another interface with the "eth0" name. Just
> delete it and move the eth0 name to your current interface.
> 
> raf
> 

Well that's just stupid.  I've had this problem for 2+ years now and 
since that server is only used for testing bandwidth speeds with FTP 
I've not really tried to fix it until now.

I'm really ashamed it was that easy.  I should have my geek card suspended.


-- 
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

Re: [gentoo-amd64] server setting up funny interfaces

[Bob Sanders]

Mark Haney, mused, then expounded:
> Raffaele BELARDI wrote:
>
>> Check
>> /etc/udev/rules.d/70-persistent-net.rules
>> there will probably be another interface with the "eth0" name. Just
>> delete it and move the eth0 name to your current interface.
>> raf
>
> Well that's just stupid.  I've had this problem for 2+ years now and since 
> that server is only used for testing bandwidth speeds with FTP I've not 
> really tried to fix it until now.
>
> I'm really ashamed it was that easy.  I should have my geek card suspended.
>

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.

Bob
-  

Re: [gentoo-amd64] server setting up funny interfaces

[Bob Sanders]

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.

Bob 
-  

[gentoo-amd64] Re: server setting up funny interfaces

[Duncan]

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.

Luckily I had seen the post-inst warning about possible persistent-
net.rules problems, and while I had blown it off earlier as not having 
any such configured, knew where to look as a result of that warning when 
things went wrong.  Except the warning said just delete the file and 
retrigger, and that didn't seem to work.  I ended up editing the detailed 
entry it created pointing at eth1, to point to eth0 instead.  That fixed 
the problem.

That was yesterday.  With today's update, I see udev-132 is now masked 
and it wanted to downgrade.  But since I already had fixed the problem on 
my own, I just added a udev-132 entry to my package.unmask file and kept 
it.  One of the bugs mentioned in the masking entry says udev-133 is 
available upstream, but it wasn't in portage yet when I did today's 
updates.  It's possible I'll have to tweak things again for it, since I 
tweaked them special for -132.  Oh, well.  Just part of working with 
~arch, I guess.  If I wasn't up for the challenge of dealing with 
occasionally broken ~arch packages, my interest in computers would 
instead be something like an interest in watching the turntable in the 
microwave go round and round... or perhaps being a brainless TV zombie 
getting programmed by all the stupid ads... boring!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: server setting up funny interfaces

[Mark Haney]

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