Configurar almacenamiento

Fedora CoreOS se envía con un sencillo esquema de almacenamiento predeterminado: la partición raíz es la última y se expande para ocupar el tamaño completo del disco. Aparte de la partición de inicio, todos los datos se almacenan en la partición raíz. Vea la sección Disposición de disco para más detalles.

A continuación, proporcionamos ejemplos de diversas maneras de personalizar esto.

Fedora CoreOS requiere que el sistema de archivos raíz tenga al menos 8 Gb. Por razones prácticas, las imágenes de disco para algunas plataformas se envían con un sistema de archivo raíz más pequeño, que de modo predeterminado se expande automáticamente para llenar todo el espacio de disco disponible. Si usted añade particiones adicionales después del sistema de archivos raíz, debe asegurarse de cambiar explícitamente el tamaño de la partición raíz como se muestra a continuación de modo que tenga al menos 8 Gb.

Actualmente, si el sistema de archivos raíz es menor de 8 Gb se emite una advertencia en el arranque. A partir de Junio de 2021, si el sistema de archivos raíz es menor de 8 Gb y está seguido por otra partición, Fedora CoreOS se negará a arrancar. Para más detalles, vea este error.

Referencia de dispositivos de bloque desde Ignition

Muchos de los ejemplos siguientes harán referencia a un dispositivo de bloque como /dev/vda. El nombre del dispositivo de bloque disponible depende de la infraestructura subyacente (bare metal contra nube) y con frecuencia del tipo específico de instancia. Por ejemplo en AWS, algunos tipos de instancia tienen dispositivos NVMe (/dev/nvme*), otros usan /dev/xvda*.

Si su configuración de disco es simple y usa el mismo disco desde el que se inició el sistema operativo se puede usar el enlace /dev/disk/by-id/coreos-boot-disk para hacer referencia conveniente a ese dispositivo. Este enlace está disponible solo durante el aprovisionamiento con el propósito de hacer más fácil referirse al mismo disco desde el que se arrancó el sistema operativo.

En los casos donde usted necesita acceder a otros discos, la cosa más sencilla de hacer es arrancar una única máquina con una configuración Ignition que solo le da acceso SSH e inspeccionar los dispositivos de bloque por medio de, por ejemplo, el comando lsblk.

Para hardware físico, una buena mejor práctica es referenciar los dispositivos por medio de /dev/disk/by-id/ o enlaces /dev/disk/by-path.

Configurar montajes /var separados

Aquí hay un ejemplo de una configuración Butane para establecer un`/var` sobre una partición separada en el mismo disco principal:

Añadir una partición /var al disco principal
variant: fcos
version: 1.5.0
storage:
  disks:
  - # El enlace al dispositivo de bloque desde el que se arrancó el sistema operativo.
    device: /dev/disk/by-id/coreos-boot-disk
    # No queremos borrar la tabla de particiones ya que este es el dispositivo
    # principal.
    wipe_table: false
    partitions:
    - number: 4
      label: root
      # Localice al menos 8 Gb para el rootfs. Vea la NOTA de arriba sobre esto.
      size_mib: 8192
      resize: true
    - size_mib: 0
      # Asignamos una etiqueta descriptiva a la partición. Esto es importante
      # para referirse a él de manera independiente en otras partes de la
      # configuración.
      label: var
  filesystems:
    - path: /var
      device: /dev/disk/by-partlabel/var
      # Seleccionamos el sistema de archivos que nos gusta.
      format: ext4
      # Pedimos a Butane que genere una unidad de montaje para nosotros de modo que
      # este sistema de archivos permanezca montado en la raíz real.
      with_mount_unit: true

Usted puede, desde luego, montar solo un subconjunto de /var en una partición separada. Por ejemplo, para montar /var/lib/containers:

