Adapt code for dkms and CI build

[orensbruli]

Closes SC-38654

[orensbruli]

It's working. Can download artifact from thee CI build: https://app.circleci.com/pipelines/github/Greenzie/emuccan-b202/6/workflows/e7c66b9e-4165-43c4-9b8f-26ce9e4ba069/jobs/6/artifacts

Tested to instal package on GZDEV9 and GZDEV4

[orensbruli]

Testing on GZDEV30: https://greenzie.slack.com/archives/CRTTEQ7EE/p1718895358925049

Asciinema recording of the session: https://drive.google.com/file/d/17gf8O7OiPjI3IROyTHDtlwDIrrtqJvjx/view?usp=sharing

• Checked that candump any was working :ok_hand:
• Removing emuc2socket module
  • Failed, something is using
  • Some session had candump running. killed
  • Still failing.
  • Something is running and restarting emucd_64 on can0 and can1. *systemctl stop emucccan
• Removed :ok_han d:
• candump any not working, as expected.
• Download debian package for emuccan from CI artifacts
• Installation
  • Failed to load. Same version of the module already installed.
  • Uninstalled.
  • Checked installed modules with find.
  • Moved ko to backup
  • Installed again.
  • Module is loaded with the installation.
• systemctl start emuccan
• candump is working.
• Check that the right module is loaded with modinfo :ok_hand:
• Uninstalled.
• Restored old module.
• Restarted the service.

Note: We will have problems with the installation if an old module is manually installed in the mower. Not sure if we should do some automatic thing to avoid or just being careful when installing.

[edavies64]

Note: We will have problems with the installation if an old module is manually installed in the mower. Not sure if we should do some automatic thing to avoid or just being careful when installing.

@orensbruli I believe we manually install the old module during our post install steps, so it would be fair to expect that the majority of our mowers with this module will have it manually installed.

[orensbruli]

Note: We will have problems with the installation if an old module is manually installed in the mower. Not sure if we should do some automatic thing to avoid or just being careful when installing.

@orensbruli I believe we manually install the old module during our post install steps, so it would be fair to expect that the majority of our mowers with this module will have it manually installed.

Ok. Then we need to make some workaround because we need to use the Debian package post install and there's a bug on DKMS that can be overcome adding our own debian folder to the project: https://github.com/dell/dkms/issues/53#issuecomment-1591788158

Not a big deal, just some boilerplate.

Just to clarify, the post-install script should:

• check if old module exists
• Unload old module (this can be tricky if some processes are using the module at the same time).
• Backup and remove old module
• :thinking: something else?

[orensbruli]

I have been trying to add a post-install script to this one to test. The current greenzie-dkms need a fix to include subfolders of drivers: https://github.com/Greenzie/greenzie-debianize-tool/pull/4

And the corresponding docker image build to be triggered when this change is merged: https://github.com/Greenzie/greenzie-docker-images/tree/main/debianize#automated-build-and-deployment

Then we can test this again. Our current workflow is a little bit complex. I have tested all this locally but :shrug:

[orensbruli]

@edavies64 @AGummyBear I finally added the post-install and post-remove scripts to this PR, please review.