You are not logged in.
Hi guys,
so this is kinda my first post, not that I'm new to arch i just never had an issue i couldn't figure out on my own... But i love arch i have been using it for about a year now and have had no serious problems except for this. I have had arch running on an older dell vostro 200 desktop before i reinstalled with a vary similar issue except that the fix i came up with doesn't work anymore. I will tell you about the first issue first because i ALMOST posted on here about it originally but i figured out a way to make it work even though it was a hassle.
After cold/rebooting my computer the network card doesn't work at all. lspci reported that the kernel module e1000e was the correct one (i have verified this) and that the kernel has loaded it, i verified that with dmesg but still it wouldn't work. After much much anguish and hairpulling, I realized that it had to have something to do with the module so i tried forcing it to reload with rmmod e1000e and modprobe e1000e and it still wouldn't work until i physically unpluged the ethernet cord and pluged it back in until the light on the NIC turned on. After that everything works as normal i could even unplug and plug it back in with no problems. So eventually i wrote a script that did this for me (except for the uplugging and plugging part) and i used that when i cold/rebooted.
But now i have the exact same issue after reinstalling arch to the T except for the fact that the (crazy) fix i came up with doesn't work now. I used my "fix" after booting from the arch cd and it worked just like it always has. And now after rebooting into my fresh system the fix doesn't work anymore. So now i'm back where i was to begin with but i have no idea what to try next. I didn't do anything particularly different during installation except i added a udev rule for the e1000e module just to see if somehow that would fix the problem... it didnt and i have since deleted that (to see if it was the problem). The only other thing that is different is the root and home are now btrfs partitions instead of ext4.
I have booted several other live cds and dvds (diferent distros) including arch derivatives such as manjaro and they all worked just fine, using the same kernel module (e1000e). I'm not sure what that could mean but i know that it means there is a fix for this some way or another. I am going to hook up a wifi adapter and connect that computer to the internet to put some more information up if it's needed (asked for) but for now lspci -vnn | grep -i -A 10 net reports
00:19.0 Ethernet controller [0200]: Intel Corporation 82562V-2 10/100 Network Connection [8086:10c0] (rev 02)
Subsystem: Dell Device 0238
Flags: bus master, fast devsel, latency 0, IRQ 42
Memory at fdfc0000 (32-bit non-prefetchable) [size=128k]
Memory at fdfff000 (32-bit non-prefetchable) [size=4k]
I/0 ports at ff00 [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Vendor Specific Information: Len=06 <?>
Kernel driver in use: e1000e
Kernel modules: e1000eip a reports:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: enp0s25: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:1d:09:8c:36:f6 brd ff:ff:ff:ff:ff:ff
4: wlp0s29f7u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 64:66:b3:16:92:10 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.55/16 brd 172.16.255.255 scope global wlp0s29f7u3
valid_lft forever preferred_lft forever
inet6 fe80::6666:b3ff:fe16:9210/64 scope link
valid_lft forever preferred_lft foreverlsmod | grep e1000e
e1000e 215644 0
ptp 17692 1 e1000eany help on what to do next would be greatly appreciated.
Last edited by mvheart/dev/null (2014-08-18 04:02:12)
Offline
Welcome to the forums. Please take the following only as advice that should help you get assistance, as that is how it is meant: I think some revision to the writing could make this post more likely to be responded to. Upon seeing a wall of text with no obvious command/log output I could jump to, I almost didn't read this.
When I did read through it, I struggled with parsing sentences like the following due to sparse punctuation:
I would have to reload the module and physically unplug and replug the ethernet cord and 7 out of 10 times that would work the very first try every once in a while i would have to keep unplugging it and plugging it back in until it worked but it always would eventually light up when i plugged in the cord
It seems whether I can understand the meaning of that sentence or not, is not important. But with that, leave out what is not important and help us get to the core of the issue.
For this core of this issue more information other than the presence or absence of the light on the NIC would be helpful. The lspci output is good, but can you also throw in the output of the following:
lspci -vnn | grep -i net
ip a
lsmod"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I understand completely, I will edit my original post. I was trying to hurry and get something up because I wanted to be able to post some code using the actual computer in question. Most of those outputs are quite long and i would much rather cut and paste them than copy it from on screen, that also takes away the human error factor of typing it. Give me 15 or 20 minutes to get a working internet connection and i will edit my orignal post and add those outputs.
Thanks for your response
Offline
mvheart/dev/null ,
Your problem looks very similar to the one described here : https://bbs.archlinux.org/viewtopic.php?id=185765 .
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Thanks Lone Wolf I will look into that, but its seems to me that if that was the case i would have an issue with all distros not just arch. But i will definitely give upgrading the BIOS a try and post any changes...
Offline
Thanks for the revisions. I was expecting that the card would not show up in the `ip` output, but it seems it does. So while the light on the NIC being off is indeed unusual, what is the first step in a connection process that actually fails and/or indicates there is a problem?
Can you set the interface up? If so, can dhcpcd or dhclient run?
This may be some power-saving mode of the NIC - though while I know these modes exist, that's about all I know about them at the moment.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I agree that is very strange and it is why i personally beleive i have a different issue than those on the post that lone wolf linked. I'm not positive but i beleive that before on my previous install, I could definitely set the link up and even start dhcpcd or netctl and at that point dhcpcd would throw errors but it would still try to connect like the device worked that is why the light on the NIC became my indicator of it being in order. But now that is not the case:
[aaron@arch-box Arch-Linux]$ sudo ip link set enp0s25 up
[aaron@arch-box Arch-Linux]$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4: wlp0s29f7u3: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
link/ether 64:66:b3:16:92:10 brd ff:ff:ff:ff:ff:ff
5: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether 00:1d:09:8c:36:f6 brd ff:ff:ff:ff:ff:ffI'm not sure what this means and if maybe i just did something different during the install process that has made this unfixable. But even in it's previous state there was something wrong...
Offline
That command worked as expected, the interface is UP. Now run dhcpcd or dhclient.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Tribly I have found a link here to a another forum post about my specific ethernet card causing a different problem because of its power saving modes. I think you could be very right about that being the cause of this. But fixing it is another issue intirely, there was someone on there that linked a driver module that disabled Intels power saving mode but it has since been moved or changed. Honestly it being that old i would be surprised if those featurs werent available now someway or another.
Offline
The interface is up, but it doesn't seem to be connected to anything eg.
<net1 disconnected from switch>
$ ip link net1
4: net1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
$ sudo ip link set net1 up
$ ip link net1
4: net1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
<connect net1 to switch>
$ ip link net1
4: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000Last edited by alphaniner (2014-08-18 15:23:56)
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Sorry I was thinking that it was say "state up" after that, I was looking in the wrong place... It's been a long time since I was playing around with this. So it is as i thought it was before?
[aaron@arch-box Arch-Linux]$ sudo systemctl start dhcpcd@enp0s25.service
[sudo] password for aaron:
Job for dhcpcd@enp0s25.service failed. See 'systemctl status dhcpcd@enp0s25.service' and 'journalctl -xn' for details.
[aaron@arch-box Arch-Linux]$ systemctl status -l dhcpcd@enp0s25.service
● dhcpcd@enp0s25.service - dhcpcd on enp0s25
Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; disabled)
Active: failed (Result: exit-code) since Mon 2014-08-18 11:20:29 EDT; 4min 11s ago
Process: 17650 ExecStart=/usr/bin/dhcpcd -q -w %I (code=exited, status=1/FAILURE)
Aug 18 11:19:59 arch-box dhcpcd[17650]: version 6.4.3 starting
Aug 18 11:19:59 arch-box dhcpcd[17650]: enp0s25: adding address fe80::ae3:ee04:7099:77c5
Aug 18 11:19:59 arch-box systemd[1]: Starting dhcpcd on enp0s25...
Aug 18 11:19:59 arch-box dhcpcd[17650]: enp0s25: waiting for carrier
Aug 18 11:20:29 arch-box systemd[1]: dhcpcd@enp0s25.service: control process exited, code=exited status=1
Aug 18 11:20:29 arch-box systemd[1]: Failed to start dhcpcd on enp0s25.
Aug 18 11:20:29 arch-box systemd[1]: Unit dhcpcd@enp0s25.service entered failed state.Last edited by mvheart/dev/null (2014-08-18 15:50:10)
Offline
mvheart, from everything I can see, it looks like your system is working fine. I just checked my own suspicion: the led lights on the NIC depend on an active connection to the router/modem/etc. Have you tested this computer on other networks, or other computers on that same network connection (even same cable)? If that's not practical, you could perhaps try different ethernet cables, as a bad cable would explain all these symptoms. In fact a gradually wearing down cable might be the best explanation for the gradual/sporadic onset leading up to the current complete absence of an active connection.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline