Support for filesystem types for non-root partitions #499
Comments
|
I think actually I'd vote to drop the separate The reason it's there is because it's necessary for LUKS cases, but that's it's own thread around supporting...and all of this heavily intersects with something like #440 which would come at this from an entirely different way. Tangentially related to this systemd/uapi recently started suggesting that But anyways my thinking here has leaned a lot closer to the idea in #440 that we streamline having downstream OS containers provide their own partitioning logic, just hooked "underneath" bootc install to at least have some common interfaces. |
In order to simplify what we're doing here, let's drop the separate `/boot` aka XBOOTLDR partition by default for the `to-disk --block-setup=direct` path (the default). We retain it when using `--block-setup=tpm2-luks` as it's required there. Notably this kills off a hardcoded "ext4 for /boot" which is suboptimal for many reasons. Longer term again I'd like to emphasize `install to-filesystem` with external installers, plus integrating external installation scripts as part of `bootc install to-disk`. xref: - containers#499 - containers#440
|
I did #529 which is related to this. |
In order to simplify what we're doing here, let's drop the separate `/boot` aka XBOOTLDR partition by default for the `to-disk --block-setup=direct` path (the default). We retain it when using `--block-setup=tpm2-luks` as it's required there. Notably this kills off a hardcoded "ext4 for /boot" which is suboptimal for many reasons. Longer term again I'd like to emphasize `install to-filesystem` with external installers, plus integrating external installation scripts as part of `bootc install to-disk`. xref: - containers#499 - containers#440 Signed-off-by: Colin Walters <[email protected]>
In order to simplify what we're doing here, let's drop the separate `/boot` aka XBOOTLDR partition by default for the `to-disk --block-setup=direct` path (the default). We retain it when using `--block-setup=tpm2-luks` as it's required there. Notably this kills off a hardcoded "ext4 for /boot" which is suboptimal for many reasons. Longer term again I'd like to emphasize `install to-filesystem` with external installers, plus integrating external installation scripts as part of `bootc install to-disk`. xref: - containers#499 - containers#440 Signed-off-by: Colin Walters <[email protected]>
…-1.0.72 build(deps): bump anyhow from 1.0.71 to 1.0.72
…e-manifest Add previous container image state
Related to osbuild/bootc-image-builder#407:
I was curious if there are plans to support defining the filesystem for partitions other than root (specifically
/boot). Currently, the way BIB works, we have a situation where users can control the filesystem type of their root partition, but have no control over/bootand it creates a mismatch which, while not invalid, can be a bit unusual.If not, if we don't want to overcomplicate the bootc install configuration, I think it might be more appropriate to have pre-defined partitioning schemes that control multiple partitions (similar to Anaconda kickstart's
autopart).The text was updated successfully, but these errors were encountered: