Greetings to the Manjaro community!
I recently did a fresh install of KDE Manjaro (switching from Gnome).
This is a desktop build, I have been using KDE manjaro for a week now.
Well, everything was running smoothly (with some minor hiccups I was able to fix) up until today.
I tried booting on Manjaro and I noticed that the Ethernet adapter does not want to work.
It was working until yesterday, and to be honest I don’t remember upgrading anything yesterday.
When I log into the system the ethernet connection tries to load and gives me the
“ip configuration was unavailable” error.
Internet works fine on other OSs and on my laptop, so it doesn’t have anything to do with the connection.
My inxi -Nazy output is:
Device-1: Intel Ethernet I217-V vendor: ASUSTeK driver: e1000e v: 3.2.6-k
port: f020 bus ID: 00:19.0 chip ID: 8086:153b
Device-2: TP-Link UE300 10/100/1000 LAN (ethernet mode) [Realtek RTL8153]
type: USB driver: r8152 bus ID: 4-5:2 chip ID: 2357:0601 serial:
The second device is a usb to ethernet dongle that I currently use to access the internet.
I am terrible at solving network related issues.
I’ve tried enabling dhcpcd.service to no avail.
I do hope it’s an easy fix.
What is your used kernel version?
Have you tried other kernels?
What is the output of
sudo dmesg -l emerg,alert,crit,err,warn when yoiu try to use the intel ethernet adapter?
I forgot to mention that the problem appeared without me explicitly changing kernels.
I use the default kernel that came with my release.
Or at least I think I do.
Manjaro 20.2 ships with 5.8 if I am not mistaken.
Perhaps it ships with 5.7 and it automatically changed the kernel version through updating?
I will try 5.7 and get back to you.
I also tried the 5.9.8-2 kernel (trying to troubleshoot).
The ethernet adapter did not work there (not recognized at all).
sudo dmesg -l emerg,alert,crit,err,warn
[ 0.117203] x86/cpu: VMX (outside TXT) disabled by BIOS
[ 0.127004] MDS CPU bug present and SMT on, data leak possible. See MDS - Microarchitectural Data Sampling — The Linux Kernel documentation for more details.
[ 0.127044] #5 #6 #7
[ 0.131099] ENERGY_PERF_BIAS: Set to ‘normal’, was ‘performance’
[ 1.853612] ata4: failed to resume link (SControl 0)
[ 2.013615] ata2.01: failed to resume link (SControl 0)
[ 2.172800] ata2.00: supports DRM functions and may not be fully accessible
[ 2.177776] ata2.00: supports DRM functions and may not be fully accessible
[ 3.177585] nvidia: loading out-of-tree module taints kernel.
[ 3.177591] nvidia: module license ‘NVIDIA’ taints kernel.
[ 3.177592] Disabling lock debugging due to kernel taint
[ 3.432411] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 455.45.01 Thu Nov 5 23:03:56 UTC 2020
[ 3.527256] ACPI Warning: SystemIO range 0x0000000000001828-0x000000000000182F conflicts with OpRegion 0x0000000000001800-0x000000000000187F (\PMIO) (20200528/utaddress-204)
[ 3.527264] ACPI Warning: SystemIO range 0x0000000000001C40-0x0000000000001C4F conflicts with OpRegion 0x0000000000001C00-0x0000000000001FFF (\GPR) (20200528/utaddress-204)
[ 3.527268] ACPI Warning: SystemIO range 0x0000000000001C30-0x0000000000001C3F conflicts with OpRegion 0x0000000000001C00-0x0000000000001C3F (\GPRL) (20200528/utaddress-204)
[ 3.527270] ACPI Warning: SystemIO range 0x0000000000001C30-0x0000000000001C3F conflicts with OpRegion 0x0000000000001C00-0x0000000000001FFF (\GPR) (20200528/utaddress-204)
[ 3.527273] ACPI Warning: SystemIO range 0x0000000000001C00-0x0000000000001C2F conflicts with OpRegion 0x0000000000001C00-0x0000000000001C3F (\GPRL) (20200528/utaddress-204)
[ 3.527275] ACPI Warning: SystemIO range 0x0000000000001C00-0x0000000000001C2F conflicts with OpRegion 0x0000000000001C00-0x0000000000001FFF (\GPR) (20200528/utaddress-204)
[ 3.527278] lpc_ich: Resource conflict(s) found affecting gpio_ich
[ 3.810035] at24 0-0050: supply vcc not found, using dummy regulator
[ 3.810611] at24 0-0051: supply vcc not found, using dummy regulator
[ 3.811203] at24 0-0052: supply vcc not found, using dummy regulator
[ 3.811749] at24 0-0053: supply vcc not found, using dummy regulator
[ 5.140299] usb 2-14: device descriptor read/64, error -71
[ 5.182330] kauditd_printk_skb: 22 callbacks suppressed
[ 6.518412] ata1.01: failed to enable DIPM, Emask 0x100
[ 6.699610] resource sanity check: requesting [mem 0x000e0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000e0000-0x000e3fff window]
[ 6.699768] caller _nv032125rm+0x2d/0x60 [nvidia] mapping multiple BARs
[ 6.911825] resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000d0000-0x000d3fff window]
[ 6.911958] caller _nv000709rm+0x1af/0x200 [nvidia] mapping multiple BARs
[ 7.419510] ata1.01: failed to enable DIPM, Emask 0x100
[ 7.419511] ata1.00: disabling LPM on the link
[ 7.419513] ata1.01: limiting speed to UDMA/133:PIO3
[ 10.673795] kauditd_printk_skb: 19 callbacks suppressed
[ 609.169380] NOHZ: local_softirq_pending 08
Ethernet adapter seems to work well on 5.7.19-2 kernel
I am using the ethernet connection to post this.
I guess the system automatically switched to the 5.8 kernel and something is wrong with the ethernet configuration there.
As I mentioned above, I did not explicitly switch kernels.
Maybe I did not pay enough attention to the update process?
Can Manjaro change the default kernel automatically?
Perhaps I logged into 5.8 by accident (for example, through GRUB).
For all intents and purposes, my current problem is solved.
However, if I want to change kernels I will probably face some problems.
You should mind that 5.7 is not a LTS Kernel and as such will stop receiving support in a while. So you should test with the 5.4 LTS Kernel. In any case it is always recommended to have 2 Kernels installed to be able to switch, if problems arise.
Shouldn’t I be headed more towards 5.8 then?
UPDATE #2 - Ethernet broken again.
Network adapter worked fine on first 5.7 kernel boot.
However on next boot it also exhibited the same problem:
“ip configuration was unavailable”
It was probably fixed by something random I guess.
UPDATE #3 - Ethernet still broken
I also tried kernel 5.4, to no avail.
I am getting consistent behavior on all kernels, so it is not a kernel thing.
I forgot to mention that this is a dualboot system (Manjaro KDE - Windows 10).
As I was searching for solutions online, I found a thread that mentioned that Windows may be hijacking the Ethernet interface via its “Fast boot” option that essentially never fully shuts the system down.
I am familiar with how Windows may “lock” hard drives via this option (and not letting Linux mount said drives), however I never thought that this would also interfere with the Ethernet adapter.
Moreover, I’ve never experienced this issue before and this is not the first time I am dual booting.
Anyway, I went into Windows and disabled fast boot (even though Ethernet worked properly for a full week before it stopped working - with Windows fast boot on that is - ), just to check.
I fully shut down Windows and booted into Manjaro.
And the ethernet adapter worked!
But guess what?
On next boot it still doesn’t work.
It is kinda frustrating, ain’t it?
Same ethernet behavior occurs even on live USB!
Tested on the very same Live USB image I used to install the system!
Ethernet also does not work on other live USBs!!
I have the exact same problem with the exact Intel Ethernet I2170-V e1000e
- Fresh install of Manjaro
- Reboot in Manjaro, ethernet works
- Reboot in Windows, ethernet works
- Reboot in Manjaro, ethernet does not work (and live usb does not work either).
I tried several things:
- dhcpcd but it tells me that dhcp4 times out
- disconnect / reconnect cable
- flush all devices on my router
- disabled fast boot / csm / secure boot on my ROG
- disabled fast boot on Windows
Interestingly, I waited a day and then it worked again.
But everytime I go to Windows and then Manjaro it doesn’t work.
SSD1: efi / windows
SSD2: efi / swap / manjaro
EDIT: tried kernel 5.4 and 5.8
Windows is more than likely the culprit here.
I cannot imagine a sensible reason why ethernet would not work even on live USBs.
Probably some recent update messed something up?
However I don’t recall updating Windows around that time (I could be wrong, though).
Now that you mention it, the ethernet adapter on my system always breaks after I’ve logged into Windows.
I use both OSs on a daily basis and when I manage to fix linux (by pure chance), the next time I log in (which will more than likely be after also booting on Windows) the ethernet is broken again.
As you can see by this thread, I’ve been facing this problem for 3-4 days now.
When it works it is purely random.
Which router model is it exactly?
Could you both run a test regimen to establish the source of the problem by exclusion?
Do each of those steps alone and see if anything changes.
- Turn of the PC and leave it turned off for 5 minutes. Then turn on again.
- Do the same with the router.
- Hard configure the IP addresses in the router and the devices.
This is for sure a very curious behaviour you both are describing here.
I will try all these steps and get back to you.
For once, I can safely guarantee you that step 1 does not work; I turn the PC off every night and power it on the next afternoon (when I get back home from work). Thus it remains powered off for like 16-17 hours.
I will give a shot at restarting the router and configuring the IP manually (I’m gonna be pretty rusty on the latter, it’s been a while since I had to manually set up and internet connection).
Have you turned off both “fast startup” in Windows, and “fast boot” in BIOS?
I did not turn “fast boot” off in BIOS and, to be honest, I don’t even know if it is on or off right now.
What I do know though is that I certainly did not change anything in BIOS when the problem appeared.
I can attest to this.
- Working ethernet on linux
- Reboot into linux again --> Ethernet stays fine
- Reboot into Windows --> Ethernet always works there
- Reboot into Manjaro --> Ethernet broken
So, the problem appears after logging into Windows.
Yesterday evening around 2 a.m. we had a minor power outage here in the neighborhood.
Not too long, probably was around 5 minutes.
I was finishing some stuff when the power went out.
So I figured I’d call it a day.
This afternoon when I came back from work and logged into linux, guess what happened?
Ethernet was working fine.
This means that the power outage was someway/somehow able to “reset” the whole issue.
So I used this opportunity to work on linux, reinstall some stuff etc etc.
I rebooted many times from linux to linux, not a single problem.
As soon as I booted into Windows (for like 20 seconds) and rebooted into linux, ethernet broke again.
I fully shut down the PC, waited for like 5 minutes and then logged into linux again.
Ethernet still broken.
Fully shut down the PC and the router, opened them up and then logged into linux.
Ethernet still broken.
The only thing I did not try thus far (in hopes of “mimicking” the power outage) is switching off the PSU and taking the power cable off.
I’ve tried all the steps that @Takei suggested.
Didn’t work either.
@pobrn I have disabled fast boot and fast startup both in bios and windows.
I have a Linksys EA8500. It is known to have some wifi issues with firmware 1.1.9 so I downgraded to 1.1.8 but still no luck.
Maybe it’s a cable problem as suggested in another post (Ethernet connection to router fails to set network address)
I’ll try to shutdown the PSU and see what happens.
I’ve switched off the PSU and waited.
Turned back on and it worked!
Not sure what Windows is doing then…
Read through that thread and tried replacing the ethernet cable.
I have 3 different ethernet cables, which all work on Windows.
Tested all 3, the connection problem was not fixed.
I also tried different router ports, with similar results.
The only thing that “works” reliably thus far is shutting off the PSU.
The problem persists, I haven’t been able to figure out what’s wrong.
The only way I am able to get ethernet to work on Linux is by shutting off the PSU for a couple minutes after I have logged into Windows.
This way, I am able to get normal ethernet connection on Linux.
It’s kinda annoying, but at least it is something simple that does the trick.
Would love to find out what’s causing the problem though.