Slackware 15 — 5
On the office computer the ethtool command does not display network controller information unless network services are running or the device link explicitly initiated. I discovered this quirk in 2021 when I tested the Slackware 15.0 development branch.
The command no longer provided controller information in runlevel 1. Not a show stopper but irritating. Functional software that stops working as expected is a regression and irritating.
I suspected the problem happened only with Realtek controllers because I did not observe this behavior on other systems with different controllers.
Investigating this little quirk took me deep into the proverbial rabbit hole.
I started testing by installing ethtool version 4.5 in my 15.0 test partition. This version functioned as expected in runlevel 1 in Slackware 14.2. The command failed just like the newer 5.16 version provided in 15.0. The resulting error message was straightforward but did not identify the root cause:
Settings for eth0:
Cannot get device settings: No such device
The network controller was not initializing.
I installed ethtool 5.16 in Slackware 14.2. The command functioned normally in runlevel 1.
The problem was not the ethtool package.
Next I installed kernels that were introduced into the Slackware Current development branch about the time I tested in 2021. That changed nothing. Using a basic “bisect” approach I continued working my way through older kernels. Eventually I found with kernel release 4.9.67 both ethtool versions functioned as expected in runlevel 1.
Eventually I found the ethtool breakage occurred during the Slackware Current development period between kernels 4.14.x and 4.19.x. I did not look deeply but during that transition the method of detecting the physical layer of network controllers was changed. With the new method there were new kernel modules being loaded such as libphy and mdio_devres.
I began trying to discover a root cause for the ethtool failure in runlevel 1.
I got lucky. At the end of a Gentoo forum discussion was a comment that the user should not use the r8169 driver but should use the r8168 driver. I found a similar comment in a different forum.
What r8168 driver? There is no such devil in the kernel module tree.
I found the module online. The code was released many years ago, long before the relatively recent kernel changes. Why would I want to use such an old driver when the r8169 driver is functioning just fine except for this oddball quirk in runlevel 1?
Yet the online discussions were clear that some people with the RTL8111/8168/8411 chip should use the r8168 driver. This was the chip in my office system.
I browsed the Slackware forum for any discussion about r8168. I found a few references. This mysterious driver should be used but seems nobody spread the word. A well kept secret of sorts. The forum search revealed a slackbuilds.org package. I downloaded the files and in my 15.0 virtual machine built the package for the respective 15.0 kernel.
I opened a chroot environment to the office system testing partition and installed the new package. I rebooted to the testing partition and runlevel 1.
The ethtool command functioned as expected.
Of course, each time the kernel is patched and updated I have to remember to rebuild the r8168 package.
Regressions. This is why we cannot have nice things. I really hate that chicken updating computers.
Posted: Category: Usability Tagged: Slackware
Next: Slackware 15 — 6
Previous: Slackware 15 — 4