Information Request: Best method to determine driver installed? Or git update is available before doing actual git pull?

[Jibun-no-Kage]

Posting here... since we don't have a discussions page enabled, and this is applicable to all drivers Nick publishes...

I am working on Ansible based logic to install a group of drivers, in support of a standardized OS image. The current logic per driver is to always execute the current remove driver script, if it exists, then pull the latest release from github, then execute the install driver script. (Doing a git clone if not existing git directory of course). This works well, but has a harsh impact on slower models of Pi (and comparable SBCs) in that the removal and install process can take a rather long time to complete. When staging several drivers for a compressive base image, this can take hours if not days. The wholesale replacement is not elegant or adaptive, for existing OS instances already deployed.

For OS instances already deployed, a typical solution would be to have check point test in the Ansible scripting to validate an update is available, and only then execute the remove and then in turn the install scripts as noted above.

The question is, how to structure this check? So asking what would be the best method to determine a update is pending? Steps that come to mind:

1. Determine of any git directory exits for given driver (relatively easy in Ansible)
2. Determine the current git directory version, if older than do a git pull (not sure at this point how to do this in Ansible, need research)
3. Execute the remove and install scripts for driver (already in place if update found available)

I don't see a straight forward way to query for the driver object file (.ko) or such and compare to the git directory, but maybe there is an easy way to do this type of check I am not aware of?

Of course, I also need to establish some type of method to decide when to use kernel based versus git based driver option, but that is a design goal for a later day, for now assuming will always source driver from git from a static list of drivers per the Ansible scripting.

What would be preferred is for the logic to be progressive, in that by just re-executing the Ansible script, any pending updates (per driver) are installed, something comparable to how 'apt update && apt upgrade' works in principle.

Any thoughts or suggestions welcome. Of course if there is a better location to post this type of question, let me know of that as well, :)

[morrownr]

Hi @Jibun-no-Kage

I am working on Ansible based logic to install a group of drivers, in support of a standardized OS image.

Building your own distro these days?

I'm going to try to discourage you from using the out-of-kernel drivers that I have up here. I've been spending time working with a small group trying to get replacements that are Linux Standards Compliant in the kernel. Actually the rtw88 8821/11cu driver is already in the kernel so we have been making improvements. Tell me what you are up to and maybe I can update you on the plans for the various chips.

[Jibun-no-Kage]

Really just automating the base OS images I use on various SBCs. The current image based on bullseye pulled your drivers, so I used that as a starting point. Decided to finally sit down and spend some time with Ansible.

I have no problem using the kernel based solution, as is applicable of course. Frankly it removes some of the installation tasks driven by Ansible scripting. The devices I plan to support on the image in question:

8812au
8821au
8821cu
88x2bu
8852bu

If all of these are in kernel now? So much the better.

[Jibun-no-Kage]

The interesting thing is I cannot seem to get the 8852bu driver to compile when triggered by Ansible... Not sure why. Maybe because the target SBC is a Pi Zero? Limited resources? Of course, if said driver is now in kernel, moot point right?

But just to document what I tripped over...

# ./install-driver.sh
: ---------------------------
: install-driver.sh v20240429
: armv7l (kernel architecture)
: arm (architecture to send to gcc)
: 1/4 (in-use/total processing units)
: 435920 (total system memory)
: 6.6.31+rpt-rpi-v7 (kernel version)
: gcc-12 (version of gcc used to compile the kernel)
: gcc (Raspbian 12.2.0-14+rpi1) 12.2.0
: dkms-3.0.10
: mokutil not installed (Secure Boot status unknown)
: ---------------------------

Checking for previously installed drivers...
Removing a driver that was added to dkms.
Deleting module rtl8852bu-1.19.3 completely from the DKMS tree.
Removing 8852bu.conf from /etc/modprobe.d
Removing source files from /usr/src/rtl8852bu-1.19.3
Finished checking for and uninstalling previously installed drivers.
: ---------------------------

Starting installation.
Copying 8852bu.conf to /etc/modprobe.d
The dkms installation routines are in use.
Copying source files to /usr/src/rtl8852bu-1.19.3
Creating symlink /var/lib/dkms/rtl8852bu/1.19.3/source -> /usr/src/rtl8852bu-1.19.3
The driver was added to dkms successfully.
: ---------------------------

Sign command: /lib/modules/6.6.31+rpt-rpi-v7/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

