Is your feature request related to a problem? Please describe.
This will use a standard testing suite for testing the resulting ISO

Describe the solution you'd like
Use OpenQA http://open.qa/

Describe alternatives you've considered
Custom scripts are currently being used

Additional context
Currently used by Fedora: https://openqa.fedoraproject.org/

Describe the bug
It is likely to do with the version of bootc packaged for Fedora 38, but the bootc switch command does not work properly for Fedora 38 based containers with Bootc installed in them.

To Reproduce
Steps to reproduce the behavior:
Bluefin GTS (based on Fedora 38) has this specific issue

Expected behavior
Post kickstart script to function properly to switch remote for rpm-ostree

Potential Solutions

1. Add a check to determine if the command bootc switch --mutate-in-place is available
2. Check to see if the image is based on Fedora 38 and if it is, fallback to the sed method.
3. Comment out bootc switch command since the sed method does what bootc switch does anyway.

Describe the solution you'd like

skopeo copy docker://quay.io/exampleos/myos:latest oci:/path/to/filesystem/myos.oci

Is your feature request related to a problem? Please describe.
In a fork, there was a report that the installer is on the wrong release version. this would ensure the build process is correct

Describe the solution you'd like
use matrix to expand testing

Is your feature request related to a problem? Please describe.
There was a recent reorganization of the monolithic make file into smaller make files. Upon doing this, secure boot key was not getting copied over properly and we had no tests to confirm that it was broken.

Describe the solution you'd like
We need to have a test that does not have a secure boot key and one that does. All of our tests currently have the secure boot key by default.

We would create a VM test that would check any of the VMs with a secure boot key loaded that it loaded the proper key onto the VM. mokutil --list-enrolled gets a list of keys. We could do a grep on the entire public key to make sure it appears in there.

Additional context
Issue was found here: #100

Is your feature request related to a problem? Please describe.
Some containers can only install using Fedora 40

Describe the solution you'd like
Add 40 to the list of tests

Additional context
Adding version 40 results in an error that pcmciautils is unavailable

Is your feature request related to a problem? Please describe.
Fedora Flatpak repo is set at the same priority as the Flathub repo upon installation. This can cause problems for users trying to install from the correct repo.

Describe the solution you'd like
A way to either completely remove the Fedora flatpak repo as a part of installation or just disable it.

Describe alternatives you've considered
We can use a service file to disable the repo on first boot, but that's not ideal.

Describe the bug
I noticed on the builds that it is attempting to build the ISO twice.

To Reproduce
Any run through the action or docker command. Witnessed it here:
docker run --rm --privileged --pull always --volume .:/github/workspace/build ghcr.io/jasonn3/build-container-installer:pr-69 VERSION=38 IMAGE_NAME=bluefin IMAGE_REPO=ghcr.io/ublue-os IMAGE_TAG=gts VARIANT=Silverblue

Expected behavior
Should only try to run the templates once.

Attached logs: output.txt

Is your feature request related to a problem? Please describe.
Currently we only support ostree-signed. We should add a feature to set to ostree-unverified when the container upstream is being set.

Describe the solution you'd like
Have a flag to disable signed images for the action as well as the container. This would be useful for testing in a lab as well as images that aren't being signed.

Describe alternatives you've considered
We could just not?

Additional context
@JasonN3 and I discussed this while working on the fedora-bootc feature.

Is your feature request related to a problem? Please describe.
There is currently a requirement to replace some system files. This is fine within the container, but would be an issue when running outside of a container

Describe the solution you'd like
Use Koji to create a build system when running make

Is your feature request related to a problem? Please describe.
Currently, we don't have an option to create Live ISOs. This makes installing on handheld devices or touch devices impossible without an external dock and keyboard due to Anaconda not supporting an onscreen keyboard. This would also be a huge benefit for users who just want to try one of the images we support.

Describe the solution you'd like
Lorax has a tool called "Live Media Creator" that we could use for generating Live ISOs. There is also Live CD Tools. This would be a huge undertaking as Upstream Silverblue and Kinoite do not make live ISOs currently.

Describe alternatives you've considered
I could file this as an issue upstream to anaconda, but it is unlikely to land until they do the Web UI.

Describe the bug
envsubst when running make install-deps

Additional context
Part of package gettext

Describe the bug
When using the action, it adds a pr tag to the container. This is useful for testing in the build-container-installer repo, but it breaks the ability to use the action outside of the repo.

This tag should be the PR number only when used by the build-container-installer repo. It should be equal to the action_ref used by the action every other time.

To Reproduce
Steps to reproduce the behavior:
https://github.com/ublue-os/bluefin/actions/runs/8236695396/job/22523736706

Describe the bug
Action does not work. There is an issue with how it uses the docker container.

To Reproduce
Use the action.
https://github.com/ublue-os/bluefin/actions/runs/8455840602/job/23164969508

Expected behavior
Expect the container to pull down and run.

Additional context
I believe the problem lies here:

It is using the ACTION_REF which is v1.1.0, but there is no tag for the container for v1.1.0. There is only 1.1 and 1.1.0

Is your feature request related to a problem? Please describe.
It would be awesome to have this be able to create ISO install images for ARM based containers. I'm unsure what this would fully entail.

Describe the solution you'd like
Be able to create ISOs for ARM based OCI images.

Additional context
We will likely be blocked by Fedora upstream until they have official ARM based OCI images that will work. I'm unsure if Centos is working on anything regarding that architecture.

Current installer is called from: https://github.com/rhinstaller/anaconda/blob/c473364cebc2e6b8c3e0fb37cc5146055dec9a15/pyanaconda/modules/payloads/payload/rpm_ostree/installation.py#L592

Describe the solution you'd like
Create a separate package for RHEL based containers using the RHEL installer. Repos should be available from RHEL UBI

Describe the bug
When building using the container outside of GH, /github/workspace doesn't exist so it is failing to copy the file

Expected behavior
Copy should succeed

Intro

This issue is made in order to track the state of online ISOs implementation in build-container-installer.

There are some users who prefer to have or offer online ISOs for the images, including me, so here is the list of advantages & disadvantages of online ISOs over offline ones that I gathered.

Advantages

• User always gets the latest image
• Integration with GitHub, including automatic upload to GitHub releases
  Thanks to the smaller file-size compared to the offline ISOs.
• No need to have separate hosting, due to the advantage above

Disadvantages

• Requires internet connection during ISO usage
• It's not possible to generate live-ISO
  Users can't experience the system before install when using the ISO.
