(solved, sort of) Driver not working on Fedora 35 kernel 5.16.7-200.fc35.x86_64 (disable secure boot)

[David-Stephenson]

Hello, I installed the driver on Fedora 35 workstation kernel 5.16.7-200.fc35.x86_64 and the driver isn't working. I am using the Alfa AC1200. The driver works on my Raspberry PI. I'm not sure what I should do from here and support would be appreciated.

[morrownr]

Hi @DucksDont

I am using the Alfa AC1200.

Yes, but which ALFA AC1200 adapter?

Please post the results of:

lsusb

[David-Stephenson]

Sorry, I'm using the Alfa AWUS036ACH Bus 003 Device 013: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac 2T2R DB WLAN Adapter

[morrownr]

I'm using the Alfa AWUS036ACH

Good adapter.

I need more info about your setup. Run and post the results of the following command:

sudo uname -a; mokutil --sb-state; rfkill list all; dkms status; iw dev

[David-Stephenson]

Linux mlady 5.15.16-200.fc35.x86_64 #1 SMP Thu Jan 20 15:38:18 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
SecureBoot enabled
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
rtl8812au/5.13.6, 5.15.16-200.fc35.x86_64, x86_64: installed
rtl8812au/5.13.6, 5.16.7-200.fc35.x86_64, x86_64: installed
xone/v0.1-94-g6af0fec, 5.15.16-200.fc35.x86_64, x86_64: installed
xone/v0.1-94-g6af0fec, 5.16.5-200.fc35.x86_64, x86_64: installed
xone/v0.1-94-g6af0fec, 5.16.7-200.fc35.x86_64, x86_64: installed
phy#0
	Unnamed/non-netdev interface
		wdev 0xb
		addr ac:74:b1:88:14:72
		type P2P-device
		txpower 0.00 dBm
	Interface wlp0s20f3
		ifindex 2
		wdev 0x1
		addr ac:74:b1:88:14:72
		ssid EpicWifi
		type managed
		channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
		txpower 22.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

[morrownr]

I need you to open the file Makefile with a text editor and find these lines:

###################### Platform Related #######################
CONFIG_PLATFORM_I386_PC = y
CONFIG_PLATFORM_ARM_RPI = n
CONFIG_PLATFORM_ARM64_RPI = n

Your lines should look like the ones above. Tell me what you find.

[David-Stephenson]

###################### Platform Related #######################
CONFIG_PLATFORM_I386_PC = y
CONFIG_PLATFORM_ARM_RPI = n
CONFIG_PLATFORM_ARM64_RPI = n
CONFIG_PLATFORM_ANDROID_X86 = n
CONFIG_PLATFORM_ANDROID_INTEL_X86 = n
CONFIG_PLATFORM_JB_X86 = n
CONFIG_PLATFORM_ARM_S3C2K4 = n
CONFIG_PLATFORM_ARM_PXA2XX = n
CONFIG_PLATFORM_ARM_S3C6K4 = n
CONFIG_PLATFORM_MIPS_RMI = n
CONFIG_PLATFORM_RTD2880B = n
CONFIG_PLATFORM_MIPS_AR9132 = n
CONFIG_PLATFORM_RTK_DMP = n
CONFIG_PLATFORM_MIPS_PLM = n
CONFIG_PLATFORM_MSTAR389 = n
CONFIG_PLATFORM_MT53XX = n
CONFIG_PLATFORM_ARM_MX51_241H = n
CONFIG_PLATFORM_FS_MX61 = n
CONFIG_PLATFORM_ACTIONS_ATJ227X = n
CONFIG_PLATFORM_TEGRA3_CARDHU = n
CONFIG_PLATFORM_TEGRA4_DALMORE = n
CONFIG_PLATFORM_ARM_TCC8900 = n
CONFIG_PLATFORM_ARM_TCC8920 = n
CONFIG_PLATFORM_ARM_TCC8920_JB42 = n
CONFIG_PLATFORM_ARM_TCC8930_JB42 = n
CONFIG_PLATFORM_ARM_RK2818 = n
CONFIG_PLATFORM_ARM_RK3066 = n
CONFIG_PLATFORM_ARM_RK3188 = n
CONFIG_PLATFORM_ARM_URBETTER = n
CONFIG_PLATFORM_ARM_TI_PANDA = n
CONFIG_PLATFORM_MIPS_JZ4760 = n
CONFIG_PLATFORM_DMP_PHILIPS = n
CONFIG_PLATFORM_MSTAR_TITANIA12 = n
CONFIG_PLATFORM_MSTAR = n
CONFIG_PLATFORM_SZEBOOK = n
CONFIG_PLATFORM_ARM_SUNxI = n
CONFIG_PLATFORM_ARM_SUN6I = n
CONFIG_PLATFORM_ARM_SUN7I = n
CONFIG_PLATFORM_ARM_SUN8I_W3P1 = n
CONFIG_PLATFORM_ARM_SUN8I_W5P1 = n
CONFIG_PLATFORM_ACTIONS_ATM702X = n
CONFIG_PLATFORM_ACTIONS_ATV5201 = n
CONFIG_PLATFORM_ACTIONS_ATM705X = n
CONFIG_PLATFORM_ARM_SUN50IW1P1 = n
CONFIG_PLATFORM_ARM_RTD299X = n
CONFIG_PLATFORM_ARM_LGE = n
CONFIG_PLATFORM_ARM_SPREADTRUM_6820 = n
CONFIG_PLATFORM_ARM_SPREADTRUM_8810 = n
CONFIG_PLATFORM_ARM_WMT = n
CONFIG_PLATFORM_TI_DM365 = n
CONFIG_PLATFORM_MOZART = n
CONFIG_PLATFORM_RTK119X = n
CONFIG_PLATFORM_RTK119X_AM = n
CONFIG_PLATFORM_RTK129X = n
CONFIG_PLATFORM_RTK1319 = n
CONFIG_PLATFORM_RTK390X = n
CONFIG_PLATFORM_NOVATEK_NT72668 = n
CONFIG_PLATFORM_HISILICON = n
CONFIG_PLATFORM_HISILICON_HI3798 = n
CONFIG_PLATFORM_NV_TK1 = n
CONFIG_PLATFORM_NV_TK1_UBUNTU = n
CONFIG_PLATFORM_RTL8197D = n
CONFIG_PLATFORM_AML_S905 = n
CONFIG_PLATFORM_ZTE_ZX296716 = n

