Ethernet doesn't exist as an option

My ethernet does not seem to exist in my network manager after a most recent upgrade of my system on 11/14 with

pacman -Syyuu

on my manjaro laptop.

Anyone have any places for me to start to debug this? I'm not a networking aficionado.

I tried to downgrade my kernel and networkmanager both to last known working version but I still do not even get an ethernet option (wifi is working fine).

I don't know why you use such command to update your system.

Only use

sudo pacman -Syu

If you have change your mirrorlist - use

sudo pacman -Syyu

I use such command because it allows me to downgrade packages if necessary during system upgrade. The command you posted has given me issues in the past because it does not.

As mentioned you should only use "uu" if it is a situation that requires it.

You need to post your system details. Use USB Android phone tethering if you need a connection. Do not post an output as a pic.

inxi -Fxxxz

You would also be well advised to learn how to do backups.


If your using the 5.3 kernel, downgrade to a different series.
I'd suggest an LTS series like 4.19, less issues, and you don't have to worry about it going EOL on you anytime soon.



Yeah I downgraded to 4.19 and the issue seems to be resolved, although I would like to be able to use the newer kernel.

From a working kernel my ouput is:

  Host: sailfish Kernel: 4.19.84-1-MANJARO x86_64 bits: 64 compiler: gcc 
  v: 9.2.0 Desktop: Cinnamon 4.2.4 dm: LightDM 1.30.0 Distro: Manjaro Linux 
  Type: Laptop System: Dell product: Precision 5530 v: N/A serial: <filter> 
  Chassis: type: 10 serial: <filter> 
  Mobo: Dell model: 0FP2W2 v: A00 serial: <filter> UEFI: Dell v: 1.13.0 
  date: 08/22/2019 
  ID-1: BAT0 charge: 61.8 Wh condition: 87.7/97.0 Wh (90%) volts: 12.7/11.4 
  model: SMP DELL GPM0365 type: Li-ion serial: <filter> status: Charging 
  Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard K540/K545 
  serial: <filter> charge: 100% (should be ignored) rechargeable: yes 
  status: Discharging 
  Device-2: hidpp_battery_1 model: Logitech Wireless Mouse M510 
  serial: <filter> charge: 55% (should be ignored) rechargeable: yes 
  status: Discharging 
  Topology: 6-Core model: Intel Core i9-8950HK bits: 64 type: MT MCP 
  arch: Kaby Lake rev: A L2 cache: 12.0 MiB 
  flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx 
  bogomips: 69720 
  Speed: 888 MHz min/max: 800/4800 MHz Core speeds (MHz): 1: 853 2: 859 
  3: 860 4: 853 5: 872 6: 875 7: 854 8: 856 9: 844 10: 836 11: 839 12: 838 
  Device-1: Intel UHD Graphics 630 vendor: Dell driver: i915 v: kernel 
  bus ID: 00:02.0 chip ID: 8086:3e9b 
  Device-2: NVIDIA GP107GLM [Quadro P2000 Mobile] driver: N/A 
  bus ID: 01:00.0 chip ID: 10de:1cba 
  Display: x11 server: X.Org 1.20.5 driver: intel FAILED: nvidia 
  resolution: 2560x1440~60Hz, 2560x1440~60Hz 
  OpenGL: renderer: Mesa DRI Intel UHD Graphics 630 (Coffeelake 3x8 GT2) 
  v: 4.5 Mesa 19.2.4 compat-v: 3.0 direct render: Yes 
  Device-1: Intel Cannon Lake PCH cAVS vendor: Dell driver: snd_hda_intel 
  v: kernel bus ID: 00:1f.3 chip ID: 8086:a348 
  Device-2: Realtek type: USB driver: snd-usb-audio bus ID: 3-1.5:3 
  chip ID: 0bda:4014 serial: <filter> 
  Sound Server: ALSA v: k4.19.84-1-MANJARO 
  Device-1: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter 
  vendor: Dell driver: ath10k_pci v: kernel port: efa0 bus ID: 3b:00.0 
  chip ID: 168c:003e 
  IF: wlp59s0 state: up mac: <filter> 
  Device-2: Qualcomm Atheros type: USB driver: btusb bus ID: 1-4:3 
  chip ID: 0cf3:e010 
  Device-3: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152 
  bus ID: 4-1.2:3 chip ID: 0bda:8153 serial: <filter> 
  IF: ens4u1u2 state: up speed: 1000 Mbps duplex: full mac: <filter> 
  IF-ID-1: br-47ec8ff8ca91 state: down mac: <filter> 
  IF-ID-2: br-6d3648237fce state: down mac: <filter> 
  IF-ID-3: docker0 state: down mac: <filter> 
  Local Storage: total: 953.87 GiB used: 103.24 GiB (10.8%) 
  ID-1: /dev/nvme0n1 vendor: Toshiba model: KXG50ZNV1T02 NVMe 1024GB 
  size: 953.87 GiB speed: 31.6 Gb/s lanes: 4 serial: <filter> rev: AADA4106 
  scheme: GPT 
  ID-1: / size: 43.00 GiB used: 39.05 GiB (90.8%) fs: ext4 
  dev: /dev/nvme0n1p6 
  ID-2: /home size: 147.03 GiB used: 64.14 GiB (43.6%) fs: ext4 
  dev: /dev/nvme0n1p7 
  ID-3: swap-1 size: 1000.0 MiB used: 0 KiB (0.0%) fs: swap 
  dev: /dev/nvme0n1p5 
  System Temperatures: cpu: 72.0 C mobo: N/A 
  Fan Speeds (RPM): cpu: 2506 fan-2: 2499 
  Processes: 329 Uptime: 28m Memory: 31.04 GiB used: 3.07 GiB (9.9%) 
  Init: systemd v: 242 Compilers: gcc: 9.2.0 clang: 9.0.0 Shell: zsh 
  v: 5.7.1 running in: gnome-terminal inxi: 3.0.36 

