-
Notifications
You must be signed in to change notification settings - Fork 72
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
Seg fault on fresh 18.04.5 install #59
Comments
Strangely, if I update from Can somebody confirm if this is reproducible on |
Yes I'm getting the same on 18.04.5 running on Arm64.
|
Confirmed seg fault on 18.04.5 both Arm64 4.9.230-76 and AMD64 4.15.0-117.118 |
I think the logic bug is in check_installed: It finds what is installed and prints that out and creates a temp pkern which has is_installed set to true.
|
The next problem is again in check_installed which does not provide a vendor neutral method of determining the installed linux kernels via the package manager. check_install makes a call to the following:
And then a subsequent match for 'linux-image' identifies the correct packages like so :
On Odroid N2 Ubuntu this command returns nothing because the package naming convention is different. On the Ubuntu 18.04.5 for the Arm64 Odroid N2 the linux kernel packages are actually named linux-odroid-n2
So for a vendor independent method a completely different approach will be needed! |
There really is no good reliable vendor-neutral way to tell what kernel packages or versions are installed. There is a function that tries (poorly) to parse a few different kinds of kernel and package version strings which come from a few different sources and which adhere to a few different conventions or naming rules. It's very fragile and only works by luck and only as long as nothing changes. There are really no actual rules that you can count on about what might appear in a version string from apt/dpkg, or a deb filename, or a directory name from the mainline-ppa website. I have a re-write of that I started some time ago and never finished, which splits that up into a few separate parsers that are simpler and more reliable by being more llimited in scope. IE, one just parses package names from dpkg/apt, not filenames, not mainline website directory names, not the output of uname... then another function only parses uname, etc, and whenever a kernel is added to the list of packages and versions, another piece of associated info is the source (did this kernel entry come from the output of apt? or uname? or wget? etc.). And they aren't simple regex's but actual logic to break up the string into sections and make decisions about what they mean based on where it came from and what the other sections of the string contain. If we are going to get wierd new packages that are still "ubuntu", then probably we should move the regexes, or some other way to express some kind of recognition rules, into the config file where it can be a larger list of possible patterns to match, which can be more easily maintained, and which the user can fiddle with themself if needed without compiling. A large part of this will simply always be dumb manual maintenance to keep updating a dumb list of known strings. For instance there was never any way to predict, or any generic pattern or rule that would have allowed for the odroid kernels to be properly recognized when they appeared. There is no such thing as a designated spot in the string where "distribution name goes here" and we can recognize and parse it by some rule like "if there's a dash after 3 dots, then between the dash and the next dot is the distribution name" and by knowing that rule we could recognize any distro without having to match the literal string, and when a new distro shows up, it already works as long as it adhered to the rule... there is no such nice rule like that. There isn't even a rule that there must always be 3 numbers, or the the the version number parts won't still have letters in with them, let alone all the unpredictable free-form junk that comes before the main numbers and after the main numbers which are totally unpredictable except within narrow contexts. By narrow context I mean, If you know a given string came from say, the mainline-ppa website, and you know it was from after some year and before some other year, THEN you can tell how to interpret the string reliably. If you just get the string with no context, you really can't say almost anything about it for sure. You can't even get even the most basic main version numbers for sure, because people put all kinds of dates and git hashes and build numbers and other sorts of revision tags and other stuff in there which are also numbers, and by itself, a 5 is just a 5. A program has no way to know that it is or is not supposed to mean kernel version 5.x.x, because version strings are not database fields with defined meanings. That doesn't mean we can't still have a nice convenient kernel package installer, it just means you can't be suprized and outraged that it isn't magic, and breaks at the slightest new deviation, until the code is updated to handle that specific new string or pattern. That's why I said maybe the best way to deal with it is just make the pattern-matching into a config setting so that it can be fiddled with by the user at run-time when they need to. It's been a while since I last looked at it so i am handwaving a bit, sorry. |
@ bkw777 I had a look as well and spoke to a few other groups and have to agree with you there doesn't seem to be a reliable way to determine what kernel packages are installed. |
I can confirm this bug as well, I am able to reproduce this bug using a fresh install of 18.04.5, any resolution for this? |
Same bug here too. Because I must stay at a stable 4.15.0 kernel, but want to test every now and again with newer until the video card works. For now I can do this manually, but that's a touch painful. |
Is this the same bug I tried reporting? |
I believe this is fixed with d3b91b0 |
Thanks for taking on the project!
I'm getting a seg fault when running
--check
or--install
Here's the gdb output with strace:
Here's the stack:
The text was updated successfully, but these errors were encountered: