Title here
Summary here
Which install guide
Corium ships one image. The target platform decides how you get the image there, and how the node learns what it is. Find the row that matches your target.
| Your target | Guide | How configuration reaches the node |
|---|---|---|
| Proxmox, KVM or libvirt | Proxmox | cloud-init, from a snippet on the host |
| An OpenStack cloud | OpenStack | cloud-init, through the metadata service |
| A desktop PC, a tower or a mini-PC in front of you | Bare metal | A NoCloud seed on a second USB stick |
| A dedicated server that you reach through the rescue system of a provider | Rescue mode | A seed that you write to the disk before first boot |
| Any other cloud or hypervisor | Quick start | cloud-init user-data |
| PXE, or bare metal with no seed device | Quick start | /etc/corium/config.yaml or the kernel command line |
When one node works, you can continue with these guides:
| What you want | Guide |
|---|---|
| Three controllers that continue to work if one fails | HA cluster |
| A cluster split across two sites or providers | Stretched cluster |
| Your own image, with your agents or drivers in it | Building your own image |
Before any of them
Get the artefacts. Downloads tells you where the project publishes the installer ISO and the qcow2. It also explains why nothing is attached to the GitHub release, and how to check that what you received is what the project published. Every guide below assumes that you did this.
Know which artefact you need:
| Artefact | Use it for |
|---|---|
| qcow2 disk | Proxmox, KVM, libvirt, and the import paths of most clouds |
| Installer ISO | Bare metal. Installs without an operator, and you do not write a kickstart |
| The OCI image | bootc install to-disk from a rescue system, and derived images |
Read the model if you want to. Concepts explains the filesystem contract and what happens on first boot. If you read it first, each guide is shorter. If you skip it, you lose nothing until something surprises you.
What every guide assumes
- A node configuration.
roleis the only required field. A node that waits for someone to tell it what it is can leave out evenrole( §3.2). See examples for complete documents, and the configuration reference for every field. - A way to log in. cloud-init creates the login user. A node that boots with no configuration has no account to log in to. It is a host, not a Kubernetes node. This is a supported result, not a failure.
- Approximately one minute from power-on to a single node that is
Ready.
When it does not work
Troubleshooting lists the failures by symptom for every install path.