I will get you the output from a non working kernel shortly.

1 Like

Normal "stable" releases usually introduce regressions, issue and bugs, then they go EOL and get removed from the repositories. LTS releases are usually pretty solid, have years of upstream support and security fixes, and unless you have new hardware that you need to be supported, is a better solution.
Don't get me started on the mainline kernels, talk about being used as a guinea pig. :wink:

I have an old media/file server here still running 4.4 because it has hardware that just isn't compatible with the newer kernels, 4.9 crashes at random and reboots, a lot, and 4.14 completely crashes on boot with a kernel dump.

1 Like

I totally agree this attitude stuns me. Especially coming from people using very old hardware. On my older computers I generally run 4.14 as I find that kernel has the least issues with some of the very old hardware I own.

The most funny thing is how some users get right ingignant and pissed at Manjaro if their system won't run properly on the latest kernel. Those cases kill me.

I will mark your suggestion to switch kernels as the solution.

1 Like

Yea, well If you go through the forum, there seems to be a reoccurring theme with the 5.3 kernel, and networking issues.

1 Like

You are quite right. Usually one of my first suggestions is to try a different kernel. I have even been ranted on for suggesting this so often. Some users think this is not a valid solution at all, Some simply think it is their God given right to be on the newest kernel and will not accept any answer that does not allow them to use the latest and greatest.

Laughable, man.


What about the endless stream of users that claim they have used Linux for twenty years ask for help and go in a endless loop of failing because they never listen to any advice given i call them attention seekers, and time wasters, Lol


or help vampire :vampire:


PS to @rubyi. These rants were not directed personally at you. It was simply venting, as some users have attitudes that tend to rub helpers on the forum the wrong way after a while.

No offense to you intended. Sorry if we came off that way.


No worries. I can totally see it from both sides. For me, I downgraded and that seemed to work fine. I know I need to use certain kernel versions because of some HDMI/display issues on older/certain kernels (I'm running pretty new ~2019 hardware). So, in that thought I could kind of understand wanting to use a newer kernel to fix certain problems where downgrading would fix the problem at hand but introduce others and thus not be a "solution" of fixing the problem on that specific kernel version.

That said, it is a fine workaround for my case as everything seems to be ok on 4.19.

1 Like

I do have new hardware that has display issues on certain kernel versions.

Yes, however that is kind of part of the reason why there are LTS kernels to begin with. Not only do they receive security fixes, but also other fixes, like driver (modules) getting backported for just the reasons you mentioned. Unless you need a proprietary driver that isn't compatible with one, or more of the LTS kernels, well then, in that case, blame Nvidia. :wink:


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by