Installation not possible after previous failed installation

[nazar-pc]

Version of xpadneo

0.10.2

Describe the Bug

If installation fails initially, for example:

WARNING: kernel uhid module not found, controller firmware 5.x will not be supported
* deploying DKMS package
Creating symlink /var/lib/dkms/hid-xpadneo/v0.10.2/source -> /usr/src/hid-xpadneo-v0.10.2
* building module
Sign command: /usr/src/linux-headers-6.19.11-x64v3-xanmod1/scripts/sign-file
Binary update-secureboot-policy not found, modules won't be signed

Building module(s)...(bad exit status: 2)
Failed command:
make -j64 KERNELRELEASE=6.19.11-x64v3-xanmod1 -C '/lib/modules/6.19.11-x64v3-xanmod1/build' M='/var/lib/dkms/hid-xpadneo/v0.10.2/build/src' VERSION='v0.10.2' modules LLVM=1
ERROR (dkms apport): binary package for hid-xpadneo: v0.10.2 not found

Error! Bad return status for module build on kernel: 6.19.11-x64v3-xanmod1 (x86_64)
Consult /var/lib/dkms/hid-xpadneo/v0.10.2/build/make.log for more information.

Repeated calls will fail even after fixing the root of the issue:

WARNING: kernel uhid module not found, controller firmware 5.x will not be supported
* deploying DKMS package

Error! DKMS tree already contains: hid-xpadneo/v0.10.2
You cannot add the same module/version combo more than once.
make: *** [Makefile:65: install] Помилка 3
HINT: Try uninstalling xpadneo first

The hint is correct and helps, but I think it should be done automatically, especially if the binary compiled module is not present yet.

[kakra]

Repeated calls will fail even after fixing the root of the issue:

What has been the root issue?

[nazar-pc]

Initially it was #614, but this is a more general issue

[kakra]

BTW: Running install.sh tries to deploy the module, and for your convenience also tries to build the module via dkms. If the version is already installed to dkms, you should not run the installer again. The error is expected in this case. Rather, let dkms rebuild the module, i.e. during kernel updates.

That your llvm linker is missing is actually a coincidence triggering this problem, but xpadneo should not try to magically work around what might be broken in the system. We did this in the past and it caused a lot of headaches with dkms becoming out of sync.

[nazar-pc]

Hm... would it make sense to roll back if initial installation resulted in an error? I just found it surprising. I'd expect installation to be idempotent, meaning it has a few steps and those that already succeeded last time would simply be skipped on repeated runs.

[kakra]

Hm... would it make sense to roll back if initial installation resulted in an error?

I wish we could do that but it seems that dkms hides most if not all errors from us. See also #278.

[nazar-pc]

Well, feel free to close this if it is not actionable, but I think it'd be a nice quality of life improvement for new users

[kakra]

but I think it'd be a nice quality of life improvement for new users

Yes, and that's exactly why I'd like to keep this open. It's another example of why dkms should not hide build failures from us. It only fails at a later step.

I guess we could run a test build in the installer before trying to add the source code to dkms. This issue shows that this is only reasonable if we also properly determine the same toolchain that dkms will use. Otherwise this step will become useless. But I may consider adding a test target to the Makefile as a starter.

installer.sh is mostly a convenience script. xpadneo has been migrated to actually rather use the Makefile. It has separate steps for installing support files and deploying itself to dkms. We could make make test a required step of the installer.

May I ask if you'd be available for further tests in the future? I probably won't add any source code changes during the next days or 2-3 weeks.

Personally, I don't use dkms (that's usually not how Gentoo does it). I run make -C hid-xpadneo modules reinstall to update or install the modules. As this is intended as a development helper, it will call sudo when actually installing the module. Usually, I avoid such surprises. But I just wanted to let you know. This way, not the whole make process has to be run as sudo, keeping permissions in the git checkout clean. Also, as a "personal tool", it uses ld.bfd by default which has been needed in Gentoo at least for a while in the past. But you can easily override it.

[kakra]

I think we could also try to skip this step in the installer:

Error! DKMS tree already contains: hid-xpadneo/v0.10.2
You cannot add the same module/version combo more than once.

If the source is already there, there should be no need to re-deploy it. OTOH, we had cases in the past where the local source didn't match the source deployment in dkms. It would be nice if dkms could just allow re-deployments of the same version.

And we'd need a unique exit code from dkms to detect this.

I'm currently preparing a xpadneo doctor tool. I think we should implement countermeasures there.