Request for more verbose erroring on `bootc container lint`

[hecknt]

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.

[hecknt]

Upon further investigation, it seems that the issue is actually with /usr/local being symlinked to ../../var/usrlocal in Zirconium. Correcting this symlink to ../var/usrlocal allows for bootc container lint to work.

I'll change the issue title. I think the error here is very unclear, as even with RUST_LOG=debug or RUST_LOG=trace it doesn't tell me which path is causing linting to fail. Maybe it could tell you which path leads outside of the filesystem?

[cgwalters]

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 assume