Add support for mounting upper layers with images#303
Conversation
alexlarsson
force-pushed
the
support-upper
branch
from
65e9e21 to
4f1ed9d
Compare
|
I was chatting a bit with some people at the embedded recipes conf about using composefs without bootc (for a bit custom stuff) and they would need this to be able to couple composefs images with one or more writable layers. |
Johan-Liebert1
left a comment
Johan-Liebert1
left a comment
There was a problem hiding this comment.
Some minor suggestions :)
alexlarsson
force-pushed
the
support-upper
branch
2 times, most recently
from
98425d8 to
0eead6a
Compare
|
Also, I didn't look at it in detail, but I think composefs-setup-root could use this instead of manually doing the overlayfs mount. |
|
I don't remember well, but I think the "non initramfs" part of |
alexlarsson
force-pushed
the
support-upper
branch
from
0eead6a to
2891abb
Compare
|
We have a reverse dependency issue in bootc, where it needs to pass composefs::mount::NO_OVERLAY to mount. What is our current API stability guarantees here? Do i add a new mount_with_overlay() for this, or do we just fix bootc later? |
This is useful from the cli if you want to add a writable layer to a composefs mount. This is better than doing it in a separate overlayfs layer as that would increase the overlayfs stacking depth, etc. Note: This adds the overlay option as a separate mount_with_overlay() as currently bootc calls repo.mount() which breaks API. We don't seem to have any callers of repo.mount_at() so the overlay option can be added there. Signed-off-by: Alexander Larsson <alexl@redhat.com>
Without this i got this in the CI:
```
error: function `verity_opt` is never used
--> crates/composefs-ctl/src/lib.rs:659:4
659 | fn verity_opt<ObjectID>(opt: &Option<String>) -> Result<Option<ObjectID>>
| ^^^^^^^^^^
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[expect(dead_code)]` or `#[allow(dead_code)]`
```
Signed-off-by: Alexander Larsson <alexl@redhat.com>
alexlarsson
force-pushed
the
support-upper
branch
from
2891abb to
7c01911
Compare
|
Seems easiest to go with mount_with_overlay(), so i added that. |
|
I have no idea what this failure is about: |
Would it help for us to support building bootc without the ostree dep? I would like to be able to do that. |
I think We can break API at any point, but it's also useful to have a bit of backpressure to avoid doing so unnecessarily. On the counterpoint, #225 does break API and in that PR I pointed the bootc revdep CI at a patch to adapt bootc to it. |
Nah, this was for "Flipper one" and the requirement they had was quite custom, focusing on allowing users to tweak and break their systems. I don't think it will ever be a good fit for bootc. |
It's likely bootc-dev/bcvk#153 - a rerun made it pass. |
cgwalters
left a comment
cgwalters
left a comment
There was a problem hiding this comment.
Looks sane to me, but I would really like to build up the pattern of having integration tests again because I think they're easy to add.
| } | ||
|
|
||
| /// Convenience constant for passing no overlay options to [`composefs_fsmount()`]. | ||
| pub const NO_OVERLAY: Option<OverlayOptions<OwnedFd, OwnedFd>> = None; |
There was a problem hiding this comment.
This can be an associated const ref https://docs.rs/gio/latest/gio/struct.Cancellable.html#associatedconstant.NONE
| )?) | ||
| } | ||
|
|
||
| /// Options for adding a writable overlay layer to a composefs mount. |
There was a problem hiding this comment.
There's more possible options here - volatile is a big one!
I'm not saying we need to do that now, but we could make this #[non_exhaustive] to allow us to more easily add more options later.
Or we could just support pub options: Option<&'str>
3 participants
This is useful from the cli if you want to add a writable layer to a composefs mount. This is better than doing it in a separate overlayfs layer as that would increase the overlayfs stacking depth, etc.