Spurious chgrp/chmod 'cannot access' warnings for non-existent /usr/lib/ostree-boot paths

[daniel-g-carrasco]

Summary

When rechunk runs on a bootc image that doesn't ship grub2 boot assets (no /usr/lib/ostree-boot/efi/EFI/, no /usr/lib/ostree-boot/grub2/fonts/, etc.), the action prints these on stderr but proceeds OK:

chgrp: cannot access '998': No such file or directory
chmod: cannot access './usr/lib/ostree-boot/efi/EFI/BOOT': No such file or directory
chmod: cannot access './usr/lib/ostree-boot/efi/EFI/fedora': No such file or directory
chmod: cannot access './usr/lib/ostree-boot/efi/EFI': No such file or directory
chmod: cannot access './usr/lib/ostree-boot/grub2/fonts': No such file or directory
chmod: cannot access './usr/lib/ostree-boot/grub2': No such file or directory

The action exits successfully and the published image is correct (verified on ghcr.io/daniel-g-carrasco/margine:stable), so this is log noise, not a functional bug. But it confuses build-log triage — every audit treats those lines as red until confirming.

Suggested fix

Two non-invasive options:

1. Pre-check with [ -e <path> ] before each chgrp/chmod call, skip silently if missing.
2. Pass -f (force, don't print errors) to chgrp/chmod. Less surgical but one-line.

Either way, downstream rechunk consumers don't have to special-case "is this a grub2-bearing image".

Reference

• Margine rechunk output: https://github.com/daniel-g-carrasco/margine-image/actions/runs/27048344027
• Audit-driven log triage that surfaced this: audit: status delta 2026-06-06 + upstream-inspirations review bump daniel-g-carrasco/margine-fedora-atomic#19 (comment)

Happy to send a PR if a fix direction is confirmed.

[antheas]

Make the failures silent. It's ok to send a PR