[jmarrero-bot]

Follow-up to #2629. bootc 1.16.0–1.16.14 installs onto ext4 made without -O verity now stop in the initramfs, and the only message is "fs-verity is not supported by filesystem". This adds the recovery steps to that error: boot the previous deployment, add ? to the entry (which gives up enforcement), or reinstall onto a filesystem with fs-verity. The text is added only when the command line is strict and measuring fs-verity fails as unsupported.

A second commit documents this in bootc-composefs(7) (a new "Strict boot entries without fs-verity" section: who is affected, the pre-upgrade check, recovery), with small matching fixes to bootc-root-setup.service(5) and the installation guide.

A third commit rewords the bootc install --allow-missing-verity help (and the regenerated install man pages): it adds the ? marker and relaxes the repository policy, but an install onto ext4 created without -O verity still fails with it, as it has since v1.17.0.

The affected set, the recovery testing and the pre-upgrade check are in #2629 (see the summary comment there).

Testing:

• Booted a 1.16.14 to-filesystem install on ext4 without verity, then switched to a build with this commit. The boot fails with the new text, followed by the original error chain.
• A normal strict install on ext4 with verity still boots. This was tested with the commit's first revision, which differs only in the message wording.
• The bootc-initramfs-setup unit tests pass (11).
• The initramfs commit is a clean cherry-pick onto main. Main's tree at 00574d5 is identical to initramfs: Enforce fs-verity for strict composefs boots #2629's tested head c53c2fc.
• Docs commit: rendered through the GitHub markdown API (anchors resolve); the check script is the one from the initramfs: Enforce fs-verity for strict composefs boots #2629 comment. mdbook and the guide man page generation were not run.
• Help-text commit, on a devspace (16 cores): just update-generated produced exactly the committed man pages, just validate (fmt, clippy, docs, generated-file check) and just unit-tests (546 passed) passed on the commit's first wording; the final revision changes only the doc comment and man page text, and was regenerated again with no diff.

The Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com> on these commits was added on jmarrero's approval of the review draft: jmarrero-forge#14 (comment)

Generated-by: https://github.com/jmarrero-bot#llms

[jmarrero-bot]

A question for the team on the third commit (--allow-missing-verity help). It documents today's behavior: an install onto ext4 created without -O verity fails even with the flag. That looks like a side effect rather than a decision.

Since 9ccd87d ("composefs: Enforce boot policy during staged installs", #2248, first in v1.17.0), install creates a strict provisional repository whenever the filesystem type supports fs-verity (provisional_relaxed = !state.composefs_fsverity_supported in install.rs). The flag is only applied after the image is imported, through final_repository_policy, and by then writing meta.json with fs-verity has already failed. 1.16 created the repository relaxed when the flag was given. The type check can't tell ext4 with -O verity from ext4 without it.

Should the provisional repository honor an explicit --allow-missing-verity? That would be a separate PR, and the help would then drop the sentence saying such installs fail. cc @cgwalters, since this is your commit.