Update to r8168 (8.048.03-14) breaks ethernet

Earlier today there was an update to r8168 (a kernel module for Realtek 8168 network cards). After updating and rebooting, the driver for the ethernet controller was missing and, consequently, I could not connect to the internet.

I restored a Timeshift snapshot to get the internet connection back, so that I could explore other options. I considered installing r8168-dkms from the AUR, but then I noticed that there was also an update to the kernels, so I just updated again and rebooted. Everything is working fine now, there was no need to install any drivers from the AUR.

The issue, as far as it seems to me, is that the update to r8168 was pushed several hours before the update to the kernel. But once you lose the internet connection, you can’t update the kernel. That seems a bit silly, why would the package maintainers do that?

Lesson: use Timeshift.


Indeed. The three pillars of computer use are:

  1. Backup
  2. Backup
  3. Backup
1 Like

and #4: BACKUP!

1 Like

This seems weird - how did they build the module without the newer kernel version?

Could this have been caused by an out-of-sync mirror?


5 ringo does never backup :crazy_face:

didn’t notice those issue anyway, personal prever a usb with iso installed :slight_smile: i fix while chrooting :slight_smile:

1 Like

I wondered what that weird numbered package was when I did ‘checkupdates’.

Good thing I am not yet planning on updating. New to EOS, I need to figure out when a good update time is. Weekly? Monthly? Time will tell.

This does gives me a reminder to setup timeshift.

1 Like

in timeshift there is also in aur timeshift-autosnap using with pacman…

sometimes is fast good but some weeks no problem when not got the time…

As long as you do the kernel update with the update to r8168, there shouldn’t be an issue. The issue is if you update r8168 without updating the kernel and then reboot.


What’s that beeping noise with flashing lights?

1 Like

Yes, I find if very odd that there would be an update to r8168 and not to the kernel. Yet, in my case, the kernel update came some 2 hours after the r8168 update. It’s certainly not a conscious decision, because that would be just plain stupid.

I don’t think it’s related to this: