Problem with Kernel 6.1.39

[Stanislav-Lapata]

Hi I got error when try to install drivers on NixOS

/build/source/os_dep/linux/wifi_regd.c: In function 'rtw_regd_init':
/build/source/os_dep/linux/wifi_regd.c:409:36: error: 'REGULATORY_IGNORE_STALE_KICKOFF' undeclared (first use in this function)
  409 |         wiphy->regulatory_flags |= REGULATORY_IGNORE_STALE_KICKOFF;
      |                                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think I have found something close https://github.com/morrownr/88x2bu-20210702/issues/165

[morrownr]

Hi @Stanislav-Lapata

The related issue is the same issue you have. I am working and testing. There is no perfect solution right now due to the way this was handled in the Linux kernel but I am going to merge the best fix I have shortly. Give me a few minutes to merge the best fix I have and I will post back here.

[morrownr]

I have merged the little patch that I think will help you.

You can use the following to update:

$ git pull $ sudo sh install-driver.sh

Let me know if this helps.

[jeremiehuchet]

@Stanislav-Lapata I'm running nixos too. You can use Jesus-M workaround (keep using 6.1.38) adding this in your configuration.nix:

boot.kernelPackages = pkgs.linuxPackagesFor (
  pkgs.linux_6_1.override { argsOverride = { version = "6.1.38"; }; }
);

[Stanislav-Lapata]

@jeremiehuchet Thanks, I have already done it but I created issue because 6.4+ kernel has the same problem. @morrownr I can't check it because I am newbie in Linux and NixOS. I think I will close issue. Thanks for your work!

[morrownr]

@Stanislav-Lapata

I can't check it because I am newbie in Linux and NixOS.

Stick around, you won't be a newbie for long. This particular problem is unusual.

While you are here and since you may not know that this site has a Main Menu:

https://github.com/morrownr/USB-WiFi

The first 2 menu items might be of interest and then there is a lot more.

@jeremiehuchet

I see both of you are using NixOS. If either or both of you would like to look at the sections where I have information related to specific distros and submit the info for NixOS, that would be fine.

@morrownr

[exzombie]

I see both of you are using NixOS. If either or both of you would like to look at the sections where I have information related to specific distros and submit the info for NixOS, that would be fine.

Which distro-specific sections are you referring to? Maybe I'm dim, but I can't find them. The README only has generic installation instructions, and I don't see anything in the FAQ either. I just wanted to see what kind of information you have there. For NixOS specifically, nothing special needs to be done because many of these RTL drivers are packaged by the distro. You just enable the module in the OS configuration and that's it.

[jeremiehuchet]

@morrownr I wish I made some research before buying my TP Link adapter!

Regarding nixos, your driver is packaged and available out of the box. My first setup of your driver was really smooth so I don't think you need to document specific instructions. Especially for nixos which has a specific package manager.

@Stanislav-Lapata I found a way to override the package definition of the module until the nixpkgs is updated:

boot.kernelPackages = pkgs.linuxPackages_latest.extend (lpSelf: lpSuper: {
  rtl8821au = lpSuper.rtl8821au.overrideAttrs (rtl8821auOld: rec {
    src = pkgs.fetchFromGitHub {
      owner = "morrownr";
      repo = "8821au-20210708";
      rev = "0dc022287b0ab534efa885881eaa65c5503291be";
      hash = "sha256-pLRBWdqlv9A39VbCS8dymTCJHcwJooqD8v6mTbOsBz0=";
    };
  });
});

[morrownr]

Which distro-specific sections are you referring to?

README:

Tested Linux Distributions Installation Steps - Step 2 and Step 3

The README only has generic installation instructions...

No, Installation Steps 2 and 3 are very specific to distros.

I wish only generic instructions would work but we have little standardization in some areas which makes things far more complicated than they should be. Distro maintainers mostly have limited resources so they mostly should attempt to determine and follow what appears to be the predominant standard. apt is a perfectly adequate package manager standard but we have dozens of package managers which means distro managers are wasting thousands of man-hours on stuff that is not making any real improvement to the Linux platform.

because many of these RTL drivers are packaged by the distro. You just enable the module in the OS configuration and that's it.

Distros packaging their own out-of-kernel drivers is problematic. First and foremost, distros should understand the issues at hand well enough that they should not make things worse. I understand why some some distro managers may think making their own version of drivers is a good idea but it is not. You should see the problems I see with Arch uses. I try to help but if they are using this driver repackaged in AUR, then I have to tell them that I support this driver installed following the instructions in this repo, not repacked drivers.

The first priority should be to follow the guidance from the Linux Foundation. Such guidance is that wifi drivers should be in-kernel and supported by the company making the hardware. The reason for this guidance is that Linux is under continuous development and releases come about every 2-2.5 months. This makes a Windows type of new version schedule, every few years, impossible. Please ask questions if you want.

