Resolver Falhas de Inicialização Após a Alteração da Forma nas Instâncias do OCI Linux

Introdução

Este tutorial orienta você na resolução de falhas de inicialização em imagens personalizadas do Oracle Cloud Infrastructure (OCI), que podem ocorrer após uma alteração de forma ou até mesmo uma simples reinicialização devido a alterações nos mapeamentos de dispositivos subjacentes.

Antes de mergulhar na solução, vamos primeiro entender o que é uma imagem personalizada.

Uma imagem personalizada no OCI é um snapshot do volume de inicialização de uma instância que captura a configuração do sistema operacional, o software instalado e as definições do ambiente. As imagens personalizadas são comumente usadas para replicar ambientes pré-configurados em várias instâncias ou regiões, garantindo consistência em escala.

No entanto, essas imagens podem apresentar riscos, especialmente se forem fortemente acopladas ao hardware original da instância. Se não for projetado tendo em mente a portabilidade, poderão surgir problemas ao alterar formas (por exemplo, alternar de uma instância VM.Standard3 para uma instância VM.Standard4), pois alterações de hardware subjacentes podem afetar a forma como os dispositivos são mapeados.

Este blog descreve um cenário de falha de inicialização do mundo real encontrado por um cliente usando uma imagem do Rocky Linux do Oracle Cloud Marketplace. Embora este exemplo seja específico do Rocky Linux, a causa raiz e a resolução se aplicam amplamente a qualquer imagem personalizada baseada em Linux que use nomes de dispositivos estáticos em sua configuração.

Objetivos

Este guia ajuda os usuários do OCI a identificar e resolver falhas de inicialização em imagens personalizadas do Linux causadas por alterações de forma ou reinicializações, corrigindo configurações de montagem e aprimorando a portabilidade da imagem.

Pré-requisitos

Tarefa 1: Compreender o Problema

  1. Verifique como as alterações de forma do OCI afetam a nomeação subjacente de hardware e dispositivo.
  2. Reconheça que os nomes de dispositivos estáticos em /etc/fstab (por exemplo, /dev/sdX) podem se tornar inválidos após uma alteração de forma ou mesmo após uma reinicialização.
    • Quando a forma é alterada, o sistema operacional pode designar novos nomes a volumes em blocos anexados. Por exemplo, um disco que era /dev/sdb agora pode aparecer como /dev/sdc.
    • Se /etc/fstab depender desses nomes estáticos, os volumes poderão falhar ao serem montados na inicialização.
    • Para evitar essa situação, use identificadores persistentes, como os caminhos UUID ou /dev/disk/by-uuid/ do volume em /etc/fstab.

Tarefa 2: Identificar Sintomas e Erros

  1. Verifique a console serial ou os logs do sistema (journalctl -xb) em busca de erros como:

    • Welcome to emergency mode! After logging in, type “journalctl -xb”...
    • Failed to mount /mnt/data: No such device
    • Duplicate mount point /mnt/data detected
    • Cannot mount /dev/sdX: No such file or directory
    • systemd[1]: Failed to mount /mnt/data.
    • systemd[1]: Dependency failed for Local File Systems.
    • systemd[1]: Job local-fs.target/start failed with result ‘dependency’.

Tarefa 3: Inicializar no Modo de Resgate/Emergência

  1. Acesse a console serial da instância.
  2. Inicie no modo de resgate ou emergência para executar diagnósticos e ações corretivas.

Tarefa 4: Identificar Nomes Corretos de Dispositivo

  1. Execute os comandos blkid ou lsblk para listar os dispositivos de bloco atuais e seus UUIDs.

Tarefa 5: Montar Volume de Inicialização Manualmente

  1. Monte o volume de inicialização usando o nome de dispositivo correto:

    • mount /dev/sdXn /mnt
    • chroot /mnt

Tarefa 6: Editar /etc/fstab

  1. Abra /etc/fstab usando um editor (por exemplo, vi /etc/fstab)

    • Substitua todas as entradas /dev/sdX pelos valores de UUID persistentes correspondentes encontrados em blkid.
    • Remova quaisquer entradas de montagem duplicadas. Observação: essa é uma correção única quando identificadores persistentes são usados, alterações futuras na forma não devem causar esse problema.

Tarefa 7: Sair e reinicializar

  1. Saia do ambiente chroot: exit.
  2. Desmonte os volumes, se necessário.
  3. Reinicialize a instância.

Dicas de Prevenção para Evitar Falhas de Inicialização Após Alterações na Forma do OCI

  1. Usar Identificadores Persistentes: sempre especifique discos em /etc/fstab usando UUID= ou LABEL= em vez de nomes de dispositivos como /dev/sdX. Isso garante que os pontos de montagem permaneçam consistentes apesar das alterações de hardware.
  2. Executar Auditorias blkid: Execute blkid antes e depois de uma alteração de forma para verificar se os mapeamentos de dispositivo para UUID permanecem corretos.
  3. Backup Antes das Alterações: Sempre faça backup de sua instância ou volume de inicialização antes de qualquer modificação de forma para ativar a recuperação se ocorrerem problemas.
  4. Testar Alterações de Forma em Não Produção: Especialmente ao usar imagens de marketplace ou personalizadas que podem ter montagens com código fixo, teste as alterações de forma em um ambiente de não produção primeiro.

Conclusão

Embora esse problema tenha sido observado no Rocky Linux, ele pode afetar qualquer imagem personalizada baseada em Linux se as melhores práticas em torno da montagem em disco não forem seguidas. A boa notícia é que esta é uma correção única. Depois que o /etc/fstab for atualizado para usar identificadores persistentes, como UUIDs ou LABELs, alterações futuras na forma do OCI ou até mesmo reinicializações não deverão levar a falhas de inicialização. A validação proativa de sua configuração garante transições suaves e confiáveis entre as formas.

Confirmações

Mais Recursos de Aprendizado

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal do Oracle Learning YouTube. Além disso, acesse education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.