Añadir una partición /var/lib/containers al disco primario
variant: fcos
version: 1.5.0
storage:
  disks:
  - device: /dev/disk/by-id/coreos-boot-disk
    wipe_table: false
    partitions:
    - number: 4
      label: root
      # Allocate at least 8 GiB to the rootfs. See NOTE above about this.
      size_mib: 8192
      resize: true
    - size_mib: 0
      label: containers
  filesystems:
    - path: /var/lib/containers
      device: /dev/disk/by-partlabel/containers
      format: xfs
      with_mount_unit: true

Alternativamente, usted también puede montar almacenamiento de un disco separado. Por ejemplo, aquí montamos /var/log desde una partición en /dev/vdb:

Añadir /var/log desde un disco secundario
variant: fcos
version: 1.5.0
storage:
  disks:
  - device: /dev/vdb
    wipe_table: false
    partitions:
    - size_mib: 0
      start_mib: 0
      label: log
  filesystems:
    - path: /var/log
      device: /dev/disk/by-partlabel/log
      format: xfs
      with_mount_unit: true
Definir un disco con múltiples particiones

En este ejemplo, limpiamos el disco y creamos dos nuevas particiones.

variant: fcos
version: 1.5.0
storage:
  disks:
    -
      # Obligatorio. Usamos el Número de ID Mundial de la unidad para asegurar
      # la unicidad.
      device: /dev/disk/by-id/wwn-0x50014e2eb507fcdf
      # Esto asegura que la tabla de partición se vuelve a crear junto con todas las
      # particiones.
      wipe_table: true
      partitions:
        # La primera partición (slot número 1) es de 32 Gb y empieza al principio
        # del dispositivo. Su type_guid la identifica como una partición Linux
        # swap.
        - label: part1
          number: 1
          size_mib: 32768
          start_mib: 0
          type_guid: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
        # La segunda partición (implícito slot número 2) se colocará después
        # de la partición 1 y ocupará el resto del espacio disponible.
        # Como no se especifica su type_guid, será una partición nativa
        #  Linux.
        - label: part2

Reconfigurar el sistema de archivos raíz

Es posible reconfigurar el sistema de archivos raíz mismo. Puede usar la ruta /dev/disk/by-label/root para referirse a la partición raíz original. Debe asegurarse que el nuevo sistema de archivos también tenga la etiqueta de root.

Debe tener al menos 4 Gb de RAM para que funcione el reaprovisionamiento raíz.

Aquí hay un ejemplo de cambiar de xfs a ext4, reutilizando la misma partición en el disco primario:

Cambiar el sistema de archivos raíz a ext4
variant: fcos
version: 1.5.0
storage:
  filesystems:
    - device: /dev/disk/by-partlabel/root
      wipe_filesystem: true
      format: ext4
      label: root

Igual que en la sección anterior, también puede mover el sistema de archivos raíz por completo. Aquí movemos la raíz a un dispositivo RAID0:

Trasladar el sistema de archivos raíz a RAID0
variant: fcos
version: 1.5.0
storage:
  raid:
    - name: myroot
      level: raid0
      devices:
        - /dev/disk/by-id/virtio-disk1
        - /dev/disk/by-id/virtio-disk2
  filesystems:
    - device: /dev/md/myroot
      format: xfs
      wipe_filesystem: true
      label: root
Usted no necesita las claves path o with_mount_unit; FCOS sabe que la partición raíz es especial y sabrá como encontrarla y montarla.

Si desea replicar el disco de arranque en múltiples dispositivos para resistir a un fallo de disco, necesita hacer espejo de todas las particiones predeterminadas (root, boot, EFI System Partition y código del cargador de arranque). Existe una sintaxis de configuración Butane especial para esto:

Haciendo espejo del disco de arranque en dos dispositivos
variant: fcos
version: 1.5.0
boot_device:
  mirror:
    devices:
      - /dev/sda
      - /dev/sdb

Definir un sistema de archivos

Este ejemplo demuestra el proceso de creación del sistema de archivos definiendo y etiquetando las particiones, combinándolas en una matriz RAID y formateando la matriz como ext4.

Definir un sistema de archivos sobre un dispositivo de almacenamiento RAID
variant: fcos
version: 1.5.0
storage:
  disks:
  # Esto define dos particiones, cada una en su propio disco. Los discos se
  # identifican por su WWN.
  - device: /dev/disk/by-id/wwn-0x50014ee261e524e4
    wipe_table: true
    partitions:
    -
      # Cada partición obtiene una etiqueta legible por las personas.
      label: "raid.1.1"
      # Cada partición se sitúa al principio del disco y tiene 64 Gb
      # long.
      number: 1
      size_mib: 65536
      start_mib: 0
  - device: /dev/disk/by-id/wwn-0x50014ee0b8442cd3
    wipe_table: true
    partitions:
    - label: "raid.1.2"
      number: 1
      size_mib: 65536
      start_mib: 0
  # Usamos las particiones previamente definidas como dispositivos en una matriz RAID1 md.
  raid:
    - name: publicdata
      level: raid1
      devices:
      - /dev/disk/by-partlabel/raid.1.1
      - /dev/disk/by-partlabel/raid.1.2
  # La matriz md resultante se usa para crear un sistema de archivos EXT4.
  filesystems:
    - path: /var/publicdata
      device: /dev/md/publicdata
      format: ext4
      label: PUB
      with_mount_unit: true

Almacenamiento cifrado (LUKS)

Este es un ejemplo de cómo configurar un dispositivo LUKS en /var/lib/data.

variant: fcos
version: 1.5.0
storage:
  luks:
    - name: data
      device: /dev/vdb
  filesystems:
    - path: /var/lib/data
      device: /dev/mapper/data
      format: xfs
      label: DATA
      with_mount_unit: true

El sistema de archivos raíz también se puede mover a LUKS. En este caso, el dispositivo LUKS debe tener pines Clevis. Hay dos tipos de pines disponibles: TPM2 y Tang (o una combinación de los que usan Shamir Secret Sharing).

Los pines TPM2 simplemente vinculan el cifrado a la máquina física en uso. Asegúrese de comprender su modelo de amenaza antes de elegir entre pines TPM2 y Tang. Para más información, vea esta sección de la documentación de pin Clevis TPM2.
Debe tener al menos 4 Gb de RAM para que funcione el reaprovisionamiento raíz.

Esta es una sintaxis de configuración Butane simplificada para configurar el cifrado y los pines del sistema de archivos raíz. A continuación un ejemplo de uso para crear un sistema de archivos raíz cifrado con pines TPM2:

Cifrar el sistema de archivos raíz con un pin TPM2 Clevis
variant: fcos
version: 1.5.0
boot_device:
  luks:
    tpm2: true

Esto es equivalente a la siguiente configuración expandida:

Cifrando el sistema de archivos root con un pin TPM2 Clevis pin sin usar boot_device
variant: fcos
version: 1.5.0
storage:
  luks:
    - name: root
      label: luks-root
      device: /dev/disk/by-partlabel/root
      clevis:
        tpm2: true
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      wipe_filesystem: true
      label: root

La configuración expandida no incluye las claves`path` o with_mount_unit; FCOS sabe que la partición raíz es especial y descubrirá como encontrarla y montarla.

Este siguiente ejemplo vincula el cifrado del sistema de archivos raíz a PCR 7 que corresponde al Componente de Arranque UEFI utilizado para rastrear el certificado Secure Boot (Arranque Seguro) desde la memoria. Por lo tanto, las actualizaciones de firmware/certificados UEFI no deberían afectar al valor almacenado en PCR 7.

El vínculo para PCR 8 (UEFI Boot Component (Componente de Arranque UEFI usado para rastrear comandos y la línea de comandos del kernel) no está soportado puesto que la línea de comando del kernel cambia con cada actualización del sistema operativo.
Cifrado del sistema de archivos raíz con pin TPM2 Clevis vinculado a PCR 7
variant: fcos
version: 1.5.0
storage:
  luks:
    - name: root
      label: luks-root
      device: /dev/disk/by-partlabel/root
      clevis:
        custom:
          needs_network: false
          pin: tpm2
          config: '{"pcr_bank":"sha1","pcr_ids":"7"}'
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      wipe_filesystem: true
      label: root

Se puede encontrar más documentación de los campos config en las páginas de manual de clevis: man clevis-encrypt-tpm2

Se puede usar el siguiente comando clevis para confirmar que el cifrado del sistema de archivos raíz se vincula a PCR 7.

$ sudo clevis luks list -d /dev/disk/by-partlabel/root
1: tpm2 '{"hash":"sha256","key":"ecc","pcr_bank":"sha1","pcr_ids":"7"}'

A continuación un ejemplo de la sintaxis de configuración simplificada con Tang:

Cifrado del sistema de archivos raíz con pin Tang Clevis
variant: fcos
version: 1.5.0
boot_device:
  luks:
    tang:
      - url: http://192.168.122.1:80
        thumbprint: bV8aajlyN6sYqQ41lGqD4zlhe0E

El sistema contactará con el servidor Tang en el arranque.

Para más información sobre la configuración del servidor Tang vea la documentación upstream.

Usted puede configurar los pines de Tang y TPM2 (incluyendo múltiples servidores Tang para redundancia). De forma predeterminada, solo el dispositivo TPM2 o un único servidor Tang es necesario para desbloquear el sistema de archivos raíz. Esto se puede cambiar usando la clave threshold:

Cifrado del sistema de archivos raíz con pines TPM2 y Tang
variant: fcos
version: 1.5.0
boot_device:
  luks:
    tang:
      - url: http://192.168.122.1:80
        thumbprint: bV8aajlyN6sYqQ41lGqD4zlhe0E
    tpm2: true
    # esto permitirá a rootfs desbloquear solo si los pines TPM2 y Tang están
    # accesibles y son válidos
    threshold: 2

Dimensionando la partición raíz

Si utiliza Ignition para volver a configurar o mover la partición raíz, esta partición no crece automáticamente en el primer arranque (vea las discusiones relacionadas en esta cuestión). En el caso de mover la partición raíz a un nuevo disco (o múltiples discos), debería establecer el tamaño de partición deseado usando el campo size_mib. Si vuelve a configurar el sistema de archivos raíz en su lugar, como en el ejemplo LUKS de arriba, puede volver a dimensionar la partición existente usando el campo resize:

Volver a dimensionar la partición raíz a su máximo tamaño
variant: fcos
version: 1.5.0
storage:
  disks:
    - device: /dev/disk/by-id/coreos-boot-disk
      partitions:
        - label: root
          number: 4
          # 0 means to use all available space
          size_mib: 0
          resize: true
  luks:
    - name: root
      device: /dev/disk/by-partlabel/root
      clevis:
        tpm2: true
      wipe_volume: true
  filesystems:
    - device: /dev/mapper/root
      format: xfs
      wipe_filesystem: true
      label: root

Añadir swap

Este ejemplo crea una partición swap que abarca todo el dispositivo sdb, crea un área swap sobre ella y crea una unidad swap en systemd de modo que el área swap se habilita al arranque.

Configurar una partición swap sobre un segundo disco
variant: fcos
version: 1.5.0
storage:
  disks:
    - device: /dev/sdb
      wipe_table: true
      partitions:
        - number: 1
          label: swap
  filesystems:
    - device: /dev/disk/by-partlabel/swap
      format: swap
      wipe_filesystem: true
      with_mount_unit: true

Añadir almacenamiento en red

Los sistemas Fedora CoreOS pueden ser configurados para montar sistemas de archivos en red como NFS y CIFS. Esto se alcanza mejor utilizando Ignition para crear unidades systemd. Los sistemas de archivos pueden ser montados en el arranque creando una unidad estándar de montaje. Alternativamente, un sistema de archivos puede ser montado cuando los usuarios acceden a un punto de montaje mediante la creación de una unidad adicional de auto-montaje. A continuación están ejempos de cada uno para un sistema de archivos NFS.

Configurar montajes NFS

Crear una unidad systemd para montar un sistema de archivos NFS en el arranque.
El archivo .mount debe tener un nombre según la ruta (por ejemplo /var/mnt/data = var-mnt-data.mount) 
variant: fcos
version: 1.3.0
systemd:
  units:
    - name: var-mnt-data.mount
      enabled: true
      contents: |
        [Unit]
        Description=Mount data directory

        [Mount]
        What=example.org:/data
        Where=/var/mnt/data
        Type=nfs4

        [Install]
        WantedBy=multi-user.target
Crear una unidad systemd para montar un sistema de archivos NFS cuando los usuarios acceden al punto de montaje (automount)
variant: fcos
version: 1.3.0
systemd:
  units:
    - name: var-mnt-data.mount
      contents: |
        [Unit]
        Description=Mount data directory

        [Mount]
        What=example.org:/data
        Where=/var/mnt/data
        Type=nfs4

        [Install]
        WantedBy=multi-user.target

    - name: var-mnt-data.automount
      enabled: true
      contents: |
        [Unit]
        Description=Automount data directory

        [Automount]
        TimeoutIdleSec=20min
        Where=/var/mnt/data

        [Install]
        WantedBy=multi-user.target

Ejemplos avanzados

Este ejemplo configura un disco de arranque reflejado con un sistema de archivos cifrado con TPM2, anula los tamaños de las replicas de la partición raíz generada automáticamente y añade un partición /var reflejada cifrada que consume el resto de los discos.

Disco de arranque reflejado cifrado con /var separado
variant: fcos
version: 1.5.0
boot_device:
  luks:
    tpm2: true
  mirror:
    devices:
      - /dev/sda
      - /dev/sdb
storage:
  disks:
    - device: /dev/sda
      partitions:
        # Anular el tamaño de la partición raíz en el primer disco, por medio de la
        # etiqueta generada por boot_device.mirror
        - label: root-1
          size_mib: 10240
        # Añadir una nueva partición llenando el resto del disco
        - label: var-1
    - device: /dev/sdb
      partitions:
        # Similarly for second disk
        - label: root-2
          size_mib: 10240
        - label: var-2
  raid:
    - name: md-var
      level: raid1
      devices:
        - /dev/disk/by-partlabel/var-1
        - /dev/disk/by-partlabel/var-2
  luks:
    - name: var
      device: /dev/md/md-var
      # No se ha especificado clave material, de modo que será generada una clave
      # aleatoria y almacenada en el sistema de archivos raíz
  filesystems:
    - device: /dev/mapper/var
      path: /var
      label: var
      format: xfs
      wipe_filesystem: true
      with_mount_unit: true

Diseño del disco

Todos los sistemas Fedora CoreOS empiezan con la misma imagen de disco que varía ligeramente entre arquitecturas en base a lo que necesitan para la carga de arranque. En el primer arranque el sistema de archivos raíz se expande para llenar el resto del disco. La imagen de disco se puede personalizar usando configuraciones Butane para reparticionar el disco y crear/reformatear sistemas de archivos. Las instalaciones de metal desnudo no son diferentes; el instalador solo copia la imagen cruda en el disco objetivo e inyecta la configuración especificada en /boot para su uso en el primer arranque.

Vea en Reconfigurar el sistema de archivos raíz ejemplos sobre los cambios en la partición raíz soportados.

Tabla de particiones

La utilización de números para referirse a particiones específicas está desaconsejado en su lugar se deberían usar etiquetas o UUIDs. Fedora CoreOS reserva las etiquetas boot, boot-<number>, root, root-<number>, BIOS-BOOT, bios-<number>, EFI-SYSTEM y esp-<number> y los nombres de dispositivos RAID md-boot y md-root RAID. La creación de particiones, sistemas de archivos o dispositivos RAID con esas etiquetas no se admite.

Tabla de Partición x86_64

La imagen de disco x86_64 está formateada como con un MBR protector. Admite el arranque por medio de BIOS y UEFI (incluyendo Secure Boot).

El diseño de la tabla de partición ha cambiado con el tiempo. El diseño actual es:

Table 1. Tabla de Partición para x86_64

Número

Etiqueta

Descripción

Tipo de partición

1

BIOS-BOOT

Contiene imagen BIOS GRUB

datos crudos

2

EFI-SYSTEM

Contiene imagen EFI GRUB y corrector Secure Boot

FAT32

3

boot

Contiene configuración GRUB, imágenes kernel/initramfs

ext4

4

root

Contiene el sistema de archivos raíz

xfs

La partición EFI-SYSTEM puede ser borrada o reformateada cuando haya arranque BIOS. Del mismo modo, la partición BIOS-BOOT puede ser borrada o reformateada cuando haya arranque EFI.

Sistemas de archivos montados

Fedora CoreOS utiliza OSTree, que es un sistema para la administración de múltiples árboles de sistemas operativos arrancables que comparten almacenamiento. Cada versión de sistema operativo es parte del sistema de archivos`/. Todas las implementaciones comparten el mismo `/var que puede estar en el mismo sistema de archivos o montado separadamente.

Esto muestra los puntos de montaje predeterminados para un sistema Fedora CoreOS instalado sobre un disco /dev/vda:

Puntos de montaje predeterminados sobre x86_64
$ findmnt --real # Some details are elided
TARGET        SOURCE                                                   FSTYPE  OPTIONS
/             /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash]     xfs     rw
|-/sysroot    /dev/vda4                                                xfs     ro
|-/etc        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/etc] xfs     rw
|-/usr        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/$hash/usr] xfs     ro
|-/var        /dev/vda4[/ostree/deploy/fedora-coreos/deploy/var]       xfs     rw
`-/boot       /dev/vda3                                                ext4    ro

La Partición de Sistema EFI se montaba anteriormente sobre /boot/efi pero ya no es así. Sobre sistemas configurados con dispositivo de arranque en espejo, hay particiones EFI independientes sobre cada disco constituyente.

/ inmutable, /usr solo lectura

Como OSTree se utiliza para administrar todos los archivos que pertenecen al sistema operativo, no se puede escribir en los puntos de montaje / y /usr. Cualquier cambio en el sistema operativo debería ser aplicado por medio de rpm-ostree.

Del mismo modo, no se puede escribir en el punto de montaje /boot y la EFI System Partition no se monta de forma predeterminada. Estos sistemas de archivo son administrados por rpm-ostree y bootupd y no deben ser modificados directamente por un administrador.

Actualmente no se admite la adición de directorios de nivel superior (esto es /foo) y el atributo inmutable no lo permite.

El / real (como en la raíz del sistema de archivos en la partición root) está montado en solo lectura en /sysroot y no debe ser accedido o modificado directamente.

Configuración en /etc y estado en /var

Las únicas ubicaciones de lectura admitidas son /etc y /var. /etc debería contener solo archivos de configuración y no se espera que almacene datos. Todos los datos se deben mantener bajo /var y no serán tocados por las actualizaciones del sistema. Los lugares tradicionales que pudieran albergar datos (por ejemplo /home o /srv) son enlaces simbólicos a directorios en /var (por ejemplo /var/home o /var/srv).

Selección de versión y arranque

Se crea una entrada de menú GRUB por cada versión de Fedora CoreOS disponible en un sistema. Esta entrada de menú hace referencia a una implementación ostree que consta de un kernel Linux, un initramfs y un hash que enlaza a un compromiso ostree (pasado por medio del argumento del kernel ostree=). Durante el arranque, ostree leerá este argumento del kernel para determinar que implementación usar como sistema de archivos raíz. Cada actualización o cambio en el sistema (instalación de paquete, añadido de argumentos de kernel) crea una nueva implementación. Esto permite la vuelta atrás a implementaciones anteriores si la actualización causa problemas.

Want to help? Learn how to contribute to Fedora Docs ›