How do I make an ISO from an OCI image for silverblue?

ultra980 · January 4, 2023, 6:57pm

Hello, my friend and I have started working on Danora, a gaming-focused silverblue-based distro, inspired by Nobara. We have got a Containerfile and we have set up github actions to build the OCI image at ghcr.io/ultra980/danora (thanks Jorge Castro for the repo template).
However, we do have one problem: to install the OS we need to install silverblue or kinoite and rebase with the experimental flag. This can be inconvenient, especially since this distro is also targeting beginners. So is there a way to make an installer ISO, like Kinoite? Thanks!

vwbusguy · January 4, 2023, 10:01pm

It looks like this current topic on our discussion site is relevant. Seems someone recently figured out how to do this there:

ultra980 · January 5, 2023, 6:11am

Hi, this is very useful but I want to find a way to actually boot it on bare metal (not just in podman / docker).

castrojo · January 7, 2023, 8:38pm

Ok been doing some digging and I think I found some good background info:

github.com/coreos/fedora-coreos-tracker

Create tooling to take a FCOS-derived container and generate bootable images from it

opened 04:00PM - 03 Apr 22 UTC

cgwalters

jira kind/enhancement area/ostree-containers

This is touched on in https://github.com/coreos/enhancements/blob/main/os/coreos…-layering.md#use-of-coreos-diskboot-images Basically I think our default stance is that admins use our golden images + ignition to target their custom containers, but I think for a variety of reasons we will want to support generating disk images directly too. I think this would be relatively maintainable for bare metal targets in particular (ISO, PXE etc.), and it's on bare metal targets where there's more of a desire for things like handling the first boot with an out of tree NIC driver, etc. Now, obviously this is basically what coreos-assembler is today. However, a few key points: - We don't want to expose all of coreos-assembler as a supported UX - The input to this tool should *only* be the derived container image, not e.g. the config git repository too. This topic heavily touches on https://github.com/coreos/coreos-assembler/issues/2685 This build tool could derive from the coreos-assembler container literally, or we could split out the bits we need as a shared library or so (could make sense as a Go library actually, even if we happen to ship shell scripts and python in it?). Starting out this way is going to be the most supportable thing. This tool should be runnable as a container image (that yes, accepts a container image as input) by default, but we could support other flows too. That said, we should also do a spike on having e.g. [RHEL Image Builder](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/composing_a_customized_rhel_system_image/composer-description_composing-a-customized-rhel-system-image) be able to output an ISO at least.

github.com/containers/bootc

Add an `install` command

containers:main ← cgwalters:install

opened 04:23PM - 21 Dec 22 UTC

cgwalters

+1841 -12

Usage example with `/dev/vda` being an extra mounted disk: ``` $ podman run …--privileged --pid=host --net=none --security-opt label=type:unconfined_t quay.io/cgwalters/c9s-oscore:latest bootc install /dev/vda ``` # Code and high level design This merges a lot of code and logic from coreos-installer, coreos-assembler and some bits of fedora-coreos-config. Unlike ostree, `bootc install` understands and manipulates block devices and bootloaders. - coreos-installer: ignition and blockdev.rs code - coreos-assember: sgdisk invocations and ostree repo setup translated to Rust - fedora-coreos-config: Things like transposefs, boot/root uuid handling are now done on the "install boot" here Note this obviates much of the need for [generating disk images](https://github.com/coreos/fedora-coreos-tracker/issues/1151). That said, it may also make sense to have `bootc install generate-iso`.  TODO items: - Add support for e.g. `--copy-network` type flows as well as https://github.com/containers/bootc/issues/22 - Implement ppc64le and s390x (needs code from both coreos-assembler and coreos-installer) - support installing from SELinux-disabled hosts (needs https://github.com/ostreedev/ostree/issues/2804 ) - Support *overwriting* disk we used to boot (`systemctl switch-root` to container image?) - Support basic partition configs (e.g. `/var`) - Related, investigate https://www.freedesktop.org/software/systemd/man/systemd-repart.html - Also support running Ignition from the "install boot"; this would make debugging Ignition configs *dramatically* nicer - Ensure we lock devices when partitioning https://systemd.io/BLOCK_DEVICE_LOCKING/ - Support config files (e.g. distro default filesystem specified in `/usr/lib/bootc/install.cfg`) - Support (or default) to only installing EFI if booted that way, etc. - Support systemd-boot - Clean up/refactor install code to be more distribution-independent in general - Consider merging bootupd in here as e.g. `bootc bootloader update` or so? - Documentation - Tests - More explicitly test host/target kernel compatibility (e.g. filesystems) Closes: https://github.com/containers/bootc/issues/24 Closes: https://github.com/containers/bootc/issues/1