Configurando o armazenamento

Fedora CoreOS vem com um layout de armazenamento simples: a partição raiz é a última e se expande para tomar todo o disco. Desconsiderando a partição de inicialização, todos os dados são armazenados na partição raiz. Veja a seção de layout de discos para mais detalhes.

Abaixo, nós provemos exemplos de várias maneiras que você pode personalizar isso.

O Fedora CoreOS requer que o sistema de arquivos raiz tenha pelo menos 8 GiB. Por razões práticas, as imagens de disco para algumas plataformas vêm com um sistema de arquivos raiz menor, que por padrão se expande automaticamente para preencher todo o espaço em disco disponível. Se você adicionar partições adicionais após o sistema de arquivos raiz, deve certificar-se de redimensionar explicitamente a partição raiz conforme mostrado abaixo para que tenha pelo menos 8 GiB.

Atualmente, se o sistema de arquivos raiz for menor que 8 GiB, um aviso é emitido ao se autenticar. A partir de junho de 2021, se o sistema de arquivos raiz for menor que 8 GiB e for seguido por outra partição, o Fedora CoreOS se recusará a inicializar. Para obter mais detalhes, consulte este bug.

Fazendo referência a dispositivos de bloco do Ignition

Many of the examples below will reference a block device, such as /dev/vda. The name of the available block devices depends on the underlying infrastructure (bare metal vs cloud), and often the specific instance type. For example in AWS, some instance types have NVMe drives (/dev/nvme*), others use /dev/xvda*.

If your disk configuration is simple and uses the same disk the OS was booted from then the /dev/disk/by-id/coreos-boot-disk link can be used to conveniently refer to that device. This link is only available during provisioning for the purpose of making it easy to refer to the same disk the OS was booted from.

If you need to access other disks, you can boot a single machine with an Ignition configuration with only SSH access, and then inspect the block devices via e.g. the lsblk command.

For physical hardware, it is recommended to reference devices via the /dev/disk/by-id/ or /dev/disk/by-path links.

Configurando montagens /var separadas

Here’s an example Butane config to set up /var on a separate partition on the same primary disk:

Adicionando uma partição /var ao disco primário

variant: fcos
version: 1.5.0
storage:
  disks:
  - # The link to the block device the OS was booted from.
    device: /dev/disk/by-id/coreos-boot-disk
    # We do not want to wipe the partition table since this is the primary
    # device.
    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
      # We assign a descriptive label to the partition. This is important
      # for referring to it in a device-agnostic way in other parts of the
      # configuration.
      label: var
  filesystems:
    - path: /var
      device: /dev/disk/by-partlabel/var
      # We can select the filesystem we'd like.
      format: ext4
      # Ask Butane to generate a mount unit for us so that this filesystem
      # gets mounted in the real root.
      with_mount_unit: true

Você pode (claramente) montar apenas um subdiretório de /var em uma partição separada. Como, por exemplo, montar /var/lib/containers:

Adicionando uma partição /var/lib/containers ao disco primário

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, você também pode montar o armazenamento de um disco separado. Por exemplo, aqui nós montamos /var/log por uma partição em /dev/vdb:

Adicionando /var/log de um disco secundário

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

Definindo um disco com várias partições

Neste exemplo, nós apagamos o disco e criamos duas partições novas.

variant: fcos
version: 1.5.0
storage:
  disks:
    -
      # Mandatory. We use the World-Wide Number ID of the drive to ensure
      # uniqueness.
      device: /dev/disk/by-id/wwn-0x50014e2eb507fcdf
      # This ensures that the partition table is re-created, along with all
      # the partitions.
      wipe_table: true
      partitions:
        # The first partition (slot number 1) is 32 GiB and starts at the
        # beginning of the device. Its type_guid identifies it as a Linux
        # swap partition.
        - label: part1
          number: 1
          size_mib: 32768
          start_mib: 0
          type_guid: 0657fd6d-a4ab-43c4-84e5-0933c84b4f4f
        # The second partition (implicit slot number 2) will be placed after
        # partition 1 and will occupy the rest of the available space.
        # Since type_guid is not specified, it will be a Linux native
        # partition.
        - label: part2

