[RESOLVED] Kernel Version Mismatch
kernel
Status: New User - Welcome
Joined: 05 Nov 2021
Posts: 1
Reply Quote
There appears to be a version mismatch with packages as of 2 days ago. I'm surprised this hasn't come up yet so is it possible I'm misreading it?

Package: linux-headers-5.14.0-16.4-liquorix-amd64
Source: linux-liquorix
Version: 5.14-21.1~bullseye

The above holds true for all available packages:
https://liquorix.net/debian/dists/bullseye/main/binary-amd64/Packages

Assuming there is indeed an issue here I'd appreciate any suggestions you might have as to how I can temporarily install an operable image/headers pairing. I started down the path of editing the debs but realized hashes would conflict and likely cause more problems than I'm trying to workaround.

Thanks!
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1126
Reply Quote
Hmm, what's the error you get when you try to install? I just upgraded a bullseye system a few minutes ago to verify and apt-get didn't have any problems.

EDIT: Worst case, I can just bump the version and have everything rebuild. Nothing has changed in the build process for probably about a year.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1126
Reply Quote
I pushed out a binary rebuild, can you try again?
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1126
Reply Quote
Ok, well considering there may have been no issue here in the first place, I'll just mark this thread as resolved.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
there was no issue, I hadn't done an apt-get update for a while, and tested apt-cache policy on your kernels and the versions were fine. Updated, and they were still fine, headers/image version numbers the same. Unless it was a sid only thing, don't know.

I suspect strongly that the person made the standard mistake of believing a package number is identical to a kernel version number, I had a hard time explaining that to some users once, they actually believed a package number has actual information in it beyond packaging data.

In other words:
:: Code ::
Package: linux-headers-5.14.0-16.4-liquorix-amd64
Source: linux-liquorix
Version: 5.14-21.1~bullseye

with this fundamental misunderstanding of package version numbers yields:
:: Code ::
5.14.0-16.4 != 5.14-21.1

with the then classic logic error of concluding that A and B are the same number, so if A and B are not equal, there is a version mismatch. Classic logic error, equivalent to: A is a cat, B is a fish, A and B are animals, A does not like water, therefore Animals do not like water.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1126
Reply Quote
Ah, thanks for the clarification. I was assuming some other larger issue with source package hash mismatches was the real problem. In this case, there was no issue, it was just PEBKAC and misunderstanding that package version and software version are not the same thing.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
damentz, I had to spend some time on this issue because a guy insisted I could get version numbers of kernels from the package number for inxi, but he didn't grasp that a package number has no necessary relationship to the program/software version number. This grows obvious on stable branch kernel version vs package numbers, but a package number is just a number that tells the package manager via some predetermined syntax that there is a newer package in the package pool and to update it. While I don't remember the precedence of events, debian at one point had kernel package numbers that were quite similar to kernel numbers, but at another point, they had essentially no relation at all. I had to dig up all this info to convince the guy that no, in fact, a dsitro package numbers is NOT an acceptable source for a kernel version number.

I actually had to look at the guys output example here a few times because I didn't notice it was the package number, and I was like, wait, that kernel version is way ahead of the current one, lol. Then I remembered, right, he's posting package number as if it has some logical connection to the kernel version, of course the package number doesn't correspond, it has nothing to do with the kernel version number beyond an arbitrary decision to somewhat make parts of the package number match the kernel version.

Technically there's a class of error that is somewhat frustrating, and that's when it takes the user FAR less time to just try installing the darned thingi and see if it works than it does to post an issue about it, with the benefit that if an actual problem existed, you could then post the error output from in this case apt which would make it easy to figure out.
Back to top
Display posts from previous:   

All times are GMT - 8 Hours