When I Tried to Install RTL8188 Wi-Fi Driver for Linux

When I Tried to Install RTL8188 Wi-Fi Driver for Linux

In this text I will talk about my experiment with Linux drivers and kernel. First of all, if you’ve ever used Linux before, it’s very unlikely that you’ve ever faced with a driver problem like you do with Windows. That’s because Linux has all the drivers for different hardware packaged all together. However, the problem arises when we use a more specific hardware. What specific hardware you might ask, right? Well, in my case it was a RTL8188 Wi-Fi adapter. That’s because the Wi-Fi I’m using is constantly failing and kicking us out of the network. So I thought about putting a Wi-Fi adapter in monitor mode and using WireShark to try to capture what’s wrong, even if it’s an attack on my innocent Wi-Fi. Now, Linux also supports the RTL8188 out of the box either. But the driver Linux has doesn’t support monitor mode or packet injection. So if we want to do that, we have to install aircrack’s version of this driver.

Back to the topic. Once I realized that I had to download the driver’s source from aircrack. They don’t have any prebuilt packages, or at least I couldn’t find any. To be honest, I didn’t look either. Building from source is something I’m used to. Of course, I’d prefer to have a prebuilt, since it’s much less time and resource consuming but still.

So I started the build process for the drivers for aircrack, and in fact that’s when the problem arose. That’s when I learned that kernel modules are specific to the kernel version of the Linux. You see, if you download a kernel module for Linux 6.5.x and you are using 6.6.x; chances are that most of the mechanisms (functions) in the Linux kernel will be changed. So the kernel module will not be able to find these functions on the new kernel. As the result, the build will fail, obviously. Fortunately, it will fail at build time, because we have to build from source, not from runtime.

In my case, the driver was supported by the Linux 6.5.x kernel. Since I’m using Fedora, it has a rolling release repository, so I had the latest Linux kernel at the time, 6.10.x. Fedora users get the latest and relatively stable packages and kernels as soon as they are released.

That’s why the build failed, saying it couldn’t find some of the functionality in the included OS headers. That’s quite normal and expected.

Since I don’t currently have the knowledge to fix the driver to run on a newer version of Linux, my only option is to install multiple kernels on my Fedora system. Installing multiple kernels on your Linux system is not a new concept. In fact, it’s a very rare thing to do. In my case, however, it was a necessity.

From now on, I may be wrong about some of the things I say. Because I’m not that familiar with installing kernels on a Linux system. If you search for a Linux kernel of a certain version on Fedora’s reporistry, you will only find the latest kernel. So Fedora doesn’t support installing specific kernel versions from it’s package manager. I wish they would. Anyway, after some Google searching, I found that there is a software called Koji that does this. I downloaded the precompiled kernel from the Fedora website and then used Koji to install it. The thing is, Koji doesn’t check if the kernel size fits into the boot partition. You see, the Linux kernel sits in a partition on the disk called boot. And because it doesn’t check to see if there’s enough room for the kernel, some of the parts of the kernel were missing. Koji also screwed up the EFI partition on the disk. It created a new GRUB entry for the new kernel. I mean, I already have an entry for Fedora. These things may have happened because I didn’t configure and tell Koji not to install a new GRUB, but to configure the one that already existed.

So after all that chaos on the system, what would you say what happened next? Well, it obviously it started not booting. UEFI decided to prioritize the new EFI entry created by Koji. All of the options on that GRUB were broken. I chose Fedora’s EFI entry, the one I had always used, over UEFI. But, that wasn’t a solution either. Something must have gone terribly wrong, because the other Linux kernels we hadn’t touched weren’t working either. I get to the recovery phase because the system won’t boot anymore. It needs some kernel-level troubleshooting.

I inserted a live image of Linux and chrooted in to the broken system. Even though I tried to remove the broken kernel on boot, remove the bad efi entry, it still wouldn’t boot. I suspect it’s a mismatch between kernel modules, so that’s the reason. I also ran dnf reinstall *kernel* to reinstall the latest Linux kernel. But no matter what I tried, I couldn’t fix it.

I ended up copying my data from the broken system to an external storage and reinstalling the whole system. I wish I knew what went wrong, but it takes a lot of time and effort, so I gave up. More importantly, it took more effort than reinstalling a new Linux and then installing all my everyday applications and even copying my files. So it wasn’t worth it.

So that’s the story of my 5 hour long Linux kernel journey. It started with trying to install a driver on Linux that turned into an unbootable system. Maybe one day I will try to install a certain kernel on a Fedora again. That will not happen for a while.

Comments are closed