Can't get Realtek RTL8852AE wireless network adapter set up

[sylphyk]

Hello everyone, this is my first post here.

I'm a good amount of the way through my Gentoo installation. I chose to go with the musl stage 3 archive. I used systemrescuecd for the installation, and shortly after some installing the kernel and some minor kernel configuration, I discovered this system was bootable as the GRUB bootloader on the live CD I used had the ability to search for a Linux installation and boot into it.
I don't have users set up yet, and I don't have grub installed yet, if that's any indication of where I'm at in the installation process. I had just set up root password before I found out I could boot into the installation.

I've done most of everything I need the graphical environment for, and Ethernet works just fine in my booted Gentoo installation, I'm just stuck with setting up WiFi.

Here are some command outputs and settings. Apologies, I am leaving out some potentially irrelevant information (denoted by an ellipsis) as I'm typing this up with my phone, including command outputs.

Code: Select all

# lspci | grep RTL8852
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852AE 802.11ax PCIe Wireless Network Adapter

Clearly, the system recognizes the device.

Code: Select all

# ifconfig -a
eno1: flags=4099<UP, BROADCAST,MULTICAST> mtu 1500 ether...
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1...

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536... link/loopback...
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500... link/ether...

So where is the device? Let's try to turn it on.

Code: Select all

# ifconfig wlan0 up
wlan0: ERROR while getting interface flags: No such device

Where is it?


According to a few different sources on forums found in Google searching, this driver module should be present in the current kernel version.
I decided to attempt to install the rtw89 drivers from lfinger's GitHub, but it failed to compile. I no longer have the output, but essentially it couldn't find /lib/modules/6.6.14-1-lts/
That's because the directory 6.6.14-1-lts does not exist in /lib/modules/. What I do have there is this:

Code: Select all

# ls/lib/modules
6.6.21-gentoo-dist-hardened

Ok, I peek into the makefile and at the very top of the file I see this:

Code: Select all

SHELL := /bin/bash
KVER ?= $(shell uname -r)
...

Sweet! So I just comment out the line where KVER is defined and I add my own line:

Code: Select all

SHELL := /bin/bash
#KVER ?= $(shell uname -r)
KVER ?= 6.6.21-gentoo-dist-hardened

I run make and make install, voila! No errors.

Modprobe check according to the GitHub's readme:

Code: Select all

# modprobe rtw89.
modprobe: FATAL: Module rtw89 not found in directory /lib/modules/6.6.14-1-lts

So it's clear to me that the system reports a kernel version that is different from the kernel I have installed. Why is this? I decide to ignore it for now and attempt to work around it as Modprobe tends to get it wrong.
I try a few different module names: rtw89, rtw_8852ae, rtw89core, rtw89_pci, rtw89pci, just trying to find some semblance of things working semi-correctly. None of these modules are found, and modprobe returns the same error each time.

I try this:

Code: Select all

# modprobe --set-version 6.6.21-gentoo-dist-hardened rtw89
modprobe: FATAL: Module rtw89 no found in directory /lib/modules/6.6.21-gentoo-dist-hardened

I retry a few times with the same module name combinations that I previously mentioned, all fail with the same error.

Ok, at this point I decide to walk through the driver GitHub's readme and find there's a workaround for Lenovo and HP laptop bios not handling PCIE properly. I have a Lenovo laptop. link to the readme
I make an attempt:

Code: Select all

# cp 70-rtw89.conf /etc/modprobe.d/
cp: cannot create regular file '/etc/modprobe.d/': Not a directory

What?
Just to make sure I'm not going crazy:

Code: Select all

# ls -al /etc | grep modprobe

No output. modprobe.d indeed does not exist.

At this point I find on what I deem to be the last remaining forum post on the Internet that I haven't yet seen about setting up this chip/driver, that again confirms that this wireless chip should have drivers supported by default in the latest kernel, and it tells me where in the menuconfig I can find it. This is how it is setup by default:

Code: Select all

Device Drivers --->
    -*- Network device support
        [*] Wireless LAN --->
            [*] Realtek devices
                <M> Realtek 802.11ax wireless chips support --->
                    <M> Realtek 8851BE PCI wireless network (Wi-Fi 6) adapter
                    <M> Realtek 8852AE ...
                    <M> Realtek 8852BE ...
                    <M> Realtek 8852CE ... (Wifi 6E) adapter
                    [ ] Realtek rtw89 debug message support
                    [ ] Realtek rtw89 debugfs support

I make no changes. It all seems to be good on this end. One thing of note is that the forum page wanted everything set to built in rather than as a module. I can set any of these items to either unsupported (empty brackets) or as their default value shown above. I cannot set them to anything different. Now, I'm not sure if installing the drivers off GitHub affected this, I didn't know where to check in the kernel config before this point.

I've been trying to get this figured out all day now and I just don't know what's going on anymore, I'm seeing a lot of strange behavior and can't figure out where I misstepped.

Some side notes:
Windows wifi continues to work. SystemRescueCD wifi works out of the box, it automatically gets the chip running and I just choose a network in the GUI, and it has no trouble at all. Not a hardware issue.
Somewhere in this process I accidentally rm -rf'ed the folder for my kernel in /lib/modules/. This was dumb, and I have no explanation for why i did this. I reinstalled the kernel and it came back.
After installing lwfinger's rtw89 drivers, I redid all of the same checks outlined previously and continued to get the same errors.
There were numerous reboots in between steps and not just where I deemed it necessary. Despite continuing to piggyback off of the SystemRescueCD's GRUB, it boots so damn fast and logging in is a non-issue, my eyes' need to blink is the only bottleneck.
I've been attempting to fix this with what I already know, my natural problem solving ability, and a few new things I learned from my scouring of the Internet for a solution. I would appreciate some help, and any ideas for what else I could check. This HAS to be possible.

Yes, I could continue working in my Live CD, but that just means I have to worry about this later. Since this is bootable, I want to continue working in this environment.

[grknight]

Code: Select all

# lspci | grep RTL8852
04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852AE 802.11ax PCIe Wireless Network Adapter

Clearly, the system recognizes the device.

This is not entirely true. lspci bypasses the kernel support and just looks for devices that are registered on the bus and finds them in a local database. It does not mean it will work (yet).

So it's clear to me that the system reports a kernel version that is different from the kernel I have installed. Why is this? I decide to ignore it for now and attempt to work around it as Modprobe tends to get it wrong.

Here your thinking is "off the rails." modprobe always does the right thing for the running kernel.
You are booted into a LiveCD. It will disregard what you have built until you are running it which is the correct thing to do. Kernel modules between versions are incompatible by definition.

The github driver is not necessary though the modprobe.d option file may be. Another hint is that directories do not have to exist until something needs them. Just mkdir if it is needed.
So long as CONFIG_RTW89=m and CONFIG_RTW89_8852AE are enabled in the kernel config and the linux-firmware package is installed, then, on reboot to the built kernel the wireless should be visible and able to be configured.

The command uname -r will always show what kernel is running.

[sylphyk]

Sorry, I should clarify, everything happening here is going on in my Gentoo environment. I do not boot into SystemRescueCD.

And my understanding of lspci is that it checks what hardware is seen, not necessarily what is working or has drivers installed. That's what I meant by "recognizes", I think we're on the same page about that.

Another clarification, modprobe doesn't have a "tendency" to be incorrect, but I've heard accounts that it wasn't correct about it before. My wording was bad.

I just found it interesting that modprobe was incorrect as well. I neglected to run uname -r as the makefile I talked about appeared to be calling it. But yes, upon running the command now, it shows the same 6.6.14-1-lts.

As stated, the kernel options for the drivers are enabled and it persists across reboots.

Perhaps I (the human) am incorrect about kernel versions. But then why didn't the make command for the GitHub drivers work, initially? Why does modprobe look in a directory that doesn't exist, and should theoretically contain the modules it probes for?

I'm no professional sysadmin, but I like to think my understanding of Linux is more on the advanced side. But maybe I'm not understanding something here.[/quote]

[grknight]

I just found it interesting that modprobe was incorrect as well. I neglected to run uname -r as the makefile I talked about appeared to be calling it. But yes, upon running the command now, it shows the same 6.6.14-1-lts.

If this is the case, then you still haven't booted into the Gentoo environment with its kernel you built during install. uname will match what you installed once you have. Without some extra configuration from a user, no kernel will end in -lts in Gentoo.

[pietinger]

sylphyk,

first of all: Welcome to Gentoo Forums !

Let me suggest using a 6.7 or 6.8 kernel because rtw89 is already included:

Code: Select all

Device Drivers  --->
    [*] Network device support  --->
        [*]   Wireless LAN  --->
            [*]   Realtek devices
            [*]     Realtek 802.11ax wireless chips support  --->

To get this options you will need =>

Code: Select all

Depends on: NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_REALTEK [=y] && MAC80211 [=y]

If you need help with manually configuring the kernel you might start here:
https://wiki.gentoo.org/wiki/User:Pieti ... figuration

(Take a look also here: https://wiki.gentoo.org/wiki/User:Pietinger to see 6.7 and 6.8 )


P.S.: Also use lspci -nnk to get the information if a module is loaded. See more:
https://wiki.gentoo.org/wiki/User:Pieti ... lspci_-nnk

[sylphyk]

I just found it interesting that modprobe was incorrect as well. I neglected to run uname -r as the makefile I talked about appeared to be calling it. But yes, upon running the command now, it shows the same 6.6.14-1-lts.

If this is the case, then you still haven't booted into the Gentoo environment with its kernel you built during install. uname will match what you installed once you have. Without some extra configuration from a user, no kernel will end in -lts in Gentoo.

I am very certain I am in the Gentoo environment, unless it somehow boots into SystemRescueCD and then chroots and unmounts itself without my knowledge.

Let me suggest using a 6.7 or 6.8 kernel because rtw89 is already included

According to many different sources, rtw89 should be present in this kernel version as well. But it might only be showing up in my config tree because I installed the ones from GitHub, I had neglected to check beforehand. I will update to a later kernel and see what happens.

I just don't understand why there's a difference in what uname -r says and that folder in /lib/modules/.
6.6.14-1-lts vs 6.6.21-gentoo-dist-hardened.

Is /lib/modules/6.6.21-gentoo-dist-hardened not associated with the kernel?
Where is the folder for 6.6.14-1-lts that a lot of different software seems to look for? I understand they get it from uname -r but why doesn't that folder exist if it's so necessary? I question this because even modprobe, a built in program, looks for the folder and it doesn't exist. Seems to me it should be there and should potentially have files in it.

[pietinger]

6.6.21-gentoo-dist-hardened is a preconfigured gentoo-distribution-kernel [1] and is not suitable for a manual kernel configuration (it is possible; but no fun).
Gentoo-sources [2] is more suitable for manual kernel configuration.

6.6.14-1-lts is not a kernel provided by gentoo; this kernel was not installed with an "emerge" from gentoo.

1) This is the first option in our Handbook: https://wiki.gentoo.org/wiki/Handbook:A ... on_kernels
2) https://wiki.gentoo.org/wiki/User:Pieti ... el_version +
https://wiki.gentoo.org/wiki/Handbook:A ... figuration +
https://wiki.gentoo.org/wiki/Handbook:A ... el_sources

[grknight]

I just found it interesting that modprobe was incorrect as well. I neglected to run uname -r as the makefile I talked about appeared to be calling it. But yes, upon running the command now, it shows the same 6.6.14-1-lts.

If this is the case, then you still haven't booted into the Gentoo environment with its kernel you built during install. uname will match what you installed once you have. Without some extra configuration from a user, no kernel will end in -lts in Gentoo.

I am very certain I am in the Gentoo environment, unless it somehow boots into SystemRescueCD and then chroots and unmounts itself without my knowledge.

Again, this is incorrect. You are not. You are still booting the Live environment or at least the Live kernel.

[sylphyk]

If this is the case, then you still haven't booted into the Gentoo environment with its kernel you built during install. uname will match what you installed once you have. Without some extra configuration from a user, no kernel will end in -lts in Gentoo.

I am very certain I am in the Gentoo environment, unless it somehow boots into SystemRescueCD and then chroots and unmounts itself without my knowledge.

Again, this is incorrect. You are not. You are still booting the Live environment or at least the Live kernel.

Running uname -r in the Live environment shows 6.6.14-1-lts.
I don't understand why this happens, but it appears you are correct.
What is the purpose of booting into another Linux installation (this is what the option on boot SAYS] if it's not really booting into that environment/kernel? Is there something that selects the kernel on a completely different device from what I decide to boot?
If I wanted to do that, I would continue with chrooting from the LiveCD.
Please pardon my frustration, which I think is becoming obvious now, I don't intend to direct it towards you.

I am currently manually configuring kernel version 6.8.1. I will then install Grub and attempt to boot and will update when I get there.

[pietinger]

Unfortunately, I don't understand your problem, but let me give you two links:

https://wiki.gentoo.org/wiki/User:Pieti ... _at_Gentoo

I would like to emphasize this recommendation in particular:

Secondly, even if you want to use a manually configured kernel, you should first install the precompiled kernel image sys-kernel/gentoo-kernel-bin because you can then select it at any time via the boot manager and thus have a backup kernel when your manually configured kernel causes problems.

I have also described how to chroot into a gentoo system in chapter "Pause during Installation".

This is the very latest recommendation for a quick installation (with OpenRC):
https://wiki.gentoo.org/wiki/User:Pieti ... EFI_System

