blue-build/template

Template for making your own OS image using BlueBuild

template's Issues

chore: finally remove the old ISO action

I've just been forgetting to do this...

is semantic.yml still relevant?

I think it requires this GitHub app be manually installed: https://github.com/marketplace/semantic-prs/plan/MLP_kgDNHVc

Besides, a lot of people don't just care about following conventional commits in their custom images.

PR GitHub action build: two builds intended?

In a pull request, the GitHub action runs twice (for push and for pull request):

Is this intended?

feat: add some custom image topics to the repo, check if they propagate to users

fix: builds in template

Either the builds in this repo should be disabled, or made not fail by adding cosign keys.

Build Custom Image failed due to "no space left on device"

I've been a user of https://github.com/blue-build/legacy-template for a while now and went to migrate to this template.

I copied my recipe.yml directly from my fork of the legacy-template, where it used to run without this issue, but now I'm getting this error.

Logs: https://github.com/bigjazzsound/os/actions/runs/8151428872/job/22279283500

docs: add commented out `maximize_build_space: true` to build.yml

Hi, I have ran into a problem where the instance didn't have enought space during build time when working with a big image like Bazzite.

I added this to my .github/workflows/build.yml

      # If you ran out of space during build, this should help
      - name: Maximize build space
        uses: ublue-os/remove-unwanted-software@v7

as first steps: of bluebuild:

It takes about a minute and results in Total reclaimed space: 3.141GB

Could be added to default template as a comment.

Thanks

chore: clean out repo

• README needs to be updated (this template is not "constantly updating")
• Move a ton of docs to website (so that they will be up-to-date, more accessible, and updateable without bothering the user)
• Update image name and other dummy values to be more generic

blue-build/github-actions version v1.0.1 is broken in the template

I noticed that github-actions v1.0.1 is broken with:

[4/4] STEP 15/21: COPY ./config/files/usr /usr
[4/4] STEP 16/21: RUN 	--mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw 	--mount=type=bind,from=stage-modules,src=/modules,dst=/tmp/modules,rw 	--mount=type=bind,from=stage-exports,src=/exports.sh,dst=/tmp/exports.sh 	chmod +x /tmp/modules/rpm-ostree/rpm-ostree.sh 	&& source /tmp/exports.sh && /tmp/modules/rpm-ostree/rpm-ostree.sh '{"type":"rpm-ostree","repos":null,"install":null,"remove":["firefox","firefox-langpacks"]}'
error building at STEP "RUN --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind,from=stage-modules,src=/modules,dst=/tmp/modules,rw --mount=type=bind,from=stage-exports,src=/exports.sh,dst=/tmp/exports.sh chmod +x /tmp/modules/rpm-ostree/rpm-ostree.sh 	&& source /tmp/exports.sh && /tmp/modules/rpm-ostree/rpm-ostree.sh '{"type":"rpm-ostree","repos":null,"install":null,"remove":["firefox","firefox-langpacks"]}'": error resolving mountpoints for container "74929d6654b37bd69553cbc86699482018317bf5c62388566ec8d62e89f8e20f": invalid mount type "bind"

Bumping to v1.0.2 fixed the above issue.

Should we remove 60-custom.just from the template?

• It's ublue-specific
• A lot of people don't use it
• Basically no-one will use it by just stumbling upon it in the repo, they'll read about it in the docs first
• It's not needed for including 100-bling.just anymore

I think we should...

`cryptographic signature verification failed` when pulling custom image (image already public)

When using my custom image (https://github.com/miabbott/rh-meatwad), I started to get the error:

error: Creating importer: Failed to invoke skopeo proxy method OpenImage: remote error: cryptographic signature verification failed: invalid signature when validating ASN.1 encoded signature

...when trying to pull the latest builds. I found #23 and blue-build/website#40, then confirmed that the package was public.

In my own investigation, I used cosign verify to walk back to the last known good image. It appears that 2 days ago was the last image that was correctly signed (ghcr.io/miabbott/rh-meatwad:20240505).

Surprisingly, I had not changed any code in my repo until yesterday (miabbott/rh-meatwad@150289c), so I'm unsure why this signature validation error cropped up before then.

I'm not well versed in cosign and container signing, so any hints are appreciated.

Cosign signing is failing

Hi all,

In moving away from startingpoint to blue-bird-template, cosign consistently fails when using the private key.

What I tried so far:

• Generate the key pair as described in https://blue-build.org/how-to/cosign/
  • I'm using the GitHub CLI client (as described) to avoid errors due to manual operations
  • I can confirm a secret under the name SIGNING_SECRET is correctly created, but of course, I can't access the content of the secret
• Commit and push the public part of the cosign key

(trace)

[2024-02-29T20:27:34Z TRACE blue_build::commands::build] check_for_cosign_files()
[2024-02-29T20:27:34Z DEBUG blue_build::commands::build] Building on live branch, checking cosign files
[2024-02-29T20:27:34Z TRACE blue_build::commands::build] cosign public-key --key env://COSIGN_PRIVATE_KEY
[2024-02-29T20:27:34Z ERROR blue_build::commands] Failed to run cosign public-key: Error: decrypt: encrypted: decryption failed
    main.go:74: error during command execution: decrypt: encrypted: decryption failed
    
Error: Process completed with exit code 1.

I tried again two times, manually, to discard any issue with GH and got the same result.

Then, I tried with the (very nice!) WebUI: https://blue-build.org/how-to/setup/ (Automatic setup using the web interface) using the factory values:

As you can see, it failed again with the same error message as above. I confirm a secret named SIGNING_SECRET was attached to the repository.

Let me know if there's any other piece of information that you need!

[ recipe.yml ] Firefox removal: Build failure warning for missing RPMs in upstream image

Hi all,

When configuring my recipes to remove Firefox RPMs from the upstream image (in favor of the Flatpak version), the pipeline fails because said packages are missing from the upstream image I switched to (kinoite-main -> bazzite).

The issue is triggered when rpm-ostree uninstall firefox is performed, which will throw an exit code 1, making the pipeline fail.

As previously discussed on Discord:

• With @bayou-brogrammer: https://discord.com/channels/1198292321037455360/1200874814349508629/1212875808914415637
• With @xynydev: https://discord.com/channels/1198292321037455360/1212997762614956052

A proposed solution is to leave a heads-up comment on the Firefox removal section in the recipe template, warning the user the pipeline will fail if Firefox RPMs are missing from the upstream image.

feat: github action success card in readme

Installation via custom ISO fails during deployment step

Hi, I just started migrating my startingpoint builds over to blue-build. I haven't really changed anything but created new cosign keys. The builds work fine, an ISO is generated and I downloaded it to try installing it. After going through all the options int he installer and starting the installation process this throws the following error:

The following error occurred while installing the payload. This is a fatal error and installation will be aborted.

The command 'ostree container image deploy --sysroot=/mnt/sysimage --image=ghcr.io/dockde/bluejay-next:latest --no-signature-verification' exited with the code 1.

I haven't seen this before and would appreciate help. If this is not the best place to report this, I'd be happy for pointers for where else to go.

Gh OIDC keyless

Hi all, is github OIDC planned for this project? Happy to help if you can give me pointers.

To reference from the bluefin repo: ublue-os/bluefin#907

Error on rebasing to unsigned image

Hi, I followed the guide to set up a new repository and everything seemed to go well. The unmodified images from the stock template are published in ghcr.io and I could verify that the public key matches the signature.

❯ cosign verify --key cosign.pub ghcr.io/mathetes87/ublue-mathetes-kde:latest

Verification for ghcr.io/mathetes87/ublue-mathetes-kde:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

I installed Bluefin in a VirtualBox image and tried to rebase but got this error

❯ rpm-ostree rebase ostree-unverified-registry:ghcr.io/mathetes87/ublue-mathetes-kde:latest
Pulling manifest: ostree-unverified-registry:ghcr.io/mathetes87/ublue-mathetes-kde:latest
error: Creating importer: Failed to invoke skopeo proxy method OpenImage: remote error: unable to retrieve auth token: invalid username/password: unauthorized

I rebased Bluefin successfully to the latest version and checked that podman reports successful login to ghcr.io.
This error seems similar to this issue but my (attached)
/etc/containers/policy.json looks fine? This is a new installation and also new repository.
policy.json

Thanks for any help!

rpm-ostree and podman fali to load the generated image with ASN.1 signature errors

Both rpm-ostree and podman produce the same error:

❯ rpm-ostree upgrade
note: automatic updates (stage) are enabled
Pulling manifest: ostree-image-signed:docker://ghcr.io/dperson/silver-ublue:latest
error: Creating importer: Failed to invoke skopeo proxy method OpenImage: remote error: cryptographic signature verification failed: invalid signature when validating ASN.1 encoded signature

While cosign thinks everything is good:

❯  cosign verify --key projects/ublue-os/cosign.pub ghcr.io/dperson/silver-ublue:latest

Verification for ghcr.io/dperson/silver-ublue:latest --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"ghcr.io/dperson/silver-ublue"},"image":{"docker-manifest-digest":"sha256:9ee4922f79e62beb828c02c74a8c4e77f28508aad6983e719c870b4152079a6f"},"type":"cosign container image signature"},"optional":{"Bundle":{"SignedEntryTimestamp":"MEUCICzgS/QCzQC4rURzj602kKUG/Gi9Apbi4eK3O/ogdaimAiEArKaJs0LJdFm+fkPZlbdHj3/HfRDD7WKmyEXWh4GMCQQ=","Payload":{"body":"eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI1ZTljMzBmYjc3NzU5MDRlMDkyNzdkYzE4M2E3ZTVhNTg1NzRmMWEzYTcyMGU0OGNjNWFlZjZhOGYxMzlkZTdjIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FVUNJRElEWFBtMWlFeGVlTTZhaG9uNmFtMy9hR2ZTdTk4c01vM1ROek5jOVloTkFpRUFxanFiTDhrSWhUNlZsOWMzcEQ1cEtqdC9MQkZTU1grSWh3TUtZS21KaDIwPSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCUVZVSk1TVU1nUzBWWkxTMHRMUzBLVFVacmQwVjNXVWhMYjFwSmVtb3dRMEZSV1VsTGIxcEplbW93UkVGUlkwUlJaMEZGY0RCM2RWUmFLekUyY2xaVVVEZEpUMkp6WW5JellsTkxRa0V5T1FwV1pqaGhaVk53VURoV2RqUjJaVWRHVkVaaFJUWnNTMmhTYXpGSWQyZzRjMlZJYkhGTlptbEliVGx4WVN0V00wZDFlVWhUVGxKclZDdEJQVDBLTFMwdExTMUZUa1FnVUZWQ1RFbERJRXRGV1MwdExTMHRDZz09In19fX0=","integratedTime":1709003820,"logIndex":74227925,"logID":"c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d"}}}}]

