Dynamic root partition size

[BobyMCbobs]

I'm trying to build an image bigger than 2GB with bootc-image-builder.
The fixed size is specified here: https://github.com/osbuild/bootc-image-builder/blob/aaa2f5b/bib/cmd/bootc-image-builder/partition_tables.go#L53

The size of an image with layers combined can be found like so

crane manifest quay.io/fedora-ostree-desktops/silverblue:39 | jq '([.layers[].size] | add)'

or

skopeo inspect docker://quay.io/fedora-ostree-desktops/silverblue:39 | jq '([.LayersData[].Size] | add)'

and then converted from bytes into Gibibytes.

Using the manifest data could be an automatic way to figure out the disk size, otherwise a manual override flag could be helpful.

Let me know your thoughts, cheers!

[achilleas-k]

Partitioning is planned and something we can do relatively easily for some base cases (resizing the image, adding extra partitions, etc). There's also a plan to read partitioning metadata from the container image itself, but that needs more work.

[noelmiller]

I would like to echo the value of this issue. We are looking at using this as a way to generate images for https://github.com/ublue-os and currently creating https://github.com/ublue-os/bazzite images does not work due to the size of the bazzite image.

[cgwalters]

This relates strongly to containers/bootc#287 which depends on #18

[cgwalters]

I briefly looked at trying to add a "just double the input container size" in the existing logic and it seems like this fundamentally clashes with the existing osbuild model of having the manifest be "on top", right? The osbuild-mpp thing seems to add some dynamism that doesn't exist quite in what is in the Go code today.

I'm willing to try to implement this with some pointers. Maybe we should do the install-to-filesystem first, as that will end up potentially leading towards a path where the container input drives more things.

[cgwalters]

So we landed the doubling in #291 which is good, but we very much still need both configuration and better defaults, because the use case of embedding container images (referenced dynamically via quadlet) is very important.

And what I'd like to at least consider doing here (this strongly relates to containers/bootc#128 ) is that bootc install actually by default looks at your quadlet files, finds their sizes, and adds that into the defaults. (And we'd need to bikeshed whether those sizes are doubled...)

Short term though, it seems fine to me to add a minimum root size into the blueprint we have today right? This touches on #124 most quickly - and perhaps we should focus on that for now.

[mvo5]

We rebased #124 which would allow resizing / and /boot as a starting point.