BlueBuildB
BlueBuild•11mo ago
amel

Changing image base from Ublue images to vanilla Silverblue - what is the best approach?

Hi! I have a question, if I wanted to migrate my custom image's base from ublue's silverblue-main to Fedora's vanilla Silverblue, what would be the best way to do so successfully?

I've tried doing so several times in the past w these steps:
  1. Create a custom Silverblue image in my repo with quay.io/fedora/fedora-silverblue as base-image. This creates custom-silverblue-base
  2. Builds just fine with the signing module
  3. Update my existing result image recipe.yml (let's call this result-image) - base-image is replaced from ghcr.io/ublue-os/silverblue-main to gchr.io/username/custom-silverblue-base
  4. result-image builds just fine with the signing module
  5. result-image is deployed just fine on the target machine, boots & runs as expected
  6. When running rpm-ostree update, it fails giving errors as such:
    Error: Creating importer: failed to invoke method OpenImage: failed to invoke method OpenImage: Error parsing signature storage configuration: "docker" namespace "ghcr.io/username" defined both in "/etc/containers/registries.d/result-image.yaml" and "/etc/containers/registries.d/custom-silverblue-base.yaml"
Some digging around made me think perhaps it has something to do w/ files under /etc/pki/containers and/or /etc/containers/registries.d/, but sudo ostree admin config-diff doesn't show that the files have been modified locally. Also, my cosign keys are unmodified, so this is not like the case of Bluefin's cosign keys from last year.

I wonder if it would be more efficient to just create a new repo altogether?

Would appreciate any input on this!
Solution
Gave it another test - it seems like the following approach as I've described above, or simplified:
  1. Create custom-silverblue-base in REPO
  2. Create result-image using custom-silverblue-base as base-image, also in REPO
  3. Deploy & continuously update/check for updates using rpm-ostree update
    will give the Error parsing signature storage configuration errors without fail.
However, this approach works:
  1. Create result-image using fedora/fedora-silverblue or fedora-ostree-desktops/silverblue with a set of recipes that would have gone into custom-silverblue-base
  2. Deploy & continuously update/check for updates using rpm-ostree update
    works fine and doesnt' give me the parsing signature errors.
So for now I've resigned to making a base-recipe.yml that layers basically everything that will be shared across images (repo files, bling, codecs, layers/removals of unneeded fedora packages, extensions etc), and just from-file: base-recipe.yml it in multiple image recipes. I've only tested on one machine though, will give it another try on a diff machine
Jump to solution
Was this page helpful?