[Error] Kali Distrobox does not allow to enter due to missing apt package in their repositories

[almereyda]

Describe the bug

When entering a Kali container, this rolling release based on Debian testing¹ may not bring all packages that are going to be installed during distrobox-init and fails to start.

Here it is a Desktop dependency on libgl1-mesa-glx, but could as well be any other.

To Reproduce

distrobox create --image docker.io/kalilinux/kali-rolling:latest --name kali
distrobox enter kali

Installing basic packages...           	Error: An error occurred

Expected behavior

A shell is opened in a Kali environment.

Logs

Reading package lists...
Building dependency tree...
Reading state information...
Package libgl1-mesa-glx is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libgl1-mesa-glx' has no installation candidate
+ [ 100 -ne 0 ]
Error: An error occurred
+ printf Error: An error occurred\n

Desktop (please complete the following information):

• Which version of podman? 4.6.2
• Which version of distrobox? 1.5.0.2
• Which host distribution? Fedora 38
• How did you install distrobox? dnf install distrobox

Additional context

The issue is also described in:

¹ https://www.reddit.com/r/linux/comments/16u73fx/dependency_issue_libgl1mesaglx/

---

Asides from the fact that this could have happened to any package in the dependencies list:

Maybe this occurrence is an invitation to consider CLI-only distroboxes, which explicitly do not bring the graphic/desktop related dependencies?

distrobox create --console, for example, could use a more minimal distrobox-init with less package dependencies on graphics support (Mesa, Vulkan, NVidia), which also decreases first-run boot up time.

[thedeadliestcatch]

Seconded. As a workaround, use kalilinux/kali-last-release.

[almereyda]

The workaround image fails with:

+ apt-get install -y libegl1-mesa libgl1-mesa-glx
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libegl1-mesa
+ [ 100 -ne 0 ]
+ printf Error: An error occurred\n
Error: An error occurred

Avoiding to install graphical dependencies, and having a toggle for switching between the graphical use case and console containers, promises to ease the observed edge case of a distribution not bringing all packages within its package repositories that are expected by default from distrobox-init.

[guss77]

The problem appears to be that the apt-get section of distrobox-init uses apt-cache show to check if a package is available for installation and only installs it if apt-cache show returns 0 - but apt-cache show, at least with recent apt versions, will return 0 for "purely virtual" packages that cannot actually be installed:

# apt-cache show libgl1-mesa-glx  
N: Can't select versions from package 'libgl1-mesa-glx' as it is purely virtual
N: No packages found
# echo $?
0
# apt-get install libgl1-mesa-glx
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package libgl1-mesa-glx is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libgl1-mesa-glx' has no installation candidate
# echo $?
100

Unfortunately, apt-cache show doesn't have any flags to tell it to error out in these cases (N: No packages found is not an error, its a "notice", therefor you don't get an error result. If you try to show a package that "really doesn't exist" you get E: No packages found which does return an error result).

I don't think that apt-cache show is the correct way to check if a package is installable. The correct way is to use apt-cache policy and check if there's a "Candidate" version - i.e. the value for "Candidate" is not (none). This script snippet would work:

apt-cache policy "${dep}" | grep Candidate | grep -qv none

Unfortunately there're no apt-cache flags to ask apt-cache to have a reliable exit code, so we must parse the input.

With the above change, distrobox enter works for me.

[almereyda]

You mean you replaced

distrobox/distrobox-init

Line 580 in bf65e62

if apt-cache show "${dep}" | grep -q Package; then

with

- 			if apt-cache show "${dep}" | grep -q Package; then
+ 			if apt-cache policy "${dep}" | grep Candidate | grep -qv none; then

and that was all that was needed to circumvent this error?

[guss77]

You mean you replaced

- 			if apt-cache show "${dep}" | grep -q Package; then
+ 			if apt-cache policy "${dep}" | grep Candidate | grep -qv none; then

I was looking at version 1.5.0.2 in this repository, where my change looks like this:

- 			if apt-cache show "${dep}" > /dev/null; then
+ 			if apt-cache policy "${dep}" | grep Candidate | grep -qv none; then

The code you quoted is from the main branch, where the grep -q Package code was a recent commit that I believe is trying to fix the same issue(*), and from cursory examination, it should also fail correctly when encountering virtual packages, so if that's how your code looks in your system - then it is likely that my issue is different than what you are talking about.

My issue isn't on Kali, but actually on ubuntu:23.10, which is where the command line output I showed above is taken from.

*) I think using apt-cache show is not the correct way to check availability, and specifically searching for the arbitrary text "Package" in the output of a command that has many different error messages, is error prone. The correct way is to use the apt-cache policy command that has fixed output and no arbitrary error messages (it actually can be counted on to never return an error exit code for input that does not start with -).

and that was all that was needed to circumvent this error?

Yes... I mean that there was no error anymore and distrobox enter succeeded. What this change doesn't do, is to fix the package installation - instead of erroring out, the package in question just does not get installed, which i believe is what the relevant code in distrobox-init is trying to do: check if the package is available and only install available packages from the provided list.

[guss77]

@almereyda I have verified that my change, on top of 1.5.0.2 fixes the issue for kali-rolling:latest and also that the current main code also fixes that issue (though, for reasons I noted above, I think that code is incorrect and should be replaced). Without either of these changes, I get the error that you reported.

[almereyda]

Thank you for the verification.

The commit d0db8d9 that introduces this change is not tied to any issue or PR, and it doesn't provide much more detail on the rationale behind it.

And thanks for offering #1036.

I'm curious about @89luca89 opinion on the matter.

[almereyda]

I have confirmed both d0db8d9 and #1036, through monkey patching of the 1.5.0.2 installed /usr/bin/distrobox-init, to resolve the limitation described in this issue. As the commit fixes the regression and is already part of the next release, we can close here.

The PR still makes a notable proposal, from what I can tell.