• It's not reliable enough with current Anaconda implementation
  • It lacks the option to pause, resume or retry the ISO download.
  • It lacks any useful troubleshooting logs in case if error occurred.
  • It can fail for some users, even with good internet connection
    (I personally never had the issue with 20Mbps 4G+ADSL internet, but I'm just the exception here).
  • It installs the unsigned image, so you need to rebase to the signed image afterwards
    (or use workarounds, like implementing the rebasing mechanism in ublue-update or similar).
  • Automatic detection of time, region & keyboard language is not working.

Some of those Anaconda issues are fixed in offline ISOs, like the last 2 ones, so maybe those can be used in online ISOs too.

Is your feature request related to a problem? Please describe.
Currently you need to specify flatpaks and all their dependencies in a long list. This makes it really hard to know what dependencies belong with which flatpak.

As an example with not that many apps:

docker run --rm --privileged --volume .:/github/workspace/build  ghcr.io/jasonn3/build-container-installer:main VERSION=39 IMAGE_NAME=bluefin IMAGE_REPO=ghcr.io/ublue-os IMAGE_TAG=39-testing VARIANT=Silverblue FLATPAK_REMOTE_REFS="runtime/org.kde.Platform/x86_64/6.5 runtime/org.kde.Platform.Locale/x86_64/6.5 runtime/org.kde.PlatformTheme.QGnomePlatform/x86_64/6.5 runtime/org.kde.WaylandDecoration.QAdwaitaDecorations/x86_64/6.5 runtime/org.kde.WaylandDecoration.QGnomePlatform-decoration/x86_64/6.5 runtime/org.freedesktop.Platform/x86_64/23.08 runtime/org.gnome.Platform/x86_64/45 runtime/org.gnome.Platform/x86_64/44 runtime/org.gnome.Platform.Locale/x86_64/44 runtime/org.gnome.Platform.Locale/x86_64/45 runtime/org.freedesktop.Platform.GL.default/x86_64/22.08 runtime/org.freedesktop.Platform.GL.default/x86_64/22.08-extra runtime/org.freedesktop.Platform.GL.default/x86_64/23.08 runtime/org.freedesktop.Platform.GL.default/x86_64/23.08-extra runtime/org.freedesktop.Platform.Locale/x86_64/23.08 runtime/org.freedesktop.Platform.openh264/x86_64/2.2.0 runtime/org.gnome.Calculator.Locale/x86_64/stable app/org.gnome.Calculator/x86_64/stable runtime/org.gnome.Calendar.Locale/x86_64/stable app/org.gnome.Calendar/x86_64/stable runtime/org.gnome.Characters.Locale/x86_64/stable app/org.gnome.Characters/x86_64/stable runtime/org.gnome.Connections.Locale/x86_64/stable app/org.gnome.Connections/x86_64/stable runtime/org.gnome.Contacts.Locale/x86_64/stable app/org.gnome.Contacts/x86_64/stable runtime/org.gnome.Evince.Locale/x86_64/stable app/org.gnome.Evince/x86_64/stable runtime/org.gnome.Loupe.HEIC/x86_64/stable runtime/org.gnome.Loupe.Locale/x86_64/stable app/org.gnome.Loupe/x86_64/stable app/org.gnome.Logs/x86_64/stable runtime/org.gnome.Maps.Locale/x86_64/stable app/org.gnome.Maps/x86_64/stable runtime/org.gnome.NautilusPreviewer.Locale/x86_64/stable app/org.gnome.NautilusPreviewer/x86_64/stable runtime/org.gnome.TextEditor.Locale/x86_64/stable app/org.gnome.TextEditor/x86_64/stable runtime/org.gnome.Weather.Locale/x86_64/stable app/org.gnome.Weather/x86_64/stable runtime/org.gnome.baobab.Locale/x86_64/stable app/org.gnome.baobab/x86_64/stable runtime/org.gnome.clocks.Locale/x86_64/stable app/org.gnome.clocks/x86_64/stable runtime/org.gnome.font_viewer.Locale/x86_64/stable app/org.gnome.font-viewer/x86_64/stable runtime/com.mattjakeman.ExtensionManager.Locale/x86_64/stable app/com.mattjakeman.ExtensionManager/x86_64/stable app/com.github.tchx84.Flatseal/x86_64/stable runtime/io.github.dvlv.boxbuddyrs.Locale/x86_64/stable app/io.github.dvlv.boxbuddyrs/x86_64/stable runtime/io.github.flattool.Warehouse.Locale/x86_64/stable app/io.github.flattool.Warehouse/x86_64/stable app/org.fedoraproject.MediaWriter/x86_64/stable runtime/io.missioncenter.MissionCenter.Locale/x86_64/stable app/io.missioncenter.MissionCenter/x86_64/stable runtime/io.github.celluloid_player.Celluloid.Locale/x86_64/stable app/io.github.celluloid_player.Celluloid/x86_64/stable runtime/org.mozilla.firefox.Locale/x86_64/stable app/org.mozilla.firefox/x86_64/stable"

Describe the solution you'd like
It would be very useful to have a standard file type you could create in your repo that has metadata for each flatpak and it's dependencies. That would allow you to define it in a set of files for easier organization. For the docker container we would want the option to specify a directory or mount that directory as a volume into the container.

Describe alternatives you've considered
The alternative is the above command :D

Items:

• Use Lorax to generate an ISO that runs Anaconda
• Save container as oci-dir format
• Install from saved container
• Update origin to source repo

Describe the bug
Only English is available in the installer.

To Reproduce
Steps to reproduce the behavior:
Create an ISO and boot from it

Expected behavior
All languages should be present

Screenshots

Additional context
This was fixed at one point with a PR, not sure if it got reverted somehow.

Is your feature request related to a problem? Please describe.
Some parameters get overlooked. A check could make sure they don't get missed

Describe the bug

After building and installing an image with the ISO, the resulting storage looked like the following:

❯ lsblk
NAME           MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda              8:0    0  250G  0 disk 
├─sda1           8:1    0    1M  0 part 
├─sda2           8:2    0    1G  0 part /boot
└─sda3           8:3    0  249G  0 part 
  └─devos-root 253:0    0   15G  0 lvm  /nix
                                        /usr/bin/swtpm
                                        /var
                                        /sysroot/ostree/deploy/default/var
                                        /usr
                                        /etc
                                        /
                                        /sysroot

To Reproduce
Steps to reproduce the behavior:

1. Create an ISO
2. Install it with automatic partitioning selected
3. After install, check storage

Expected behavior
I expected the entire disk to be used.

Additional context

Am I perhaps misunderstanding something? Do I need to plan on resizing the disk after installation, or should I not be attempting to use automatic partitioning?

Describe the bug
For some reason, the flatpak.trustedkeys.gpg is an empty file when installing from generated bluefin ISO.

To Reproduce

docker run --rm --privileged --pull always --volume .:/github/workspace/build  ghcr.io/jasonn3/build-container-installer:main VERSION=39 IMAGE_REPO=ghcr.io/ublue-os IMAGE_NAME=bluefin IMAGE_TAG=39-testing VARIANT=Silverblue FLATPAK_REMOTE_REFS_DIR=/github/workspace/build/flatpaks

Expected behavior
File should not be empty

Screenshots
Discussion happening in discord ISO thread: https://discord.com/channels/1072614816579063828/1192504002252914791

Is your feature request related to a problem? Please describe.
Only available in English

Describe the solution you'd like
Install additional language packs

Describe the bug
You cannot install multiple flatpak packages when using the docker command.

To Reproduce
docker run --rm --privileged --volume .:/github/workspace/build ghcr.io/jasonn3/build-container-installer:latest VERSION=39 IMAGE_NAME=bluefin IMAGE_REPO=ghcr.io/ublue-os IMAGE_TAG=39-testing VARIANT=Silverblue FLATPAK_REMOTE_REFS="app/org.videolan.VLC/x86_64/stable runtime/org.kde.Platform/x86_64/5.15-23.08"

Expected behavior
Export the variables properly

Output

+ for entry in $@
+ export VERSION=39
+ VERSION=39
+ for entry in $@
+ export IMAGE_NAME=bluefin
+ IMAGE_NAME=bluefin
+ for entry in $@
+ export IMAGE_REPO=ghcr.io/ublue-os
+ IMAGE_REPO=ghcr.io/ublue-os
+ for entry in $@
+ export IMAGE_TAG=39-testing
+ IMAGE_TAG=39-testing
+ for entry in $@
+ export VARIANT=Silverblue
+ VARIANT=Silverblue
+ for entry in $@
+ export FLATPAK_REMOTE_REFS=app/org.videolan.VLC/x86_64/stable
+ FLATPAK_REMOTE_REFS=app/org.videolan.VLC/x86_64/stable
+ for entry in $@
+ export runtime/org.kde.Platform/x86_64/5.15-23.08
/entrypoint.sh: line 7: export: `runtime/org.kde.Platform/x86_64/5.15-23.08': not a valid identifier

Is your feature request related to a problem? Please describe.
Difficult to keep track of which ISO is for which PR

Describe the solution you'd like
Append the PR number to the ISO zip name

Is your feature request related to a problem? Please describe.
I maintain an image for htpc and working on this to build an ISO for it however it seems like calling this is not a working solution and wondering is the user account needs to be created during instalation of a generated image

Describe the solution you'd like
The ability to pre create a user account on the ISO image so it does not need to be manually generated

Describe alternatives you've considered
A hacky systemd service to just create a user account on initial system boot that then disabled itself

If this bug can be solved via my image feel free to say so and just close the issue.

Describe the bug
Flatpak repos are not being configured properly and issues with setting the correct upstream location for rpm-ostree.

To Reproduce
Create an ISO using Fedora 39

Expected behavior
Post scripts should run

Screenshots

Write tests for different capabilities

• Ensure Flatpak packages are installed
• Verify all parameters match between action.yml, README.md, and Makefile
• Ensure OSTree origin is updated

When running the action in my blue-build based image repo, I encounter the error: invalid reference format: repository name must be lowercase. I believe this is due to my GitHub user name containing capital letters.

See my generate-iso.yaml workflow file: https://github.com/CarrotManMatt/carrot-kinoite-nvidia/blob/7771fbeb6d20f64e96025908efcd67756478615e/.github/workflows/release-iso.yaml
See the failing iso generation logs: https://github.com/CarrotManMatt/carrot-kinoite-nvidia/actions/runs/8926298189/job/24517007572#step:4:1207

It would be acceptable for the usernames to be normalised to lower case letters.

Is your feature request related to a problem? Please describe.
I have to push my image to a registry in order to use the local container or action.

Describe the solution you'd like
It would be nice to be able to directly copy the image from the local docker-daemon. I'm currently doing this by mounting over the current container Makefile. Instead of doing that, I wish to be able to specify the transport method.

Describe alternatives you've considered
I'm currently mounting over the current container Makefile with the necessary change.

Additional context
This is mostly for convenience for building one off test ISOs.

Is your feature request related to a problem? Please describe.
Not a specific one for me, but it would be cool to add the ability to have common custom kickstart options appended to the kickstart to automate certain aspects of the install.

Describe the solution you'd like
See above

Describe alternatives you've considered
You could have someone include a kickstart after the fact using xorriso, but it would be nice to include it as part of ISO generation

Is your feature request related to a problem? Please describe.
Repeated builds are slow because everything has to be downloaded new

Describe the solution you'd like
Create a volume for cache and symlink the cache directories into that volume

Additional context
skopeo cache: ~/.local/share/containers/cache

Describe the bug
When running the container provided by this project to try to build a custom ISO, no files are created into the bind-mounted volume, and no ISO is available after the generation process is complete.

To Reproduce

1. Open the terminal (optionally, navigate to an empty directory like ~/iso/)
2. Run the command provided in the README: docker run --rm --privileged --volume .:/github/workspace/build ghcr.io/jasonn3/build-container-installer:latest VERSION=38 IMAGE_NAME=base IMAGE_TAG=38 VARIANT=Server
   • I had to use sudo because of how my host is set up.
   • Here's the log: https://paste.centos.org/view/0c4da6c0
3. Wait for command to complete
4. Check directory with ls, no ISO file is found.

Additional things I tried

• Building an ISO of my own custom image with the following commands:
  • Setup:

      IMAGE_REPO=ghcr.io/xynydev
      IMAGE_NAME=linuxyz
      IMAGE_TAG=latest
      IMAGE_VARIANT=Silverblue
      mkdir ./iso

  • Build with docker:

      sudo docker run --rm --privileged --volume ./iso:/github/workspace \
      -e IMAGE_REPO="$IMAGE_REPO" -e IMAGE_NAME="$IMAGE_NAME" -e IMAGE_TAG="$IMAGE_TAG" -e VARIANT="$IMAGE_VARIANT" \
      ghcr.io/jasonn3/build-container-installer:latest

  • Build with podman:

      sudo podman run --rm --privileged --volume ./iso:/github/workspace --security-opt label=disable --pull=newer \
      -e IMAGE_REPO="$IMAGE_REPO" -e IMAGE_NAME="$IMAGE_NAME" -e IMAGE_TAG="$IMAGE_TAG" -e VARIANT="$IMAGE_VARIANT" \
      ghcr.io/jasonn3/build-container-installer:latest

  • No files were created in the ./iso/ directory with either of these commands.
• I also looked at the action.yml to see if the mount path (/github/workspace/) had changed from when the documentation was written, but I didn't find any indication of such a thing.

Expected behavior
When running the container with the bind mount, it should output the ISO file into the mounted host directory.

Desktop (please complete the following information):

• OS: Fedora Silverblue (custom image)
• Version: 39

Additional context

• Docker version 24.0.5, build %{shortcommit_cli} (from moby-engine)
• podman version 4.9.4 (pre-installed)
• Custom image repository: https://github.com/xynydev/linuxyz

Describe the bug
Using the deps branch (which is based off main), it is not copying over the secure boot key defined in the action inputs.

https://github.com/ublue-os/bluefin/actions/runs/8584000337/job/23523831176

To Reproduce
Use the action.

Expected behavior
Should copy the file over, it is not.

Additional context
To avoid this in the future, we should probably define a test using ansible that will detect if the .der file got copied over. Not sure how we would be able to test mokutil for a true test.

Is your feature request related to a problem? Please describe.
There are only examples using docker. We should include examples using podman.

Describe the solution you'd like
Update README to include podman commands

Describe alternatives you've considered
Not adding them?

no screens in anaconda to set username / password ? so how does one login to the iso ?

Is your feature request related to a problem? Please describe.
Right now the dependencies have to be specified in the list. It would be nice to generate that list from a list of apps

Describe the solution you'd like
Run a container prior to building the ISO and install the Flatpaks to a volume that can be read in by the Lorax template

1. docker run -v flatpaks:/flatpaks ${dest_container} ... flatpak install ...
2. Normal action

Describe the solution you'd like
Add support for bootc instead of just rpm-ostree