I have a wifi dongle that uses this driver.
https://github.com/morrownr/8812au-20210629
I have worked through several issues with this communities help.
But now I have a new one. it is like this
https://github.com/morrownr/8812au-20210629/issues/60
the developer is suggesting my DKMS is not working correctly and suggests he has a scrip that fixes it.
While one can appreciate a developer who has a fix, my question is, Is my DKMS broken?
How do i diagnose either way?
Is the difference that the driver assumes systemd?
Which is why it works on systemd distros?
Did the developers fix fix it ?
If so If I'd suggest freezing the kernel you are on and only updating it periodically.
Otherwise you'll be fixing the issue every time the kernel updates.
You can stop the kernel, and headers, updating by editing /etc/pacman.conf
IgnorePkg = linux linux-headers
Is your dkms broken ? Or is the developer of the driver's dkms implementation broken ?
I've no idea. Do you have other dkms modules which work ?
The fact the dev was extremely rapid to provide a script sort of suggests they've encountered this before. But proves nothing.
Personally I struggle to debug / troubleshoot dkms issues when sat in front of my own PC, so wouldn't be able to help you with that myself.
It is the only DKMS device I have.
I was hoping someone would come along and confirm/deny it is because the driver assumes systemd, which I am unsure it does, but think it does.
I do not believe my dkms is broken, because it is the same DKMS all the other artix users have.
It just takes a few minutes to remove and reinstall the driver, which I guess I'll do until i get a better answer.
does it seem insane that the init has infected device drivers?
I'm not convinced it has in this case? What makes you think so ?
I've read your first post and the linked issue a couple of times and I'm still having to guess exactly what the issue is.
You need to be more descriptive.
I'm guessing that the first time dkms is run a module is created and everything is fine ?
At the next kernel update dkms installs another module, doesn't remove the previous one and the module doesn't load.
Is that correct?
because thats the only difference between arch and artix, and it is the aur driver for Arch.
And also I note a small bug, for me, in the install scripts that assume systemd
https://github.com/morrownr/8812au-20210629/issues/59
If I use the install script provided by the dev, the device installs and works fine.*
I think, but do not know, that script uses dkms to install the driver, but may be wrong.
If the kernel updates, a second device is installed and the original not removed, and the device is broken.
so, yes that is correct
*I had to explicitly set my host name as this driver was changing my host name and breaking x sessions.
https://aur.archlinux.org/packages/rtl8812au-dkms-git
Apparently others are having issues with this driver.
Perhaps I should switch drivers
No harm trying you can always switch back.
It is the main difference but there's many differences between installs of one or the other. I bet if you look on the Arch forum there's loads of examples where some users can get a particular driver working and others can't. Yet all use systemd.
What I'm trying to get across is keep an open mind. I've wasted a lot of time in the past being fixated that such and such was the cause of an issue and realised in the end it was something else entirely.
However....
you're right. The script uses hostnamectl. But all it's doing is getting the OS name and outputting it to the terminal. That alone wouldn't cause issues but if the dev has used one systemd program there could be more instances of systemd only commands ?
I'm fairly certain that was NetworkManager doing the hostname changing in one of your previous threads.
If you want to debug this further try to figure out why the old module is not being deleted. Also why the naming format of the second module is slightly different. Read the dkms man page. Try to get verbose output.
Post it up and if anything stands out someone might notice.
I noticed DKMS just had an update. how can i tell what the artix dkms update was?
is this my bug?
https://github.com/dell/dkms/issues/224
You can see the Artix dkms package files here (https://gitea.artixlinux.org/packagesD/dkms/src/branch/master/x86_64/extra)
The history is here (https://gitea.artixlinux.org/packagesD/dkms/commits/branch/master/x86_64/extra)
That shows (looking at the PKGBUILD as well) dkms is now compiled from the v3.0.5 tag of https://github.com/dell/dkms
This (https://github.com/dell/dkms/compare/v3.0.3...v3.0.5) shows the commits since the last packaged tag (v3.0.3)
I doubt it. I thought you had an issue with the previous module not being removed ? Not the module being installed to the wrong place ?
I switched to https://aur.archlinux.org/packages/rtl88xxau-aircrack-dkms-git
And now I have no issues.
But we will see.
dkms was updated not too long ago. might have resolved? maybe?
3.0.5-2 was updated on 7/15/2022
I switched to the new aur after update.
It made no difference for me.
You can also use https://packages.artixlinux.org/ site:
https://packages.artixlinux.org/details/dkms
interesting
@SGOrava . Do you know how packages are chosen to be added to that?
Back to my firmware, the new package failed upon a new kernel update.
reinstall of the new package fixed it.
So it seems there may be something with the DKMS that is problematic.
How could I debug this further?
Like can i roll back the kernel update get it working and log what DKMS does after reupdateing the kernel?
whatever is happening with DKMS it is not working with these drivers and artix.
getting ready to apply this kernel update.
Anything I should do so see why DKMS is not working?
getting ready to post the issues, when https://github.com/aircrack-ng/rtl8812au/issues/993
I guess i'll not reboot till then