install: Use systemd-repart for partitioning - #2314
Conversation
Sorry, something went wrong.
cgwalters
left a comment
There was a problem hiding this comment.
Thanks for starting this! ACK on the principle.
Needs docs and tests at least.
Sorry, something went wrong.
| } | ||
|
|
||
| let rootpn = | ||
| rootpn.ok_or_else(|| anyhow::anyhow!("systemd-repart output missing root partition"))?; |
There was a problem hiding this comment.
I think we should support images that have repart.d definitions that are expected to run on firstboot in the target environment, without defining the default root either.
I would flip this around a bit - we default to running repart.d definitions for the root and esp/xbootldr, but probably not the other ones? And we let the other ones naturally run on firstboot.
Sorry, something went wrong.
There was a problem hiding this comment.
I think we should support images that have repart.d definitions that are expected to run on firstboot in the target environment, without defining the default root either.
so this will entail us creating a root partition if it's not defined?
Agree with the second point. We can only include root,esp and xbootldr
Sorry, something went wrong.
There was a problem hiding this comment.
Re-reading the comment, I think I get it now. The main question then would be how would be figure out the sizes of the root partition? Doing a simple --dry-run with systemd-repart is probably the best way
Sorry, something went wrong.
There was a problem hiding this comment.
The main question then would be how would be figure out the sizes of the root partition?
We honor the repart defaults i.e. something like
[Partition] Type=root
should be all that's needed to have that fill the remaining space.
For cloud scenarios a common thing is that the raw block device is expanded dynamically, and I think there repart will run again and should handle expansion of the root.
Sorry, something went wrong.
|
Currently we check fs-verity compatibility for composefs installations using the filesystem param passed via cli or in our config files. With systemd-repart, we will be allowing any filesystem to be used for root partition (not just the ones defined in our Filesystem enum). This poses an issue with checking fs-verity compatibility of filesystems that are not defined in our enum. This is probably going to be a design choice, should we: Read repart.d definitions, add more fs options in our enum to still be able to check for fs-verity compatibility |
Sorry, something went wrong.
I think ideally we do fsverity support detection early on dynamically instead of having a filesystem allowlist. But I'd vote for now we just let the install fail if fsverity is required and we fail to enable it instead of trying to match filesystems via repart.d |
Sorry, something went wrong.
If `systemd-repart` binary is present and we find one of the directories associated with systemd-repart configurations, then use systemd-repart for partitioning, else fallback to sfdisk Also, update the default ESP size to 2G for composefs installs. This only applies to sfdisk path. Closes: bootc-dev#2132 Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
When repart.d configuration defines ESP/xbootldr but omits a root partition definition, previously we failed with a hard error. Now we perform a dry-run first to detect whether a root partition is defined. If not, it creates a temporary definitions directory containing: - ESP/xbootldr configs from the existing repart.d - A generated root partition config `Type=root` that consumes all remaining disk space or a fixed size via `--root-size` Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
If systemd-repart definition for root partition is present in the image, we don't need the `--filesystem` CLI option to be present. So, we ignore it until we have enough information from the repart definitions. This has the ufortunate effect of us not being able to outright detect if the filesystem will support fs-verity or not during composefs installs. Now if we have a rootfs that doesn't support fs-verity, but the composefs repository does not have fs-verity as optional, we will throw an error during installation instead of throwing an error while preparing for an install. Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Do not filter the definitions that are supposed to run after boot as we mount `/sysroot` ro which causes systemd's growfs service to throw an error as it tries to repartition Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
|
Weird that we're only getting disk space error on f43 content: + podman run --rm --privileged -v /dev:/dev -v /run/udev:/run/udev -v /var/disk.img:/disk.img --pid=host --security-opt label=type:unconfined_t --env BOOTC_BOOTLOADER_DEBUG=1 localhost/bootc-repart-noroot bootc install to-disk --filesystem ext4 --root-size 5G --disable-selinux --via-loopback --source-imgref containers-storage:localhost/bootc-repart-noroot /disk.img content: Automatically enabling --generic-image when installing via loopback content: notice: Target has SELinux enabled, overriding to disable content: Installing image: docker://localhost/bootc-repart-noroot content: Block setup: direct content: Size: 10737418240 content: Serial: <unknown> content: Model: <unknown> content: Partitions: Discoverable content: Initializing ostree layout content: layers already present: 0; layers needed: 13 (2.1 GB) content: error: Installing to disk: Creating ostree deployment: Pulling: Importing: Writing relabeled layer 30721fef5053e6f825058143840fc073e309af149cb21783931acf9844affc6a to mtree: Writing content object: min-free-space-percent '3%' would be exceeded, at least 118.7 MB requested Increased root partition size |
Sorry, something went wrong.
Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Generated by ClaudeCode Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Similar to what we have in the composefs path, check if there already exists an overlay at `/usr`. This fixes the error in `test-install-repart.nu` where a second install was failing for ostree due to an overlay already existing on `/usr` Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Before trying to run `bootc install to-disk` manually remove `/run/ostree/deployment-state/...` as ostree checks a file in this directory to test whether the current deployment is unlocked. 5b52216 adds a check in the ostree path to early return if an overlay already exists on top of `/usr`, but the way `systemd-run` works with `Mount=slave` makes it so that no overlay exists on top of `/usr` but the file in `/run/ostree/deployment-state/..` remains intact which causes ostree to throw an error. Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
Older systemd-repart versions (ex. the one in c9s) do not include the partno field in the JSON output. Make the field optional and fall back to the array index when absent Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
|
Finally, tests pass. This should be good for review now @cgwalters @jeckersb |
Sorry, something went wrong.
cgwalters
left a comment
There was a problem hiding this comment.
Not a full review yet
Sorry, something went wrong.
| # Remove usr overlay state for ostree | ||
| # We still need this even though we now have usr-overlay check in ostree branch | ||
| # as well, because ostree checks for a file inside /run/ostree/deployment-state/... | ||
| # for usr-overlay status | ||
| rm -rvf /run/ostree/deployment-state | ||
|
|
There was a problem hiding this comment.
Hmm but we're kind of piling on hacks here... (not your fault to be clear)
Sorry, something went wrong.
| `systemd-gpt-auto-generator` maps DPS partition types to fixed mount points | ||
| (e.g. `Type=home` mounts at `/home`). If the mount point is a symlink | ||
| as is common in ostree-based systems where `/home -> /var/home`, the | ||
| auto-generated mount unit will fail. |
There was a problem hiding this comment.
I think we should argue to fix this in systemd btw
Sorry, something went wrong.
| Images may include repart.d definitions for partitions beyond root, ESP, | ||
| and xbootldr, for example `/home`, swap, or `/var`. Because all definitions | ||
| run at install time, systemd-repart allocates space for all of them during | ||
| installation. |
There was a problem hiding this comment.
Hmmm hmm...I worry about this breaking use cases people have where they actually relied on the repart definitions running on firstboot.
Think about use cases like "generic cloud image with repart definition for instance-local drive" - or really any case where the block devices aren't available at the time we happen to run bootc install (basically bootc-image-builder style flows typically).
Actually we already have this knob: --generic-image. I think if that is set, we should only honor the root repart definition (but do use the other ones for calculating space constraints?)
Sorry, something went wrong.
Reviewers
At least 1 approving review is required to merge this pull request.
If systemd-repart binary is present and we find one of the directories associated with systemd-repart configurations, then use systemd-repart for partitioning, else fallback to sfdisk
Also, update the default ESP size to 2G for composefs installs. This only applies to sfdisk path.
Closes: #2132