pimlie / ubuntu-mainline-kernel.sh

Bash script for Ubuntu (and derivatives) to easily (un)install kernels from the Ubuntu Kernel PPA
868 stars 103 forks source link

Doesn't install the latest version available #87

Closed abcbuck closed 7 months ago

abcbuck commented 9 months ago

If the build of the latest kernel failed, the kernel isn't updated at all, instead of being updated to the latest kernel for which the build succeeded.

pimlie commented 7 months ago

instead of being updated to the latest kernel for which the build succeeded

I'm sorry but this will be a wont-fix. There is no way to easily check which kernel version was the last version for which a build was successful, besides that it's often better to just wait a couple of days/weeks until the Ubuntu kernel team has fixed the kernel builds. And if you really cannot wait, you can just check which version was successful yourself quite quickly :)

abcbuck commented 7 months ago

It depends. I had bought a new notebook and have relatively little experience with Linux. Mouse and keyboard didn't work from the outset, and after a lot of research I found that updating to the newest kernel would fix the issue. Barely knowing anything about Linux, I was happy to find someone link to your script to do the work. However, when it just didn't want to work, not knowing what else to do, I had to read through your script to find out where it went wrong, so I could set it to update to the last working version instead. A script that worked as I expected it to work would have saved me a lot of time.

Also, I disagree with the difficulty of checking the latest functional version. Just go from the latest and check backwards iteratively. If you have a good sense of bash scripting, which is certainly better than mine, the main difficulty is to understand the structure of the current script, and there's no one better suited to this task than you.

So, given the impact on users who stumble upon your script to fix serious hardware issues, and the low conceptual difficulty to fix the problem, I don't see the reason to discard this issue so easily.

pimlie commented 7 months ago

Ah ok, thanks I understand your concerns better now.

There have been times in the past where like the last 10 versions didn't build correctly, and I feel that having to iterate 10 times to find a proper build is not something we should do for each individual user of the script.

Maybe we could improve the error message, maybe point to a discussion 'Kernel build status reports' or something on this repo that explains how to check which build was successful and where maybe users can also report themselves which build is still ok. Wdyt?

abcbuck commented 7 months ago

Changing the error message to point to a guide to manually check the latest version would be a quick fix I would go with if you don't have a lot of time on your hands. (I certainly don't. Maybe in a month or two.)

But I like to automate everything I can, so now it gets a bit technical.

I had thought of the issue with too many failed versions as well, and thought you could stop at the tenth try and then refer to manual help. This would be better if you want a quick way to get the latest built version.

Ideally, you could cache the latest version for each architecture to prevent excessive traffic. Kind of like the build status report site you suggest but automatically, though I don't know if this is technically possible.

(I would want to create a file 'latest-versions' in your root directory that contains a string of the latest version for each architecture paired with the date the latest version for that architecture was last checked or a single date on which all the architectures were checked for their latest version. You could then access this file at https://raw.githubusercontent.com/pimlie/ubuntu-mainline-kernel.sh/master/latest-versions and compare the respective date to the list on https://kernel.ubuntu.com/mainline/ to see if there are any newer versions to regularly update 'latest-versions', and had a list for quick access your script could make use of. However, this might just be me going for full optimization and isn't mandatory if you don't share this fervor.)

Most important to me is new users can find quick help to fix their machines when they have to. All of these solutions are fine, depending on how much time you want to put in to improve the user experience.

pimlie commented 7 months ago

Although I applaud & appreciate your need for automation, I feel that adding a latest-versions file would add way too much complexity for the service this script is providing. And I'm talking not even about the technical/coding part, but mainly about maintaining that file.

Also if we would add that then the next request is gonna be about keeping track which Ubuntu release has which library discrepancies with which kernels which might prevent a user from building (dkms) modules from source. And after that we will get a request if we can store pre-built deb files for kernel versions with mismatches libraries. And before we know management of what works with what takes over all the work required for this script and we are maintaining a second mainline kernel ppa next to Ubuntu's.

So I feel it's just better to not go in that direction at all. The goal of this script is to quickly install kernels from the mainline kernel ppa which 95+% of the time works correctly and does not list any build failures. The script has some features to help you choose which version to install, but the script is not aimed at being a kernel version compatibility tool. But as said, I'm happy to try to elevate some concerns by referencing a github ticket/discussion about that :)

abcbuck commented 7 months ago

Yes, I was worried about the maintaining as well. I had hoped GitHub had an easy way to deal with this but I'm rather new, so I'd have to look into the details and check if there's anything like what I had mind. A reference as you say will do.

Your inflated, though humorous, apprehensions aside however, I still think the script should give the option to force a check for the latest functional version on the machine the script runs on, even if it takes a few more than ten site requests that otherwise would be done manually. I hope you don't mind if I unbury this issue in a few months to give it a try. :)