Given this guidance and reality, Linux users seeking a USB WiFi adapter should first and foremost get an adapter that uses chipsets from a company that is following Linux guidance. The Plug and Play List, shown as menu item 2 in the Main Menu, shows many adapters that use in-kernel drivers. Drivers that are maintained primarily by the company that produces the chipsets. This allows uses to buy an adapter, plug it in and get on with their business instead of wondering where they can get a driver that may or may not work.

The 3 primary bits of guidance that I highlight in Main Menu item 1 are:

• Buy an adapter that is single state
• Buy an adapter that is single function
• Buy an adapter that uses an in-kernel driver

If this guidance is followed, the probability of happiness is greatly improved. If Linux users understand this and adjust purchases accordingly, the Realtek will see lost sales and may start doing things right.

Keep in mind that I maintain the Realtek based drivers here at this site not to encourage Linux users to buy Realtek based adapters but to help those that already have the Realtek based adapters. While they are here, I try to get the information to them about what better solutions are available.

@morrownr

[exzombie]

I, for one, greatly appreciate your effort, both in maintaining these drivers, and in explaining the issues with them, again and again. It is thanks to you that I even know about Mediatek, and will never buy Realtek again.

I would just like to point out that NixOS is very different from other distros, and you need a NixOS configuration module to wrap a kernel module. I think you will find it difficult to adapt your installation instructions. You would basically have to teach users how to write a NixOS module. Thankfully, NixOS already provides that.

I also understand that such packaging can cause issues, and that you can't support it. IMHO it is perfectly acceptable to redirect the user to distro support, or require that they install using the supported method. Just be aware that the latter is probably not possible on NixOS.

[morrownr]

Just be aware that the latter is probably not possible on NixOS.

If this is the case then I see a problem. It is fundamental Linux to be able to use gcc and make to compile and install source code. The installation script I have as the primary means for a user to install this driver follows the 2 main ways of compiling and installing code on Linux. The script is simply to automate the process for those that are not developers.

1. Basic Manual Installation

$ make clean $ make $ sudo make install $ sudo reboot

2. dkms installation

I won't spell out the steps as you can see them inside the source of install-driver.sh.

If NixOS cannot support both of those methods then it cannot even compile a Linux kernel and that is just fundamental.

Arch Linux has their AUR but a lot of Arch users stop by here and use the instrunction I have and it works fine unless they have messed something else up. Arch does some non-standard things with header files that leads to problems.

You can test. Remove the driver you have installed via NixOS and do the Basic Manual Instructions I posted. If it does not work then there are a lot of things that won't work in NixOS and that is not cool.

@morrownr

[Stanislav-Lapata]

You can test. Remove the driver you have installed via NixOS and do the Basic Manual Instructions I posted. If it does not work then there are a lot of things that won't work in NixOS and that is not cool.

If I understand right, it will work but not for long because after commands nixos-rebuild boot nixos-rebuild switch NixOS rebuilds kernel with instructions from /etc/nixos/configuration.nix

[exzombie]

It is fundamental Linux to be able to use gcc and make to compile and install source code.

Agreed, and that works on NixOS with no issues. Building a module and playing with it using insmod is the same as any other Linux. Where it differs is installation of development tools, and system administration: there is no /lib/modules, there is no /usr and so on. So, any installation instructions would necessarily be very different.

My recommendation is: don't worry about it. The point I want to make is that many people want to do things differently, and you shouldn't lose sleep over that. It's very nice of you that you try and accommodate everyone, and I think you are doing an excellent job with the more mainstream distros, but there are limits to what a person can do.

In any case, I believe NixOS users won't be a source of packaging related issues in your repos: those packages don't apply any additional patches over your code. At most, we will report issues related to kernel versions, such as this very issue. And if you need a NixOS user to test a fresh commit, just tell them to do so, maybe mention the NixOS wiki; even if they're a newbie, they can figure out how to override a package, just as Jérémie above had. He even updated the NixOS package to install a newer version of the driver. I have done that in the past for 88x2bu. We'll take care of this stuff for you, as long as some of us (are forced to) use these adapters.

[morrownr]

The point I want to make is that many people want to do things differently, and you shouldn't lose sleep over that.

I get the part about doing things differently and I certainly won't lose any sleep over this. I do not support RHEL or distros based on RHEL. I don't support Android or Chrome OS. My friendly warning is: Does doing things differently regarding the subject at hand help achieve the goals that go with NixOS? I'll assume, possibly incorrectly, that becoming popular and widely used is one of the goals of NixOS. If so, I submit that messing up standard usage is this way is not only not helping with that goal but hindering it. If you were about to add instructions in this and the other repos here for NixOS, it is free advertising. You may not realize how many people stop by here. The USB-WiFi repo is currently at about 1,600 hits per day. The driver repos are getting hits in hundreds daily. Doing things differently in areas where different really is providing no tangible advantage is expensive for users. Having to relearn skills when going from one OS to another is a serious impediment . Reducing the cost to users is makes is easier to gain users.

If I am wrong about the goals and the goal is simply to do things differently for personal fulfillment, fine. Enjoy.