I'm running SolydK (Debian Bookworm, KDEPlasma 5.27.5) and I'm trying to add the Liquorix kernel to my system but I'm getting the following error.

I'm seeing threads with similar errors, but I don't see how to resolve them so I can install one of the kernels.
Back to top

Yep, Solyd(X)K is lying what it is. From a VM, here's the output from doing an apt-get update and printing os-release:



If this was an Ubuntu distribution, it would be completely unusable. The add-apt-repository utility will fail because there's no Ubuntu release called "SolydXK". The VERSION_CODENAME value is reserved for the upstream distribution, not for downstream to play with.

There's actually no way to support this without hardcoding in support for your distribution. Your best bet is letting your distribution know that this is not supportable and they need to put in the os-release file that they're actually Debian Bookworm with customizations on top.

In the meantime, you can open /etc/apt/sources.list.d/liquorix.list and replace SolydXK with bookworm and it should work fine.

I'll mark this as resolved as hardcoding distributions that play with os-release incorrectly are unsupportable, but the workaround is straight forward.
Back to top

You've hit the problem with a badly designed 'new' specification (/etc/os-release) made by a Redhat corporation employee who simply failed to grasp that there are actual derived distros, thus, os-release spec is totally missing stuff like SYSTEM_BASE, SYSTEM_BASE_RELEASE, SYSTEM_BASE_VERSION, which then forces distros to make up random stuff to try to ID themselves.

This isn't actually a derived distro bug, it's a core bug in the os-release specs, since there is literally no good solution to this problem. Ubuntu made up a proprietary key=value pair to handle part of this, but that's not part of the core spec.

inxi has to have a massive distro ID and system base ID section to handle all the random ways distros find to identify themselves when they are either spins or derived.

Yet another subtle bit of damage Poettering did before moving on to Microsoft, since he was handed the job of making this spec if I remember right, which was insane since he's notorious for not listening to user feedback.

damentiz is right however, if the distro does not make itself readily identifiable in terms of its system base (what a derived distro is made out of), then it's very difficult to support unless you have the type of distro ID engine that inxi has, which nobody in their right mind should try to do for a simple installer tool or whatever.
Back to top

Ok, so I thought about it some more and found a way to determine the underlying version of Debian. In the apt-cache policy output, something sticks out; the organization is defined with o=<org>. Here's example output below:



Testing a few distributions (including Ubuntu spins), using O=Debian or O=Ubuntu lets me identify the real system below. Then sampling the most common occurrence in n=<release> gets the real distribution release.

Here's an example command you can run to verify what you are really running: apt-cache policy | grep o=Debian | grep -Po 'n=\w+' | cut -f2 -d= | sort | uniq -c | sort | tail -n1 | awk '{print $2}'.

It's a long command but works every time. We're basically filtering down to all Debian lines, then cutting out the release name, and then counting occurrences and choosing the most common.

jmhardin, can you try the install script again on the website? It should install. I also verified through a SolydXK VM that this correctly now installs the correct release.
Back to top

damentz, that's an excellent find. And you can trip the case to run that test if /etc/debian_version is present. I believe that file is in all debian and derived distros. Let me do some quick checks on some of the worst offenders, like deepin.

[update]As suspected, while detecting /etc/debian_version works on deepin, the policy test fails because the Chinese pretend that this is not Debian. However, Deepin is the very worst offender I know of in the Debian derived set of distros.

blankon also doesn't work, just shows blankon in apt-cache policy.

I believe it will work on virtually all others however, let me spin up a few more vms to verify this.

So it's not 100% because distros if they host all the packages will show their own distro name, but honestly, you don't want to support those anyway since who knows what they have done under the covers.

I'd say this is a solid test, basically if the distro has ubuntu or debian sources, with a recognized release name or pool, you can support it, and I would suggest a followup test, if /etc/debian_version and debian/ubuntu not detected, don't support that distro. Let me check how mint fares there.

Note: inxi now has a distro data debugger, --dbg 66 which prints out the contents of all known possible distro files in /etc, making debugging/testing quite easy.
Back to top

Yep, I agree with you on if this information is missing, not supporting the distribution is really my only option.

The reason why is if the core packages are not supported by Debian upstream, there's no way without inspecting the system to know what kernel to give them. In-fact, we'd probably need to a build a kernel for their distribution to guarantee it works. Or in otherwords, without the base distro in apt-cache policy, even if we could determine what they may be based on, there could be no compatible kernel.

As for debian_version, I remember looking at that but I'll have to support a map from number to name, like 12 -> bookworm. I'm not too interested in that since there's the inevitable lapse in support where the number doesn't exist in the map and someone's install fails.
Back to top

Partly because of this discussion, for the new inxi 3.3.34, I slightly upgraded some of the mentioned worst offenders, blankon, deepin. One thing I changed was to use /etc/debian_version to show which system base Debian it was sourced from.

This goes along with what you are saying, what I found in my test vms, which span back 10 years or more, was that an old Deeping showed as my old default:

Distro: Deepin 14.0 base: Debian testing/sid

But when I checked debian_version it was I think stretch or something, that is, an ancient testing/sid setup.

For inxi's purposes, which already has ubuntu and debian release codename/version number matching tables (matches based on the input, if text, get version nu, if numeric, get codename) this can be helpful, but this is ONLY to show the reasonable assumption of what the system base actually was when the distro was built, or what it is now if upgraded.

Absolutely do NOT go down this road yourself for liquorix, truly the only distros that will do this are ones that are so unreliable and who have chosen to pretend they are not really debian based at all by forking the entire package pool and then saying it's theirs. Not many distros do this, and the ones that do, should by no means be supported since that is truly impossible.

On the bright side, simply by exiting with unsupported error you remove any support questions.

Note this is also why seeing inxi -bxz is important, it will reveal any such nonsense right away, actually asking for -bx is a sort of secret way to get them to show you their distro and system base, along with some other important info. You'll recall derived distro users often try to pretend they are using the system base, not the derived distro. Or they 'forget' to mention that when reporting problems to you.
Back to top