The builds are running successfully, I'm not sure what or how I messed things up... the repo is public, you're welcome to look. Running rpm-ostree rebase has the same issue as upgrade.

The only thing my searches found was this link, which was caused by something messed up in /etc/containers. So I cleared it entirely replacing it with the contents of my /usr/etc/containers.

I really like how you cleaned up the design / layout of the template. Now if I can just get the images to work... Thanks!

feat: start using actions-template-sync

From Discord:

Hey, uhh, I thought that with pull.yml we wouldn't need to fork since that can sync changes automatically. Now I realized that you can't actually "sync with an upstream" if you aren't a fork, so our template changes won't be synced to users.
I do still want to get rid of forking, since it's very annoying that you can accidentally PR the upstream repo and can have only one fork of the template. And outside contributors need to fork to contribute, which is kind of annoying if making a custom image in the fork...
We'll have to figure out how the syncing would work, then...
Apparently, it has to be done with the git CLI: https://stackoverflow.com/questions/56577184/github-pull-changes-from-a-template-repository
But someone made an action to automate it: https://github.com/marketplace/actions/actions-template-sync
I guess this would be the best option if we trust that
We could .templatesyncignore the config/ and modules/ folders

chore: switch to pinning a major or minor version instead of a patch version

Once blue-build/github-action#19 is released, we'll have the @v1, @v1.1, and @v1.1.0 tags available.

I'm unsure whether to pin to the major (v1) version or the minor (v1.1) version. With major versions it would be very automatic for users, but they also wouldn't get notified of new features by Dependabot.