[morrownr]

I'm a little under the weather these days so am going slow.

Did the installation script tell you the installation was successful?

Do you have the ALFA ACH plugged into a USB3 port? Many adapter says they are backwards compatible but that compatibility does not apply in all situations. This adapter requires up to 800 mA of power and USB2 ports can only provide up to around 500 mA of power.

[David-Stephenson]

I forgot to reply earlier, but I disabled secure boot and the driver started working.

[morrownr]

This is good information. Thanks.

I'm going to have to research this more but here is what I know at this point.

I am primarily a user of Debian based distros. I regularly use Linux Mint, Ubuntu, Raspberry Pi OS and Kali. I keep several distros on my test systems, including the Arch based Manjaro but I currently do not have an installation of Fedora or OpenSUSE. I have two test systems with secure boot on so as to test secure boot. I have not seen any secure boot problems with Debian based systems and I don't remember problems with Manjaro but it has been a while since I installed a fresh release.

I use dkms in the installation script. It helps with a lot of issues that will come up if a simple manual installation is used. dkms has the capability to handle the needs of secure boot. dkms was written by and is maintained by Dell. Dell has been offering some Ubuntu pre-loaded systems for years so their devs likely test on Ubuntu. I suspect Fedora and OpenSUSE may be handing their secure boot support differently than Debian based systems and this is leading to problems. This and the other repos I have are VERY heavily used and I am sure there are plenty of Fedora users that use this driver. Are they all turning off secure boot and not reporting the problem? I don't know. What I do know is that reports like this are very rare. Very recently #39 was posted. That poster reported that he was told in the OpenSUSE forums that he needed to turn secure boot off. My opinion is that is not a fix. To get real fixes, problems need to be reported in details to the problem reporting system of the distro in question.

For the driver to compile and install correctly but not be available tells me there is a key issue. Here is an interesting link regarding Debian systems and secure boot:

https://wiki.debian.org/SecureBoot

That document contains a lot of information that can help an investigation into what the real problem is and I invite you and other Fedora users to investigate and present what you know to the Fedora devs via their problem reporting system. I am not in a position to deeply investigate this issue currently but it does need to be investigated. I do intend to post information in the FAQ.

Hopefully this helps.

Regards

[3dsf]

I believe the issues with dkms/fedora and secureboot is that your driver is not signed.
The nvidia driver experiences similar issues.

[morrownr]

I believe the issues with dkms/fedora and secureboot is that your driver is not signed.

I test with 2 systems that have secureboot turned on. In fact, this morning I was testing the 8821cu driver on my laptop system. This system runs Ubuntu 22.04. During installation a dialog popped up that allowed me to activate support and enroll the keys. dkms takes care of this as long as the distro supports it.

If you are willing to test, I can add support to the installation scripts. Let me know.

[3dsf]

I don't think Fedora has autosign ability for dkms. I'll test it to tomorrow on my laptop. If it does not work, what info can I share to be beneficial to you? The laptop is F34, but I was going to bring it to F36 soon, so after I test in F34, I'll take a run on F36.

Anything I can do to help you, let me know.

[morrownr]

I'll test it to tomorrow on my laptop.

Thanks.

If it does not work, what info can I share to be beneficial to you?

I don't know. I'll rework the README's to let folks know to help on this issue and I think the first 2 questions that need to be answered are:

• What are dkms/Ubuntu/Mint doing that it works automatically?

• Do I need to deactivate anything on those distros to establish a new way in the script?

• What is the best way to do this in a script?

Anything I can do to help you, let me know.

If you can isolate and test a good manual/step by step method to sign the drivers, please do.

Regards

[3dsf]

Ok, give me a little bit; I want to submit what I think is the better answer.

[3dsf]

This short blog post pretty much covers everything to handle it like ubuntu (Started F36) automatically self sign nvidia kernel module

---

Is secure boot enabled? mokutil --sb-state not supported on system

EFI variables are not supported on this system

disabled

Failed to read SecureBoot

enabled

SecureBoot enabled

---

If secure boot is enabled & /etc/pki/akmods/certs/public_key.der exists (requires sudo) install with a reminder they will have to enter their secure boot password on reboot.

If secure boot is enabled & /etc/pki/akmods/certs/public_key.der does NOT exist (requires sudo), don't install and direct them to a separate page that instructs them to disable secure boot or do steps 1-5 from the blog post above, and then run the install script again.

Else, let install

---

Pre F36, I'd suggest turning off secure boot

Disable Secure Boot

sudo mokutil --disable-validation

[morrownr]

@3dsf

Thanks for posting this. I am just now getting around to addressing the issue. I hope things go well.

Nick