Reconfigurando o sistema de arquivos raiz

É possível reconfigurar o sistema de arquivos raiz. Você pode usar o caminho /dev/disk/by-label/root para se referir à partição raiz original. Você deve ter certeza que o novo sistema de arquivos também tem um rótulo /root.

You must have at least 4 GiB of RAM for root reprovisioning to work.

Aqui está um exemplo de migração de xfs para ext4, mas usando a mesma partição no disco primário:

Mudando o sistema de arquivos raiz para ext4

variant: fcos
version: 1.5.0
storage:
  filesystems:
    - device: /dev/disk/by-partlabel/root
      wipe_filesystem: true
      format: ext4
      label: root

Similar à seção anterior, você também pode mover o sistema de arquivos raiz inteiramente. Aqui, estamos movendo a raiz para um dispositivo RAID1:

Movendo o sistema de arquivos raiz para 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

Você não precisa das chaves path ou with_mount_unit; FCOS sabe que a partição raiz é especial e irá descobrir como encontrá-la e montá-la.

If you want to replicate the boot disk across multiple drives for resiliency to drive failure, you need to mirror all the default partitions (root, boot, EFI System Partition, and bootloader code). There is special Butane config syntax for this:

Espelhando o disco de inicialização em duas unidades

variant: fcos
version: 1.5.0
boot_device:
  mirror:
    devices:
      - /dev/sda
      - /dev/sdb

Defining a filesystem

Este exemplo demonstra o processo de criação do sistema de arquivos definindo e rotulando as partições, combinando-as em um arranjo RAID e formatando esse arranjo como ext4.

Definindo um sistema de arquivos em um dispositivo de armazenamento RAID

variant: fcos
version: 1.5.0
storage:
  disks:
  # This defines two partitions, each on its own disk. The disks are
  # identified by their WWN.
  - device: /dev/disk/by-id/wwn-0x50014ee261e524e4
    wipe_table: true
    partitions:
    -
      # Each partition gets a human-readable label.
      label: "raid.1.1"
      # Each partition is placed at the beginning of the disk and is 64 GiB
      # 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
  # We use the previously defined partitions as devices in a RAID1 md array.
  raid:
    - name: publicdata
      level: raid1
      devices:
      - /dev/disk/by-partlabel/raid.1.1
      - /dev/disk/by-partlabel/raid.1.2
  # The resulting md array is used to create an EXT4 filesystem.
  filesystems:
    - path: /var/publicdata
      device: /dev/md/publicdata
      format: ext4
      label: PUB
      with_mount_unit: true

Armazenamento criptografado (LUKS)

Aqui está um exemplo de como configurar um dispositivo LUKS em /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

The root filesystem can also be moved to LUKS. In that case, the LUKS device must be pinned by Clevis. There are two primary pin types available: TPM2 and Tang (or a combination of those using Shamir Secret Sharing).

TPM2 pinning just binds encryption to the physical machine in use. Make sure to understand its threat model before choosing between TPM2 and Tang pinning. For more information, see this section of the Clevis TPM2 pin documentation.

You must have at least 4 GiB of RAM for root reprovisioning to work.

There is simplified Butane config syntax for configuring root filesystem encryption and pinning. Here is an example of using it to create a TPM2-pinned encrypted root filesystem:

Encrypting the root filesystem with a TPM2 Clevis pin

variant: fcos
version: 1.5.0
boot_device:
  luks:
    tpm2: true

Isso é equivalente à seguinte configuração expandida:

Encrypting the root filesystem with a TPM2 Clevis pin without using 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

A configuração expandida não inclui as chaves path ou with_mount_unit; FCOS sabe que a partição raiz é especial e irá descobrir como encontrá-la e montá-la.

This next example binds the root filesystem encryption to PCR 7 which corresponds to the UEFI Boot Component used to track the Secure Boot certificate from memory. Therefore, updates to the the UEFI firmware/certificates should not affect the value stored in PCR 7.