Building module:
Cleaning build area...
kernelver=6.6.31+rpt-rpi-v7 ./dkms-make.sh..........................................................................(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.6.31+rpt-rpi-v7 (armv7l)
Consult /var/lib/dkms/rtl8852bu/1.19.3/build/make.log for more information.
An error occurred. dkms build error:  10
Please report this error.
Please copy all screen output and paste it into the problem report.
Run the following before reattempting installation.
$ sudo ./remove-driver.sh

[morrownr]

The devices I plan to support on the image in question:

8812au
8821au
8821cu
88x2bu
8852bu

8821cu and 88x2bu are in kernels 6.2 and later. Recommend 6.6 and later for 88x2bu and 6.7 and later for 8821cu.

8821au is in testing right now. It looks really good. 8812au is under development. I'm hoping we can get both in before the next LTS... probably 6.12.

8852bu. Ouch. I've been posting messages warning Linux users to stay away from Realtek based WiFi 6 adapters. There is no usb support in rtw89 and the out-of-kernel drivers are really bad. My best guess as to when that could happen is maybe 2-3 years down the road. When it comes to WiFi 6, going with a Mediatek based adapter is far and away the best solution, In the Plug and Play List, in the WiFi 6 section is a little Edup adapter that works really well and does not cost much. I have one.

[morrownr]

I cannot seem to get the 8852bu driver to compile...

Not a bit surprised. Now you have an idea what I had to deal with when getting this driver ready for a repo. I only support managed mode on this driver. To help see what is happening:

$ sudo sh remove-driver.sh
$ make clean
$ clear
$ make

...maybe that will give us an idea where it is blowing up.

[Jibun-no-Kage]

Will manual build a shot this weekend.

So for 8821au... that is an explicit git pull for now. Looks like I may look into 6.7 for Pi OS, I have been looking for an excuse to do a kernel build (cough).

The bulk of the sensor packs that are deployed actually use (quite old) 8188CUS and 8188EUS. I think a couple use 8811au.

8852bu I got and have used on an old laptop. I don't use much WiFi 6 other than a couple of relatively new mini PCs (as backup to wired). All the new stuff I am getting is only MediaTek with my Pi stuff. I just need to support the installed sensor modules that rolled out with the older RealTek stuff. Hence creating the new base image. Since IoT stuff is low demand on WiFi have yet to upgrade my WiFi infrastructure to 6. I can live without 8852bu on the image, just figured since I had it in the Ansible I would let it fly.

[morrownr]

So for 8821au... that is an explicit git pull for now.

Yes, it has to be pulled and compiled for now as it is in testing. It should be upstreamed to the Linux kernel soon. You can find info about where the driver is located and more by reading the first message in the following Issue:

morrownr/8821au-20210708#133

Your testing and reporting would be welcome.

Looks like I may look into 6.7 for Pi OS, I have been looking for an excuse to do a kernel build (cough).

I have a guide for doing such with the RasPiOS around here somewhere. Should I dig it out?

Also, remember that in-kernel drivers need one or more firmware files in the distro. You may have to crosscheck that. On the Main Menu here are the site is a menu item that goes into firmware. Let me know if you can't find it.

I'll try to help you with other things but as you can tell, I am really focused on getting the situation where Linux users do not have to compile these poorly done Realtek out-of-kernel drivers. I think it can be done within a reasonable amount of time with the WiFi 5 chips but the best I can recommend based on what I know is for Linux users to avoid the Realtek WiFi 6 chips and go to Mediatek chips where the support is already in place and is well tested at this point.

[Jibun-no-Kage]

Yes, I remembered about the firmware... sometime ago, I had an old i386 machine where I had to add firmware to support some hardware features that were not recognized on the core Debian installation.

I will avoid tying up your assistance, I recall how busy you get!

I did some quick testing this morning, and for my needs, looks like 6.6.x supports everything I have but an odd 8811AC, so I can move forward with my base image, before I tackle the kernel build effort. I don't recall where I picked this one up... old system I refurbished maybe. Looks like no Pi OS/native support, so that maybe the one out of kernel driver I may have to keep in my base image, or I just don't use it.

Yes, going forward, as I noted, I am walking away from the RealTek ICs, just have older stuff I still need to support. I have couple MediaTek based devices now, and the difference is clear and obvious... your suggestion to move to MediaTek has never disappointed.

Now if we could just get the various motherboard manufacturers to stop using RealTek. Oh, and don't get me started on the Intel 225 series either (cough). What a can of worms 2.5GB support is right now on some Intel NICs. Finally decided to take the house and casitas to a fiber backbone, to support my NAS, Maybe overkill but let me skip some of the copper 2.5GB growing pains.

As always, Nick, thank you very much for taking the time to respond, greatly appreciate all your help and insights over the years... years? Good Grief!