[SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

ScionicSpectre · 2011-07-06 03:16:56

Just put together a new computer with a Linux certified cast (of hardware) and decided I want my humble, simple Arch back after playing around with the new Ubuntu release. After installing from the static ISO (core, not netinstall), I proceeded to have absolutely no ability to update. I get an error saying 'no address recorded' for every possible mirror. Assuming no one staged a coup on the devs, I typed lspci to find I have an 82566DM network adapter, and ifconfig returns only the loopback interface, no eth0.

I read some posts that it might be an issue with the kernel version, but on the current official net install CD and the latest experimental ISO, the problem persists. I have modprobe'd e1000 and e1000e separately to see if I can start up the network and get eth0 to show up, but nothing happens. This isn't an issue on the latest Ubuntu or Debian, so I'm a bit confused on exactly how to resolve this. I assume they use a different, perhaps more updated version of these modules.

I've done everything I know short of compiling the new module myself, but the prospect of mounting a USB drive manually, migrating the source files, and compiling and installing the module repeatedly every kernel update is extremely uninviting. If it's the only solution, however, I may deal with it, since I love Arch so much. XD

I've scoured the internet and wikis for information, and done most I feel apt to do to troubleshoot the issue. If anyone has extra information on this module/hardware and what's likely happening, I'd appreciate it greatly. If it's unresolved I'll file a bug at least- I really don't want to use Debian right now.

P.S. I'm totally on x64. There is a chance i686 works, haven't tested it, but I'd really rather not use it for obvious reasons.

Last edited by ScionicSpectre (2011-07-08 23:34:58)

ewaller · 2011-07-06 03:19:54

ifconfig will only show the device if it is up.

What do either ifconfig -a or ip link say?

ScionicSpectre · 2011-07-06 03:39:51

Thank you for the quick response.

Well, this is odd. As soon as I executed ifconfig -a, the eth0 interface showed up on top (far too much information for me to remember to post here- unfortunately I have a hard time copying this information since I'm in two different rooms). Anyway, after that I typed ifconfig to make sure it still didn't show up there, but it did. So I restarted and now ifconfig by itself does display eth0. The e1000e module is what seems to start each time I boot, although e1000 is available. Regardless of which I'm using, however, my pacman updates still display errors, except this time rather than 'no address recorded', it's 'transient resolver failure' at the end of the line of each mirror I test against.

I'm not sure if that gets me closer or further from a solution, but if eth0 shows up, I'm sure there are some things I could do to try activating it. Also, ip link outputs that I have no ip command on my machine. I'll keep researching, but if anyone has an obvious next step I should take, please chime in. Networking errors like this are surely a rarity these days.

ewaller · 2011-07-06 03:44:00

Okay. What happens with dhcpcd eth0 ??

ScionicSpectre · 2011-07-06 03:58:04

Well, in the meantime I actually found someone suggesting to run dhcpcd, so I ran that without specifying eth0 (whoops), and it said something along these lines in this order.

Rebinding lease to 192.168.1.100
Acknowledged 192.168.1.100 to 192.168.1.1
Carrier Lost
MTU restored to 1500
Carrier Acquired
Leased for 86400 seconds
MTU set to 576
forked to background

So I pkilled dhcpcd to try it again with dhcpcd eth0, and it came up with this.

Rebinding lease to 192.168.1.100
Acknowledged 192.168.1.100 to 192.168.1.1
Checking for 192.168.1.100
Leased for 86400 seconds
MTU set to 576

On both attempts, pinging websites and trying to update packages failed, and pacman continues to give me the 'transient resolver failure' message. I rebooted and tried again with the same results- my apologies for crudely parsing the information from dhcpcd, but I think it should be sufficient for a basic understanding of what's going.

Last edited by ScionicSpectre (2011-07-06 03:59:15)

ewaller · 2011-07-06 04:10:56

We are getting there -- really.

Your card shows up, and you can acquire an address. Now you must tell it how to find the Internet by telling it about your gateway.

Look at the output of [ip route] and I'll bet you do not have a default gateway

ewaller@odin:~[127] 1024 %ip route
default via 192.168.1.1 dev wlan0  proto static 
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.8  metric 2 
192.168.56.0/24 dev vboxnet0  proto kernel  scope link  src 192.168.56.1 
ewaller@odin:~ 1025 %

Mine is at 192.168.1.1. coincidentally, so is yours

Try this (as root after running dhcpcd):
route add default gw 192.168.1.1

If that works, then we will automate this mess

ScionicSpectre · 2011-07-06 04:21:37

It's unfortunate, but after typing ip route, I got "bash: no command named ip" again. I wonder if this is normal on a base install- I only added a few extra packages like automake and pkg-config during installation, so maybe I should've added a few more? Or perhaps something's terribly wrong.

Either way, I took a leap of faith and entered route add default gw 192.168.1.1, and it returned nothing but "SIOCADDRT: no such process". I think I may be missing a package or two that aren't included in the base install, at least for the ISO on the download page. I'm fine picking up some packages and moving them from my USB to the offline computer if necessary, just not sure which ones would be necessary.

Last edited by ScionicSpectre (2011-07-06 04:23:36)

ewaller · 2011-07-06 04:41:22

Sorry, i missed that you don't have "ip" installed. You will once you get the network up and the installation updated route and ifconfig are deprecated and are being replaced.

ewaller@odin:~ 1027 %route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 vboxnet0
ewaller@odin:~ 1028 %

the route command will still give you the data in a different format.

Did you run the route add default gw 192.168.1.1 command as root ? After running dhcpcd? Just checking before I do some research.

ScionicSpectre · 2011-07-06 04:58:49

Yes, I executed them as typed in that order- I actually only have the root account for the moment, having no sudo. It's interesting- as soon as I execute route -n, it displays the same top two lines of your output, but nothing else. No actual information, just Kernel IP routing table and the headers for Destination, Gateway, Genmask, etc., with appropriate spacing, which implies they actually have information below them in some invisible mystery space. I still get the SIOCADDRT error message after trying to set the default gateway.

I hope this isn't complicating matters too much. Thank you for being patient and polite despite my somewhat disorganized and frequent replies. I'm not really familiar with networking in Linux since it never really comes up.

Last edited by ScionicSpectre (2011-07-06 05:00:14)

ewaller · 2011-07-06 05:02:44

Well, I need to pack it in for the night. Can you post the output of ifconfig -a and I'll pick it up in the morning.

ScionicSpectre · 2011-07-06 05:19:29

Thanks for the exceptional assistance so far. ifconfig -a returns the following.

eth0    Link encap:Ethernet  HWaddr 00:0F:FE:6C:15:BE
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:847 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2575 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:401010 (391.6 Kb)  TX bytes:320026 (312.5 Kb)
    Memory:f0500000-f0520000

And the loopback interface just has a ton of null values, but it says "inet addr:127.0.0.1 Mask:255.0.0.0," which seems expected to me, but it may be important. I'll keep researching in the meantime.

UPDATE: I have found a couple posts around the forum with nearly identical issues to mine, but they seem to end with things like, "well, I'm too busy to figure this out, so I'm installing Ubuntu." I definitely think the problem's more obvious than it's coming off to be, though.

I think it's worth noting that this computer has a 'twin' with the exact same components that oddly was able to do the net installation, but immediately had the same connection problems afterwards. So it may very well be an issue with my router and not entirely the driver, which means this may be a more appropriate post for Networking than Kernel and Hardware.

Anyway, I looked at my router's status page, and it seems my Default Gateway there is 24.2.80.1, and my Subnet Mask is actually 255.255.248.0. This may be significant.

Last edited by ScionicSpectre (2011-07-06 05:40:53)

ewaller · 2011-07-06 15:57:23

I looked at my router's status page, and it seems my Default Gateway there is 24.2.80.1, and my Subnet Mask is actually 255.255.248.0.

Not really. That is your Router's IP address and the route to the gateway it uses. Your network (192.168.1.*) is a separate network that is connected to the Internet through the gateway that is your router.

eth0    Link encap:Ethernet  HWaddr 00:0F:FE:6C:15:BE
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:847 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2575 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:401010 (391.6 Kb)  TX bytes:320026 (312.5 Kb)
    Memory:f0500000-f0520000

Well there's your problem. It seems we have made negative progress With dhcpcd running, I would have expected the card to have an IP address. It doesn't.

Rebinding lease to 192.168.1.100
Acknowledged 192.168.1.100 to 192.168.1.1
Carrier Lost
MTU restored to 1500
Carrier Acquired
Leased for 86400 seconds
MTU set to 576
forked to background
So I pkilled dhcpcd to try it again with dhcpcd eth0, and it came up with this.
Rebinding lease to 192.168.1.100
Acknowledged 192.168.1.100 to 192.168.1.1
Checking for 192.168.1.100
Leased for 86400 seconds
MTU set to 576

Whereas, both those examples show it had acquired 192.168.1.100. The first case, however, forked to the background. The second did not include that line Any chance you killed dhcpcd with a Ctrl-C or something?

Anyway, before adding a default gateway with route, you must have a valid IP address. ifconfig -a will tell you the address, if one is assigned.

ScionicSpectre · 2011-07-06 16:43:32

Yeah, that's what was confusing me, too. I always pkilled dhcpcd, but whenever I start my computer it seems to already have a handle on eth0, so I have to pkill it just to see what it's doing again. I wonder if there's any way to look back at what happened during the boot process to see what dhcpcd was doing. The network daemon may have some enlightening information if I can find information on that.

I'm considering chrooting into Arch from my Ubuntu Live CD (with persistence, so I can install a few packages if necessary), but I'm not sure if that would further complicate things. I think I'll wait for a recommendation on that, but it could make debugging a bit simpler.

Last edited by ScionicSpectre (2011-07-06 17:01:47)

lilsirecho · 2011-07-06 16:52:01

Perhaps the "no address record" problem can be resolved by commenting out the server used to install arch which appeared in my install as the last item in the mirrorlist. While you are there, establish the new pacnew list.

Good luck with the other issues.

ScionicSpectre · 2011-07-06 17:01:15

Ah, there's no more 'no address recorded' error, but I didn't actually use any servers to install Arch, since the netinstall CD had this same issue with internet connection. I have tried multiple mirrors on each try with pacman, though. I'm sure some of these mirrors may be out of date, since they're from the latest (old) core install CD.

Anyway, it looks like I lied to you twice, ewaller.

Taking a closer look, dhcpcd does indeed get forked to the background after I pkill it the first time and retry specifying eth0. So that's not an issue. Also, it looks like the output I typed was from before killing dhcpcd and restarting it, because after I do, ifconfig returns an extra line.

inet addr:192.168.1.100  Bcast:255.255.255.255  Mask:255.255.255.0

All the other output is largely the same as before. I think this information should make things a bit clearer- my apologies for some faulty troubleshooting.

EDIT: Just to be clear, trying the route add default gw 192.168.1.1 command fails with SIOCADDRT: no such process, just as before.

Last edited by ScionicSpectre (2011-07-06 17:08:06)

ScionicSpectre · 2011-07-06 20:49:09

Well, I'm in a chroot environment from a LiveUSB now, and everything seems to be in order (including the errors- they're still happening as they should be, lol). I did copy the resolv.conf from my Ubuntu LiveUSB to the one in the mounted Arch chroot environment, as specified in the wiki.

As soon as I ran dhcpcd from the chroot, however, pacman started working. I haven't rebooted yet, and I'm not sure if it's just because I'm in Ubuntu or something like that, but things seem to be functioning normally. I can ping any old website, install any package, and the bandwidth seems pretty decent.

It's a solution, but not a very straightforward or ideal one. Apologies to anyone who came to this post in the future looking for a more independent solution. I have yet to reboot and see if the changes have carried onto the actual installation. If not, we can keep troubleshooting along these lines.

ScionicSpectre · 2011-07-06 22:08:55

Well, good news for those of you looking for a solution without chrooting, because it didn't work. Everything's still screwed up when I boot into the actual environment. It's just a fully updated mess, now. :\

jni · 2011-07-06 22:51:35

If you see that line :

inet addr:192.168.1.100  Bcast:255.255.255.255  Mask:255.255.255.0

There is nothing else to do for the dhcp. Since you have no other NIC aside from eth0, "dhcpcd" or "dhcpcd eth0" should do the same and both should work.

Now, type in "route", if one of those start with "default 192.168.0.1", your routes have been updated properly.

Now try to ping google's dns, i.e. : "ping 4.4.4.4"

If that works, you have the net.

Now, try to ping a domain, i.e. : "ping google.com"

If that works, everything should be fine. It might just be a pacman configuration error.
If it doesn't, look into /etc/resolv.conf

Is it empty? If so, put the following in it :

nameserver 8.8.8.8
nameserver 4.4.4.4

And now "ping google.com" should work.

If it wasn't empty, don't touch it. The DHCP will most likely override it anyways.

Try this and give me some feedback as to what works and what doesn't and i'll help you the best i can!

ScionicSpectre · 2011-07-06 23:47:15

Well, this is utterly confusing. It turns out I wasn't lying back when I couldn't see the 'inet addr' line. Because it's happening again, and it happens on the LiveCDs as well. I have no idea how I got to the point that ifconfig was constantly giving me an internet address after running dhcpcd just once.

I've tried the command by itself and with eth0. I've also tried dhcpcd and dhcpcd eth0 after ifconfig eth0 down then back up, and doing all that after unloading and reloading the kernel module as well, and a few restarts in between. No combination of refreshing these commands is bringing me any closer to having that line again.

I'm very confused- I'm considering installing from the CD again from scratch just in case it was the update I did that's causing this. I feel like there are too many variables at work here. But if someone has an obvious way to get that line back, or some suggestion I haven't mentioned in the above paragraph, that'd be awesome.

Then I can get back to the next few steps, hopefully.

ScionicSpectre · 2011-07-07 00:21:06

I reinstalled everything from scratch from the 2010 ISO (on the download page, x86_64). Same problem- inet addr line just won't come up. I've retraced my steps throughout this entire thread and it still won't happen, even if I mistakenly try routing a default gateway like I did before. There's no way this problem can be so impossibly confounding when it doesn't even happen anywhere else. I've researched this problem to death and found very few similar issues, and each of those people ended up giving up and using some other distribution.

I really want to figure this out. XD At most, I might dual-boot something else while I try to find a solution, since this new machine's a beast. I can't stand Arch having a bug like this one, so I wanna' help fix it.

Last edited by ScionicSpectre (2011-07-07 00:22:11)

jni · 2011-07-07 00:32:43

try to get a static IP instead of relying on the DHCP.

EDIT : stop dhcpcd first here.

ifconfig eth0 down
ifconfig eth0 192.168.0.101 netmask 255.255.255.0 up
(if 192.168.0.101 is already in use on your network, pick another)

Now route -n should be empty. If not, remove entries and add them back (just in case)

route add default gw 192.168.0.1 netmask 255.255.255.0 dev eth0

Then try the "ping tests" from the post above. Does it work with a static ip like that?

Last edited by jni (2011-07-07 00:33:44)

ScionicSpectre · 2011-07-07 01:22:40

Man, I've always hated static IP, but if it gets me out of this I might reconsider it. XD

I did everything just as you wrote, jni. At the route -n step, it wasn't empty, but populated with some IP information (I'm not sure how I would 'remove' this). After I did the route command you posted, the route command output this.