Binding for PCR 8 (UEFI Boot Component used to track commands and kernel command line) is not supported as the kernel command line changes with every OS update.

Encrypting the root filesystem with a TPM2 Clevis pin bound to 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

More documentation for the config fields can be found in the clevis man pages: man clevis-encrypt-tpm2

The following clevis command can be used to confirm that the root file system encryption is bound to PCR 7.

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

Here is an example of the simplified config syntax with Tang:

Encrypting the root filesystem with a Tang Clevis pin

variant: fcos
version: 1.5.0
boot_device:
  luks:
    tang:
      - url: http://192.168.122.1:80
        thumbprint: bV8aajlyN6sYqQ41lGqD4zlhe0E

The system will contact the Tang server on boot.

For more information about setting up a Tang server, see the upstream documentation.

You can configure both Tang and TPM2 pinning (including multiple Tang servers for redundancy). By default, only the TPM2 device or a single Tang server is needed to unlock the root filesystem. This can be changed using the threshold key:

Encrypting the root filesystem with both TPM2 and Tang pins

variant: fcos
version: 1.5.0
boot_device:
  luks:
    tang:
      - url: http://192.168.122.1:80
        thumbprint: bV8aajlyN6sYqQ41lGqD4zlhe0E
    tpm2: true
    # this will allow rootfs unlocking only if both TPM2 and Tang pins are
    # accessible and valid
    threshold: 2

Dimensionando a partição raiz

Se você usar o Ignition para reconfigurar ou mover a partição raiz, essa partição não aumenta automaticamente na primeira inicialização (consulte as discussões relacionadas em este problema) . No caso de mover a partição raiz para um novo disco (ou vários discos), você deve definir o tamanho da partição desejada usando o campo size_mib. Se reconfigurar o sistema de arquivos raiz no local, como no exemplo LUKS acima, você pode redimensionar a partição existente usando o campo resize:

Redimensionando a partição raiz para seu tamanho máximo

variant: fcos
version: 1.5.0
storage:
  disks:
    - device: /dev/vda
      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

Adicionando swap

Este exemplo cria uma partição swap abrangendo todo o dispositivo sdb, cria uma área swap nela e cria uma unidade swap de systemd para que a área swap seja habilitada na inicialização.

Configurando uma partição swap em um 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

Adding network storage

Fedora CoreOS systems can be configured to mount network filesystems such as NFS and CIFS. This is best achieved by using Ignition to create systemd units. Filesystems can be mounted on boot by creating a standard mount unit. Alternatively, a filesystem can be mounted when users access the mountpoint by creating an additional automount unit. Below are examples of each for an NFS filesystem.

Configuring NFS mounts

Creating a systemd unit to mount an NFS filesystem on boot.

