ostreedev
sysroot: Support for directories instead of symbolic links in boot part
Allow manipulating and updating /boot/loader entries under a normal directory, as well as using symbolic links.
For directories this uses renameat2 to do atomic swap of the loader directory in the boot partition. It fallsback to non-atomic rename. This stays atomic on filesystems supporting links but also provide a non-atomic behavior when filesystem does not provide any atomic alternative.
/boot/loader as a normal directory is needed by systemd-boot support, and can be stored under the EFI ESP vfat partition.
Tests were duplicated for simplicity reasons.
Based on the original implementation done by Valentin David [1].
[1] https://github.com/ostreedev/ostree/pull/1967
Hi @igoropaniuk. Thanks for your PR.
I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
![openshift-ci[bot] avatar](https://avatars.githubusercontent.com/in/91280?v=4 "Published by a pub.dev verified publisher"){kind=small}
This is based on the initial work done in the https://github.com/ostreedev/ostree/pull/1967 PR (looks like it stalled) I'll push adjusted tests soon to cover this change.
Thanks so much for picking this back up!! I am very interested in systemd-boot support. But this is just one part of the picture as far as BLS type 1 spec.
Note that that spec added the srel file which I think we should use to dispatch on.
IOW if we find that file, it is an error if /boot/loader is a symlink. We should encourage installers to create that to signal compatibility (after this patch lands).
This is a tangentially related topic but I'd like to ask you: Have you investigated https://github.com/containers/bootc/ ? That's where most of my development work today is going. I will continue to help maintain ostree (and bootc hard depends on it today) but medium term I do plan to slowly sever that dependency (as we head towards composefs in particular, xref https://github.com/containers/composefs-rs/ for some cool PoC work). And especially that would mean here that we may end up doing BLS and UKI support in Rust in bootc, not here.
@igoropaniuk Based on your contributions I'd like to offer you reviewer-level access to ostree. This would mean both the right and some responsibility to review/merge PRs made by others.
@cgwalters
@igoropaniuk Based on your contributions I'd like to offer you reviewer-level access to ostree. This would mean both the right and some responsibility to review/merge PRs made by others.
Sounds great, I will be happy to help with reviews!
This is a tangentially related topic but I'd like to ask you: Have you investigated https://github.com/containers/bootc/ ? That's where most of my development work today is going. I will continue to help maintain ostree (and bootc hard depends on it today) but medium term I do plan to slowly sever that dependency (as we head towards composefs in particular, xref https://github.com/containers/composefs-rs/ for some cool PoC work). And especially that would mean here that we may end up doing BLS and UKI support in Rust in bootc, not here.
Actually I had, but our existing OTA solution is based on Uptane (Aktualizr fork as a client) + OSTree, so my primary focus is on this software stack for now.
@cgwalters I've added additional commit for entries.srel support, let me know if you prefer to have everything in one commit (will squash them if needed)
@cgwalters I've added additional tests to cover proposed changes.
Let me know if there is anything else for me to do in the scope of this change
@cgwalters gentle ping, let me know if there is anything else for me to do
@cgwalters Thank you for your review. I have addressed all your recently posted comments. Please let me know if there's anything else I need to do.
I pushed a rebased version of this to https://github.com/cgwalters/ostree/pull/new/symlinks-directories-support - I think I resolved the conflicts OK, but there's definitely some stuff here I want to look at more closely.
I'd like to bring my issues with #1967 here:
I've thought about this several times as I would really like to have this in Endless to support our systemd-boot systems. What always makes me anxious is trying to figure out how to handle compatibility with the vast majority of our systems that have symlink based deployments. There are 2 main issues I'm concerned with:
- The semantics of the deployment are different if loader is a symlink to a loader.N directory versus loader itself being a directory. What do the swapped loader.N directories mean in pure directory mode? I think the answer is that they don't really match the semantics of the symlink deployment. It's essentially a different algorithm even though it's seemingly only a small change from the symlink approach.
- What do you do with systems that already have symlink based deployments? Potentially you could write a migration to the directory scheme, but that means you can't roll back to a system with a libostree that doesn't understand the directory scheme.
So, to me this requires a couple additional pieces of implementation and policy.
- The directory deployment scheme is treated separately from the symlink deployment scheme. Your system can be in one scheme or the other, but the semantics are different and shouldn't be mixed.
- If your system is already using a symlink based deployment, it should stay that way. You can opt in to a migration to the directory scheme, but this means you may potentially lose roll back targets. At Endless we'd do that at some major version check point and probably have to delete some old deployments to ensure users didn't try to roll back to a system where they'd be screwed. Or maybe we'd never migrate anyone because the downsides are too great.
- If you're on a new deployment (i.e., no existing /boot/loader or /boot/ostree), then the directory scheme is preferred.
Does this PR consider any of these points?
Looking at the PR I would say
So, to me this requires a couple additional pieces of implementation and policy.
* The directory deployment scheme is treated separately from the symlink deployment scheme. Your system can be in one scheme or the other, but the semantics are different and shouldn't be mixed.
yes
* If your system is already using a symlink based deployment, it should stay that way. You can opt in to a migration to the directory scheme, but this means you may potentially lose roll back targets. At Endless we'd do that at some major version check point and probably have to delete some old deployments to ensure users didn't try to roll back to a system where they'd be screwed. Or maybe we'd never migrate anyone because the downsides are too great.
yes (entries.srel containing "type1\n")
* If you're on a new deployment (i.e., no existing /boot/loader or /boot/ostree), then the directory scheme is preferred.
No, and this prevent downgrade, so at first I would personally prefer to use directories only when required (/boot is vfat)