containers
Investigate alignment/intersection with systemd-repart
Let's look at systemd repart and our intersections with it.
A big picture overall thing here is that bootc install defaults to having one rootfs and inherently can work on top of any filesystem or block storage. A key thing is that the operating system size is dynamic, not a fixed partition A/B setup.
systemd-repart is definitely oriented towards DDIs and the discoverable partition spec and less so to this path, but it is obviously very general.
I think a baseline pattern that would be neat to support is injecting repart configs into the base container image to define a distinct /var partition.
A great first target would be e.g. initializing EBS instance store volumes in AWS, or the NTFS partition in Azure.
(Note, it looks like the service is designed to run from the initrd, so we'll want to document either regenerating or more ideally appending to the initrd)
I was thinking about this one more in the context of https://github.com/bootc-dev/bootc/pull/1314#discussion_r2086652274
If a base image chooses to include content in /usr/lib/repart.d, I think we should probably use it by default for to-disk. We could also support --repart-dir to allow embedding e.g. /usr/lib/exampleos/repart-liveos.d or so for alternative partition layouts.
If a base image chooses to include content in
/usr/lib/repart.d, I think we should probably use it by default forto-disk.
Just keep in mind that one of the primary purposes of repart.d is to dynamically size to real hardware as determined at run-time of booting the file system/initramfs the files are included in.
There are two big use cases for repart.d:
- I already have known existing partition states I'd like to ensure additions/modifications to.
- I want to create everything from scratch.
While there's a lot of discussion about Use-case 2, I don't think bootc install to-disk currently supports it. If I'm not mistaken it currently just has a fixed non-configurable partitioning scheme it implements, and you'd use something like bootc-image-builder to do a custom partitioning scheme (using bootc install to-filesystem under the hood instead).
In Use-case 1, which is all that's currently possible with bootc install to-disk, it's very unlikely a user would include files matching the default boot or xbootldr partitions, unless they're in the very unlikely scenario of needing to create additional partitions of those types (in which case you have to identify the existing ones first, so subsequent files are matched as new rather than existing). The most likely sub-use-cases are really just:
- Match the existing
rootpartition to grow it larger - Define new partitions
- Both
Ideally any modifications to bootc install to-disk would default the same as now, and assume Use-case 1. A check would have to be done to see if any of the repart.d config files uses the Type=boot, Type=xbootldr, or Type=root (or any of their synonyms) that matches with the default partitions, but otherwise the current default could be injected as a pre-defined set of repart.d files effectively.
Handling use-case 2 however would require the ability to opt-out of the default partitioning, and a way to specify what bootc-generated content goes into what user-defined partition (e.g. a name that can be used with CopyFrom=?).
