Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kernel modules don't support the latest kernel #506

Closed
Eeems opened this issue Nov 29, 2021 · 8 comments · Fixed by #858
Closed

Kernel modules don't support the latest kernel #506

Eeems opened this issue Nov 29, 2021 · 8 comments · Fixed by #858
Labels
bug Something isn't working packages Add or improve packages of the repository
Milestone

Comments

@Eeems
Copy link
Member

Eeems commented Nov 29, 2021

It looks like OS 2.10.3 is now 5.4.70 based. The wireguard and fuse packages generate 4.14.78 and 4.9.84-zero-gravitas folders, but not 5.4.70-zero-gravitas.

cc @jonahweissman @plan5

@Eeems Eeems changed the title Wireguard doesn't support latest kernel Kernel modules don't support the latest kernel Nov 29, 2021
@Eeems
Copy link
Member Author

Eeems commented Nov 29, 2021

@matteodelabre we probably should have a kernel meta package along with whatever we do for #445 to support different OS versions.

@Eeems Eeems added bug Something isn't working packages Add or improve packages of the repository labels Nov 29, 2021
@Eeems
Copy link
Member Author

Eeems commented Nov 30, 2021

I wonder if exploring something similar to dkms would make sense?

@ju6ge
Copy link

ju6ge commented Aug 14, 2022

Hey is there any information available to help with this? I am trying to use wireguard to connect the remarkable to my home network, but due to the outdated packages it will not work 😭

@rM-self-serve
Copy link
Contributor

rM-self-serve commented Mar 5, 2023

still interested

@Eeems
Copy link
Member Author

Eeems commented Aug 18, 2023

At this point, I think we need to remove the kernel modules from the repository and re-think how we distribute them. Something similar to dkms might be the solution. I think what would be a better solution though would be to package the kernel modules for the various kernel versions, as well as the stock kernel at the different versions, and figure out how to manage picking the right version for the running OS on install/reenable of toltec. A meta package for the OS version, or some other OS version mechanism in the packages is probably needed.

@Eeems
Copy link
Member Author

Eeems commented Dec 6, 2023

The current plan is to drop kernel module packages for 3.x onward, while keeping the 2.x ones around for now. They'll be automatically removed as part of re-enabling in 3.x. A longer term solution will still be needed to allow people to install modules without having to have a custom kernel with every single one.

I'm tempted to say we have a package that downloads the correct build for your kernel, and have automated builds for every single tag or something? That or maybe a package per kernel tag for the different modules?

The more I think about dkms, the more I think it's a good solution, but that these devices aren't powerful enough for it to be realistic.

@RomanHargrave
Copy link

I'm tempted to say we have a package that downloads the correct build for your kernel, and have automated builds for every single tag or something? That or maybe a package per kernel tag for the different modules?

This has likely been solutioned elsewhere, but I ran across this nonetheless while hoping that I could get wireguard working on my rm2 without cross compiling anything myself.

Has the idea of having one repository for system-software-version-agnostic packages, and then repositories for each supported version of the system software? opkg should support this.

@Eeems
Copy link
Member Author

Eeems commented Jan 27, 2024

I'm tempted to say we have a package that downloads the correct build for your kernel, and have automated builds for every single tag or something? That or maybe a package per kernel tag for the different modules?

This has likely been solutioned elsewhere, but I ran across this nonetheless while hoping that I could get wireguard working on my rm2 without cross compiling anything myself.

Has the idea of having one repository for system-software-version-agnostic packages, and then repositories for each supported version of the system software? opkg should support this.

#701

@Eeems Eeems linked a pull request May 24, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working packages Add or improve packages of the repository
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants