Ejecutar Fedora CoreOS directamente desde la RAM

El entorno vivo Fedora CoreOS es una copia totalmente funcional de Fedora CoreOS. Puede aprovisionar a través de Ignition, ejecutar contenedores, etc. El entorno vivo puede ser usado para instalar Fedora CoreOS en el disco y también puede ser usado para ejecutar Fedora CoreOS directamente desde RAM.

Esta guía muestra como arrancar un sistema Fedora CoreOS (FCOS) transitorio por medio de ISO, PXE o iPXE. Para más sobre las imágenes vivas ISO y PXE, vea la referencia de imagen viva.

Requisitos previos

Antes de arrancar FCOS, usted debe tener un archivo de configuración Ignition. Si no tiene uno, vea Producir un Archivo Ignition.

If you’re booting from PXE or iPXE, you must host the Ignition config on a reachable HTTP(S) or TFTP server. Booting the live PXE image requires at least 2 GiB of RAM with the coreos.live.rootfs_url kernel argument, and 4 GiB otherwise.

Booting via ISO

The live ISO image can be booted from a physical DVD disc, from a USB stick, or from a virtual CD drive via lights-out management (LOM) firmware.

To boot from the ISO image, follow these steps:

  • Download the ISO image:

    podman run --security-opt label=disable --pull=always --rm -v .:/data -w /data \
        quay.io/coreos/coreos-installer:release download -f iso
  • Use coreos-installer iso customize to customize the ISO for your needs. In this example we assume an Ignition config exists in a file config.ign. We also add the optional coreos.liveiso.fromram kernel argument to the live boot.

    The coreos.liveiso.fromram is optional and is used in cases where you want to have no references to the booted media (ISO) once the system is up and running. This enables use cases like removing the media after boot or rewriting the disk the booted media is on, but does require more memory.
    KERNEL_ARG='--live-karg-append=coreos.liveiso.fromram'
    IGNITION_ARG='--live-ignition=./config.ign'
    podman run --security-opt label=disable --pull=always --rm -v .:/data -w /data \
        quay.io/coreos/coreos-installer:release iso customize $KERNEL_ARG $IGNITION_ARG \
        -o customized.iso fedora-coreos-41.20250130.3.0-live.x86_64.iso
  • Grabe el ISO a disco. En Linux y macOS, puede usar dd. En Windows, puede usar Rufus en modo "Imagen DD".

  • Boot it on the target system.

Booting via PXE

To boot from PXE, follow these steps:

  • Descargue un kernel FCOS PXE, initramfs y una imagen de rootfs:

podman run --security-opt label=disable --pull=always --rm -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release download -f pxe
  • Follow this example pxelinux.cfg for booting the installer images with PXELINUX and running Ignition:

DEFAULT pxeboot
TIMEOUT 20
PROMPT 0
LABEL pxeboot
    KERNEL fedora-coreos-41.20250130.3.0-live-kernel-x86_64
    APPEND initrd=fedora-coreos-41.20250130.3.0-live-initramfs.x86_64.img,fedora-coreos-41.20250130.3.0-live-rootfs.x86_64.img ignition.firstboot ignition.platform.id=metal ignition.config.url=http://192.168.1.101/config.ign
IPAPPEND 2

Booting via iPXE

Una máquina compatible con iPXE debe contar con un Script de Inicio relevante para recuperar y cargar artefactos FCOS.

El ejemplo de abajo muestra como cargar estos directamente desde la infraestructura de Fedora. Por razones de rendimiento y fiabilidad se recomienda duplicarlos en la infraestructura local y después modificar BASEURL según sea necesario.

#!ipxe

set STREAM stable
set VERSION 41.20250130.3.0
set CONFIGURL https://example.com/config.ign

set BASEURL https://builds.coreos.fedoraproject.org/prod/streams/${STREAM}/builds/${VERSION}/x86_64

kernel ${BASEURL}/fedora-coreos-${VERSION}-live-kernel-x86_64 initrd=main coreos.live.rootfs_url=${BASEURL}/fedora-coreos-${VERSION}-live-rootfs.x86_64.img ignition.firstboot ignition.platform.id=metal ignition.config.url=${CONFIGURL}
initrd --name main ${BASEURL}/fedora-coreos-${VERSION}-live-initramfs.x86_64.img

boot

Using persistent state

By default, the Fedora CoreOS live environment does not store any state on disk, and is reprovisioned from scratch on every boot. However, you may choose to store some persistent state (such as container images) in a filesystem that persists across reboots. For example, here’s a Butane config that configures a persistent /var:

variant: fcos
version: 1.1.0
storage:
  disks:
    - device: /dev/sda
      wipe_table: true
      partitions:
        - label: var
  filesystems:
    - device: /dev/disk/by-partlabel/var
      label: var
      format: xfs
      wipe_filesystem: false
      path: /var
      with_mount_unit: true

When booting a live environment, the Ignition config runs on every boot, so it should avoid wiping LUKS volumes and filesystems that you want to reuse. Instead, configure such structures so that they’re created on the first boot and preserved on subsequent boots.

In particular, note the following guidelines:

  • Avoid setting wipe_filesystem or wipe_volume for filesystems or LUKS volumes that you intend to reuse. (You can safely set wipe_table or wipe_partition_entry when reusing a disk, since those don’t modify the contents of a partition.)

  • When reusing LUKS volumes, you must configure a key_file. Ignition cannot reuse Clevis-backed LUKS volumes.

  • Avoid writing persistent data to RAID volumes, since Ignition cannot reuse those.

  • When writing files in persistent storage, set overwrite to true to avoid Ignition failures when reusing a filesystem that already has the file. Avoid using the append directive for persistent files, since the append operation will occur on every boot.

Update process

Since the traditional FCOS upgrade process requires a disk, the live environment is not able to auto-update in place. For this reason, Zincati is not running there.

For PXE-booted systems, it is recommended that images referenced in the PXE configuration are regularly refreshed. Once infrastructure and configurations are updated, the live PXE instance only needs to be rebooted in order to start running the new FCOS version.

For ISO-booted systems, the ISO image used to boot the live environment should be periodically refreshed, and the instance rebooted to update the running OS.