Replies: 8 comments 5 replies
-
@masahiro331 Can you please look into it? |
Beta Was this translation helpful? Give feedback.
-
An update - I can resolve the scanning of the bespoke/derivative AMI by running the following prior to building the AMI:
I don't understand why journal log file(s) would cause Trivy scans to fail though. It seems worrisome that someone could craft a special log message (or messages) that causes subsequent Trivy scans to not detect any OS packages (and therefore detect no vulnerabilities). |
Beta Was this translation helpful? Give feedback.
-
Am concerned about this too. @masahiro331 @knqyf263 can you create an issue on this? |
Beta Was this translation helpful? Give feedback.
-
Sorry for the delay. I'll investigate. |
Beta Was this translation helpful? Give feedback.
-
@aleliaert @tmay-dg The library I'm using doesn't support this, so I need to modify it, but I haven't been able to reproduce this Binary data. It looks like it will take some time to fix it. |
Beta Was this translation helpful? Give feedback.
-
Hello, just wondering if there is any sort of update on this issue? |
Beta Was this translation helpful? Give feedback.
-
@masahiro331 - I thought the INODE problem was fixed in the go-xfs module when we first starting working with AL2023 - I remember working with you on that problem. did we have a regression on this? this issue renders the AMI image scan for AL2 and AL2023 useless. |
Beta Was this translation helpful? Give feedback.
-
Possibly overlooked something - Trivy seems to be puking on the docker virtual block device 2024-10-27T12:24:37.131Z WARN Partition error: filesystem walk error: fs.Walk error: read directory /var/lib/docker/volumes/backingFsBlockDev: failed to list directory entries inode: 8699708: failed to list entries: not found entries looks like there is another thread with this same problem - #7071 |
Beta Was this translation helpful? Give feedback.
-
Description
We are receiving a strange
unsupported attribute fork error
on a Trivy scan of an AL2 AMI. I am creating a new AMI from a base AMI. I can scan the base AMI just fine, but when the new AMI is created it can no longer be scanned. There were no changes from the base AMI to the new AMI - other than spinning up an EC2 instance from the base and creating a new AMI from that.Here is the full error that we receive:
You may notice the DB is older in the output above - I have tried with the latest DB and have also run the scans with Trivy 0.49.1 - neither help with the issue. I am unsure how simply creating a new AMI from an existing AMI (with zero changes) could cause the scans to suddenly stop working.
Desired Behavior
I expected the bespoke/derivative AMI to be successfully scanned.
Actual Behavior
The bespoke/derivative AMI cannot be scanned.
Reproduction Steps
Target
Virtual Machine Image
Scanner
Vulnerability
Output Format
JSON
Mode
Standalone
Debug Output
Operating System
Amazon Linux 2
Version
Checklist
trivy image --reset
Beta Was this translation helpful? Give feedback.
All reactions