The .mount file must be named based on the path (e.g. /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

Creating a systemd unit to mount an NFS filesystem when users access the mount point (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

Exemplos avançados

Este exemplo configura um disco de inicialização espelhado com um sistema de arquivos raiz criptografado por TPM2, substitui os tamanhos das réplicas de partição raiz geradas automaticamente e adiciona uma partição espelhada /var criptografada que consome o restante dos discos.

Disco de inicialização espelhado criptografado com /var separada

variant: fcos
version: 1.5.0
boot_device:
  luks:
    tpm2: true
  mirror:
    devices:
      - /dev/sda
      - /dev/sdb
storage:
  disks:
    - device: /dev/sda
      partitions:
        # Override size of root partition on first disk, via the label
        # generated for boot_device.mirror
        - label: root-1
          size_mib: 8192
        # Add a new partition filling the remainder of the disk
        - label: var-1
    - device: /dev/sdb
      partitions:
        # Similarly for second disk
        - label: root-2
          size_mib: 8192
        - 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 key material is specified, so a random key will be generated
      # and stored in the root filesystem
  filesystems:
    - device: /dev/mapper/var
      path: /var
      label: var
      format: xfs
      wipe_filesystem: true
      with_mount_unit: true

Layout de discos

All Fedora CoreOS systems start with the same disk image which varies slightly between architectures based on what is needed for bootloading. On first boot the root filesystem is expanded to fill the rest of the disk. The disk image can be customized using Butane configs to repartition the disk and create/reformat filesystems. Bare metal installations are not different; the installer only copies the raw image to the target disk and injects the specified config into /boot for use on first boot.

Veja Reconfigurando o sistema de arquivos raiz para exemplos sobre mudanças suportadas para a partição raiz.

Tabelas de partição

Usar números de partição para se referir a partições específicas é desencorajado e rótulos ou UUIDs devem ser usados no lugar. Fedora CoreOS reserva os rótulos boot, boot-<número>, root, root-<número>, BIOS-BOOT, bios-<número>, EFI-SYSTEM e esp-<number>, e os nomes de dispositivos RAID md-boot e md-root. Criar partições ou sistema de arquivos com esses rótulos não é suportado.

Tabela de partição x86_64

A imagem de disco para x86_64 é formatada com GPT com uma MBR protetiva. Suporta inicialização via BIOS ou UEFI (incluindo Secure Boot).

O layout da tabela de partição mudou com o tempo. O layout atual é:

Table 1. Tabela de partição para x86_64
Número	Rótulo	Descrição	Tipo da partição
1	BIOS-BOOT	Contém imagem GRUB de BIOS	dados brutos
2	EFI-SYSTEM	Contém imagem GRUB de EFI e pedaço Secure Boot	FAT32
3	boot	Contém configuração GRUB, imagens kernel/initramfs	ext4
4	root	Contém o sistema de arquivos raiz	xfs

A partição EFI-SYSTEM pode ser excluída ou reformatada quando a inicialização é feita por BIOS. Similarmente, a partição BIOS-BOOT pode ser excluída ou reformatada quando inicializar em EFI.

Sistema de arquivos montados

Fedora CoreOS uses OSTree, which is a system for managing multiple bootable operating system trees that share storage. Each operating system version is part of the / filesystem. All deployments share the same /var which can be on the same filesystem, or mounted separately.

Isso mostra os pontos de montagem padrão para um sistema FedoraCoreOS instalado em um disco /dev/vda:

Pontos de montagem padrão em x86_64

$ findmnt --real # Alguns detalhes estão omitidos
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

A partição de sistema EFI era montada anteriormente em /boot/efi, mas não é mais o caso. Em sistemas configurados com espelhamento de dispositivo de inicialização, existem partições EFI independentes em cada disco constituinte.

`/` imutável, `/usr` somente leitura

Como o OSTree é usado para manejar todos os arquivos pertencentes ao sistema operacional, os pontos de montagem / e /usr não podem ser escritos. Qualquer mudança para o sistema operacional deve ser aplicada via rpm-ostree.

Similarmente, o ponto de montagem /boot não pode ser escrito e a Partição de Sistema EFI não é montada por padrão. Esses sistemas de arquivos são gerenciados pelo rpm-ostree e bootupd, e não devem ser modificados por um administrados.

Adicionar diretórios de alto nível (i.e. /foo) é atualmente não suportado e desaconselhado pelo atributo de imutabilidade.

O / real (como na raiz do sistema de arquivos e na partição root) é montado como somente leitura em /sysroot e não deve ser acessado ou modificado diretamente.

Configuração em `/etc` e estado em `/var`

Os únicos locais com suporte a escrita são /etc e /var. /etc deve conter apenas arquivos de configuração e não deve armazenar dados. Todos os dados devem ser mantidos em /var e não serão tocados por atualizações do sistema. Locais tradicionais (como /home ou /srv) são links simbólicos para diretórios em /var (como /var/home ou /var/srv).

Seleção da versão e inicialização

A GRUB menu entry is created for each version of Fedora CoreOS currently available on a system. This menu entry references an ostree deployment which consists of a Linux kernel, an initramfs and a hash linking to an ostree commit (passed via the ostree= kernel argument). During bootup, ostree will read this kernel argument to determine which deployment to use as the root filesystem. Each update or change to the system (package installation, addition of kernel arguments) creates a new deployment. This enables rolling back to a previous deployment if the update causes problems.

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