Repository navigation
Request for more verbose erroring on bootc container lint #2469
Description
Edit: The issue is a filesystem configuration error on Zirconium's end. I've amended this issue, as the error output from bootc container lint was not at all clear as to which path was causing issues.
The issue here is that bootc container lint, when faced with a path that leads outside of the filesystem, errors out without telling you which path is causing the problem. Adding RUST_LOG=debug or even RUST_LOG=trace does not help here. It's still not verbose enough on this particular step of linting. It would be nice to at least show the path that it errored out on.
Old description text:
I'm running into this on zirconium-hawaii testing images, but I can also reproduce this on images for Zirconium (fedora). Ever since bootc 1.16.11, bootc container lint has been failing with the error error: Linting: Unexpected runtime error running lint runtime-deps: a path led outside of the filesystem. I've attached screenshots with RUST_LOG=debug enabled, but it doesn't seem to provide me any useful information.
I think the problematic commit is 98bc78d. I've tested this on the bottom-most screenshot.
zirconium:latest (Fedora 44), running bootc container lint on commit 98bc78d and 3324be4 respectively.
Activity
hecknt commentedon Sep 16, 2026
Upon further investigation, it seems that the issue is actually with
/usr/localbeing symlinked to../../var/usrlocalin Zirconium. Correcting this symlink to../var/usrlocalallows forbootc container lintto work.I'll change the issue title. I think the error here is very unclear, as even with
RUST_LOG=debugorRUST_LOG=traceit doesn't tell me which path is causing linting to fail. Maybe it could tell you which path leads outside of the filesystem?[-]bootc container lint fails with 'error running lint runtime-deps: a path led outside of the filesystem'[/-][+]Request for more verbose erroring on `bootc container lint`[/+]cgwalters commentedon Sep 17, 2026
Sure, makes sense; in this case I wonder if we're actually following a symlink when we shouldn't? Just needs a
.with_context()here I assumemake relative symlinks for /opt and /usr/local
fix: Include failing paths in container lint errors