(Feature request) Can the installation script please allow an option to choose the version of kernel being downloaded & patched?
I am using Debian 12 and the stable repo only has Nvidia drivers till version 525.xx that aren't updated to work with kernel version 6.5.xx, which is what the script downloads currently, so dkms autoinstall fails.
In any case it would be a good option to have :) Apologies if this was not the place to ask for such a thing. Thanks! Back to top |
|||||
I believe I can answer for damentz here:
What you are asking for makes absolutely zero sense. You want to run a non free driver like nvidia using the frozen pool Debian version of that non free driver, and you want to run a liquorix that is that old, and you want to use dkms. This is simply not how you should be doing this, top to bottom. I'll go through the points one by one: 1. Liquorix is by definition a current kernel. Current as in new, reasonably stable current version. As such, it is not supported for the application you are asking for, since older releases, that is, older kernel versions, are not supported. 2. Should you insist on wanting to run liquorix of a previous era, then you add the liquorix repos, install the keyrings, and install the version available, but do NOT install the kernel metapackage. But there is zero guarantee a kernel old enough to work for this scenario will remain available. 3. Learn how to install the direct nvidia *.run driver installer directly, and use the liquorix kernels until the gcc issue makes it non viable, which is probably sometime soon. Basically your request comes down to asking damentz/liquorix to enable something that should not, and probably cannot, be suppoorted, which then suggests agreeing that this is a feature that should be supported. Legacy Liquorix kernels are maintained for a period of time, then are removed, and there is zero obligation to retain them for a specific distro. Note that steven pusser, search the forums here, is maintaining a build of liquorix off and on for MX that will work but will not support your notion of having your cake and eating it too. For frozen pool distributions, the real solution is to not use Liquorix, it's not the right kernel for you, it's to use the distro set of packaged kernels + non free drivers + dkms. Those are designed and maintained to work as such, that's the whole point of using stable releases. Note that you could probably get rid of one of the issues short term, but not long term, by removing the impossible requirement to maintain support for dkms debian nvidia driver package version, but you have to pick your priorities, these are exclusive: * use Debian stable to have a stable environment, with matching kernel and drivers, with dkms handling minor kernel patch version. * use a cutting edge new kernel, until the gcc issue makes it fail because the current Debian Sid/Testing gcc version jumps past the Stable version of gcc, and learn how to install the real nvidia driver from the nvidia sourced .run file, which is a pain, but it's the same exact driver (since it's non free, it has to be the same binary) as the 525 debian nvidia package used. Except you'd be using the current driver, which does support the current kernel release. It sounds to me like you want stable but you don't want stable, and that doesn't work over time. I use Debian Testing, with Liquorix, and have basically no issues, but I don't use the liquorix kernel metapackages, I use the manual install/update when I feel like it method, which also then allows me to roll back to previous kernel when (not if, when) a new kernel makes something not work right. Then I wait a while, and try new ones, until the thing I needed works again. I also dumped nvidia a while back because I was totally sick of the non free driver headaches, and switched to AMD graphics, and now have really no further issues. Use a FREE operating system like Debian with a FREE kernel and FREE kernel drivers and your experience will be much better. Note that nvidia in process of moving most of their non free code into the graphics device hardware firmware, then adding a thin wrapper layer over that, so that a so called 'open source' nvidia driver wrapper layer can be used between the kernel and the firmware can be used. This is obviously a dodgy and shady maneuver, but it falls within the space the kernel guys are willing to accept. This I believe is only Turing and later generations, there will never be a open source driver except nouveau, which is buggy and largely unusable in my opinion, for any older nvidia gpu generations. Judging from the amount of time it's taking nvidia to come out with this 'free' driver, however, it's clearly more difficult than they had first assumed, I had expected their first beta months ago, and there's zero sign of it yet. AMD (or the new Intel GPUs) on graphics is the only solution for now, until the 'open source' Turing and newer driver is part of the kernel tree. Back to top |
|||||
OK understood, it seems this was rather an unreasonable request. My bad, I didn't fully understand dkms and the overall background and jumped the gun.
Anyway, thanks for your patient reply! Back to top |
|||||
It's a common misunderstanding, mistaking the fairly seamless ease of using stable distro + stable distro kernel + stable distro non free driver as a situation where one of those bits can be changed and turned into unstable.
While Stephen Pusser's Liquorix builds for MX won't solve this problem, since he also does not attempt when he makes these to maintain support for legacy Liquorix versions, and obviously not for obsolete nvidia drivers, when he makes these they will handle the GCC issue I believe, though he should confirm that, not me. I am not even sure if he's currently making them, I think he is according to his last posts here. Life is MUCH easier on free operating systems if you use free drivers, trust me. But it will never solve the issue of running current kernels on legacy sets of core software for a distro. Back to top |
|||||
All times are GMT - 8 Hours
|