[Hu]

Running uname -r in the Live environment shows 6.6.14-1-lts.
I don't understand why this happens, but it appears you are correct.
What is the purpose of booting into another Linux installation (this is what the option on boot SAYS] if it's not really booting into that environment/kernel?

As you describe it, that does sound misleading. However, this is controlled by whoever created the boot media for you, which appears to mean your question is about the SystemRescueCD environment, not about Gentoo. We might have someone here who is familiar with it and can address your question. We might not. In the hope that we do, or that we have someone willing to do some research for you, could you share precise instructions on where and how to obtain the media that is offering you this seemingly misleading option? In particular, there have been multiple releases of SystemRescueCD over the years, and we would need to use the same version as you in order to get the best analysis.

[sylphyk]

Running uname -r in the Live environment shows 6.6.14-1-lts.
I don't understand why this happens, but it appears you are correct.
What is the purpose of booting into another Linux installation (this is what the option on boot SAYS] if it's not really booting into that environment/kernel?

As you describe it, that does sound misleading. However, this is controlled by whoever created the boot media for you, which appears to mean your question is about the SystemRescueCD environment, not about Gentoo. We might have someone here who is familiar with it and can address your question. We might not. In the hope that we do, or that we have someone willing to do some research for you, could you share precise instructions on where and how to obtain the media that is offering you this seemingly misleading option? In particular, there have been multiple releases of SystemRescueCD over the years, and we would need to use the same version as you in order to get the best analysis.

I had just downloaded the latest iso available on the official SystemRescueCD website and flashed it to an ancient USB flash drive I had laying around using Rufus on my Windows installation. I had previously been working in VMs (but not on Gentoo, this is my first Gentoo setup) and I got tired of that setup.

The Gentoo installation is on a completely different physical media (an SD card).

I just don't understand how it pulled the kernel off the SRCD flash drive and ran the Gentoo environment on the SD card. I know it did because SRCD displays a short quick-start guide upon logging in, explaining how to run startx etc. Upon booting into what was presumably the Gentoo environment, i was not met with this, and the screen resolution was much lower (SRCD would automatically change resolution) and I was also met with my configured hostname.

My question was not about SRCD but rather getting my wifi drivers working with Gentoo, but it appeared to be running off a different kernel (this is where it gets more confusing for me) from what I thought i installed.
Evidently, this kernel in use was the kernel my SRCD installation uses.
But wifi drivers were working in the SRCD environment...

So I'm manually installing a later version of the kernel, which I might not have needed to do, but I'd prefer it this way anyways. I had initially decided to go with a dist kernel for the sake of simplicity, intending to build my own kernel later once I had a working system. I've learned so much in the past 24h. I'm almost done, just need to finish setting up sound card and a few other things. I've got a few other projects going on around the house so I'm kind of jumping back and forth but I should be able to start compiling today. I'll disconnect SRCD media once I've got a bootloader installed and will attempt to boot and see how it goes. I'll need to

[sylphyk]

Ok, I've got it all working now.

So it's clear that when I started this thread, there were a lot of other issues I needed to solve/understand, and that required me to manually configure a kernel.

Big shoutout to Pietinger for the excellent tutorials on kernel configuration. It was a lot of work but I got it all figured out.
The answer to my specific issue, barring the confusion about kernel versions and all of my trial and error getting this truly bootable, is solved right here in one of those tutorials. By the way, I admire the brutal lack of handholding. You were specific enough to show how it needs to work and ambiguous enough to let me figure it out for my specific system.[/url]

After getting my system bootable and navigating a kernel panic by just recompiling, I ran dmesg | grep -iF "direct firmware" and used the result (mine showed a .bin file specific to my hardware) as parameter for the direct firmware loading kernel option displayed in the tutorial.
I then made a quick config file for wpa_supplicant (I had installed it much earlier in this whole endeavor) for my wifi network and got connected. Everything is running swell, now I can get to work building the perfect Gentoo.

Thanks for the help!

[pietinger]

Ok, I've got it all working now. [...] Everything is running swell, now I can get to work building the perfect Gentoo.

Happy to hear that ! ...

Big shoutout to Pietinger for the excellent tutorials on kernel configuration. [...]

... and thank you too for your feedback and this compliment !

By the way, I admire the brutal lack of handholding. You were specific enough to show how it needs to work and ambiguous enough to let me figure it out for my specific system. [...]

Our forums legend NeddySeagoon would answer you:

"Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

I try to teach fishing without letting any students drown."

Thanks for the help!

You are very Welcome !

Have fun with Gentoo !