Kernel IP routing table
Destination    Gateway        Genmask        Flags    Metric    Ref    Use    Iface
default        192.168.0.1    255.255.255.0    UG    0    0    0    eth0
192.168.0.0    *        255.255.255.0    U    0    0    0    eth0

I went on to attempt pinging 4.4.4.4, and was returned connect: Network is unreachable, and google.com obviously continued to say unknown host. Pacman still gives the same errors. I checked resolv.conf as well, and it was empty. I entered the nameservers and restarted and retried, but nothing changed so far as I can tell.

Hopefully that's more enlightening than it is confusing.

Last edited by ScionicSpectre (2011-07-07 01:24:03)

jni · 2011-07-07 01:25:45

after the ifconfig .... up, what would "ifconfig -a" say?

EDIT, do you have a computer on linux with a working net?

If so, can you post here the output from those commands on the computer where the net works. This way we can check your network config.

The following would be useful :

ifconfig -a
route -n

Let's begin with that

Last edited by jni (2011-07-07 01:27:37)

ScionicSpectre · 2011-07-07 01:44:50

In the Arch install, ifconfig -a brings up the following after putting the static IP up (I'm only including the inet addr line since it's the only one that seems to have any meaningful changes from the other similar output I've posted).

inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0

That's under the eth0 entry.

Interestingly, I looked up this forum post on my Kubuntu LiveUSB, as I'm aware that the networking in Debian is working 'out of the box', and hoped it could shed some light on why my settings are ineffective.

Here's eth0 from my Kubuntu USB.

eth0      Link encap:Ethernet  HWaddr 00:0f:fe:6c:15:be  
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:feff:fe6c:15be/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6198 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6377175 (6.3 MB)  TX bytes:814605 (814.6 KB)
          Interrupt:19 Memory:f0500000-f0520000

I noticed that the packets are orders of magnitude greater than my Arch packets (hence the increased reported bandwidth). The problem seems to reside in my trying to use the 0 subdomain instead of 1 at this point.

The command route -n returns this output.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

Hopefully that's enlightening enough. Also, resolv.conf for the heck of it.

# Generated by NetworkManager
domain hsd1.ut.comcast.net.
search hsd1.ut.comcast.net.
nameserver 68.87.85.102
nameserver 68.87.69.150

jni · 2011-07-07 01:58:43

damn, my bad. I assumed 192.168.0.1 for the router... it was 192.168.1.1... sorry for that mistake.

If you retry the static IP idea with the corrected router, does it work?

ifconfig eth0 down
ifconfig eth0 192.168.1.101 netmask 255.255.255.0 up
(again, if .101 is used, pick another)
route del default
route add default gw 192.168.1.1 netmask 255.255.255.0 dev eth0

and then, can you "ping 4.4.4.4" ?

Arch Linux

#1 2011-07-06 03:16:56

[SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#2 2011-07-06 03:19:54

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#3 2011-07-06 03:39:51

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#4 2011-07-06 03:44:00

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#5 2011-07-06 03:58:04

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#6 2011-07-06 04:10:56

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#7 2011-07-06 04:21:37

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#8 2011-07-06 04:41:22

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#9 2011-07-06 04:58:49

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#10 2011-07-06 05:02:44

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#11 2011-07-06 05:19:29

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#12 2011-07-06 15:57:23

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#13 2011-07-06 16:43:32

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#14 2011-07-06 16:52:01

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#15 2011-07-06 17:01:15

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#16 2011-07-06 20:49:09

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#17 2011-07-06 22:08:55

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#18 2011-07-06 22:51:35

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#19 2011-07-06 23:47:15

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#20 2011-07-07 00:21:06

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#21 2011-07-07 00:32:43

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#22 2011-07-07 01:22:40

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#23 2011-07-07 01:25:45

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#24 2011-07-07 01:44:50

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

#25 2011-07-07 01:58:43

Re: [SOLVED] Intel 82566DM Gigabit Network Adapter won't show up as eth0.

Board footer