bootc should document this process a bit better or provide a more convenient method

See #267 for a more convenient method. We are indeed in a relatively inconsistent situation where e.g. Anaconda allows this, but bootc-image-builder and bootc install don't in any kind of direct way; the above PR helps.

Not everyone will want to adopt ignition to do these tasks.

Yes, agreed.

I gathered there was divergent functionality here and this was not really supported now. What is the present day workaround?

What is going on in your PR with let target_etc = root.open_dir("etc").context("Opening deployment /etc")?;? Are you effectively just grabbing the etc directory of the ostree deployment in sysroot? figured this out for myself.

As for a workaround, should I just dump stuff into <physroot>/ostree/deploy/default/deploy/<hash>/etc/? What I've come up with to use in a script with a filesystem install to get to this location: ostree admin status | head -n 1 | cut -d ' ' -f 3 -

As for a workaround, should I just dump stuff into <physroot>/ostree/deploy/default/deploy/<hash>/etc/? What I've come up with to use in a script with a filesystem install to get to this location: ostree admin status | head -n 1 | cut -d ' ' -f 3 -

ostree admin status --sysroot=<wherever sysroot is mounted> doesn't work right after install as it reports works only if the boot partition is mounted otherwise it reports No deployments. It looks like ostree rev-parse --repo=<wherever sysroot is mounted>/ostree/repo ostree/1/1/0 could work if boot isn't mounted for some reason.

It would be a much more pleasant experience if bootc install subcommands could cleanly output this bit of info. It is present internally.

ostree admin status --sysroot= doesn't work right after install as it reports No deployments.

It's almost certainly because you have a distinct /boot filesystem which isn't mounted, and ostree uses the bootloader configs as source of truth.

ostree admin status --sysroot= doesn't work right after install as it reports No deployments.

It's almost certainly because you have a distinct /boot filesystem which isn't mounted, and ostree uses the bootloader configs as source of truth.

This is exactly what the issue was. The documentation for ostree admin status does not indicate it pulls data from /boot, however. I wrongly presumed it inspected the repository somehow.