-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
failed to scan all layer contents: rhel: unable to create a mappingFile object #1698
Comments
Might be in a way link to the following commit :
|
Because we don't know anything about the image when we index it, all the (configured) scanners are run on every layer, hence why the rhel specific scanning is running. The PR that holds the commit mentioned was to avert a panic in the above situation and instead surface. Since then we've changed the instantiation of a number of components and this should be non-issue going forward (quay/claircore#867) as the ingesting of the files should be a lot more infrequent. |
This should be fixed in 4.7 |
I think this may still be an issue when running in airgapped mode. I am seeing this error nearly constantly in a new instance running behind a firewall. I have followed https://quay.github.io/clair/concepts/updatersandairgap.html to turn on the relevant config settings. EDIT: I think it's essentially quay/claircore#525, but the current error message is unclear. After implementing the fix from redhat's docs with a local file, I now get "rhcc: unable to create a mappingFile object" instead of "rhel: unable to create a mappingFile object", but at a lower frequency. EDIT2: It's because I also needed indexer.scanner.package.rhel_containerscanner.name2repos_mapping_file set. |
Hey @IsaacVaughn sounds like the issue is straightened out, is there something specific that could be added to the docs that would have made it less painful? |
Description of Problem / Feature Request
Since upgrading to Clair 4.6.0, we're sometimes seeing the indexing error
failed to scan all layer contents: rhel: unable to create a mappingFile object
pop up at random. This is not reproducible. Upon deleting the index report and indexing again, the error does not show up again.One of the images in question that this happened on is
index.docker.io/curlimages/curl@sha256:17468885fb8a20cd6bc25316f8267492c4d758ba63a6838ce74b9a0ffe4d2e90
(the amd64 variant of the image index tagged aslatest
as of the time of this writing), so I recommend to use this image for testing. We only saw theunable to create a mappingFile object
in one of our regional deployments (out of 15 regions), so that demonstrates the stochastic nature of the issue.Expected Outcome
Indexing should not fail.
Actual Outcome
After deleting this index report and reindexing, we get the following index report:
What is funny to me is that this is apparently an Alpine image, but the error indicates that it's related to rhel-specific code.
Environment
uname -a
):Linux clair-indexer-64cd54fcb7-9dbzz 5.15.89-flatcar #1 SMP Wed Feb 15 18:00:42 -00 2023 x86_64 x86_64 x86_64 GNU/Linux
kubectl version
): 1.25.6The text was updated successfully, but these errors were encountered: