ultra980
(Alex Stan)
January 4, 2023, 6:57pm
1
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 Package danora · GitHub (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!
1 Like
vwbusguy
(Scott Williams)
January 4, 2023, 10:01pm
2
It looks like this current topic on our discussion site is relevant. Seems someone recently figured out how to do this there:
Tested with a fresh install of F37 KDE spin, and it works.
(with the original /var:/var, logon with normal user do not work - it return to logon screen immediately, but with root user is OK)
Thank you very much, it is really interesting.
ultra980
(Alex Stan)
January 5, 2023, 6:11am
3
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
(Jorge Castro)
January 7, 2023, 8:38pm
4
Ok been doing some digging and I think I found some good background info:
opened 04:00PM - 03 Apr 22 UTC
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.
containers:main
← cgwalters:install
opened 04:23PM - 21 Dec 22 UTC
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`.
<!--
Command run to test:
umount /mnt; export h=/run/hostsrv/src/github && (test -w /usr || rpm-ostree usroverlay) && install /run/hostsrv/src/github/containers/skopeo/bin/skopeo /usr/bin && podman run --pull=newer --rm -ti --privileged --pid=host --net=none -v $h/containers/bootc/target/release/bootc:/usr/bin/bootc -v $h/coreos/bootupd/target/release/bootupd:/usr/bin/bootupctl -v /run/hostsrv:/run/hostsrv:ro quay.io/cgwalters/fcos bootc install --wipe /dev/vdb --ignition-file /run/hostsrv/src/github/cgwalters/playground/fcct/ssh-basic.ign
-->
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
2 Likes