Solução de problemas em instâncias com falha nas verificações de status

As informações a seguir podem ajudá-lo a solucionar problemas se sua instância falhar em uma verificação de status. Determine primeiro se seus aplicativos exibem quaisquer problemas. Se você verificar que a instância não está executando seus aplicativos como esperado, analise as informações de verificação de status e os logs do sistema.

Para obter exemplos de problemas que podem causar falha nas verificações de status, consulte Verificações de status para as instâncias.

Analisar informações de verificação de status

Para investigar instâncias prejudicadas usando o console do Amazon EC2

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

2. No painel de navegação, selecione Instâncias e, em seguida, sua instância.

3. No painel de detalhes, escolha Status e alarmes para ver os resultados individuais de todas as Verificações de status do sistema e as Verificações de status da instância.

Se uma verificação do status do sistema falhar, é possível tentar uma das opções a seguir:

• Crie um alarme de recuperação da instância. Para obter mais informações, consulte Criar alarmes para interromper, encerrar, reinicializar ou recuperar uma instância.

• Se você alterou o tipo de instância para uma instância desenvolvida no AWS Nitro System, as verificações de status apresentarão falhas se você migrar de uma instância que não tenha os drivers ENA e NVMe necessários. Para obter mais informações, consulte Compatibilidade para alterar o tipo de instância.

• Para uma instância usando AMI baseada no Amazon EBS, pare e reinicie a instância.

• Para uma instância usando uma AMI com armazenamento de instâncias, encerre a instância e execute uma substituição.

• Espere o Amazon EC2 resolver o problema.

• Publique seu problema no AWS re:Post.

• Se sua instância está em um grupo do Auto Scaling, o serviço do Amazon EC2 Auto Scaling executa uma instância de substituição automaticamente. Para obter mais informações, consulte Verificações de integridade de instâncias do Auto Scaling no Guia do usuário do Amazon EC2 Auto Scaling.

• Recupere o log do sistema e procure erros.

Recuperar os logs do sistema

Se uma verificação de status da instância falhar, será possível reinicializar a instância e recuperar os logs do sistema. Os logs podem revelar um erro que pode ajudar você a resolver o problema. Reinicializar limpa as informações desnecessária dos logs.

Para reinicializar uma instância e recuperar o log do sistema

1. Abra o console do Amazon EC2 em https://console.aws.amazon.com/ec2/.

2. No painel de navegação, selecione Instâncias e selecione sua instância.

3. Escolha Instance state (Estado da instância) e Reboot instance (Reinicializar instância). Pode demorar alguns minutos para a instância reinicializar.

4. Verifique o problema ainda existe; em alguns casos, reinicializar pode resolver o problema.

5. Quando a ação estiver no estado running, escolha Actions (Ações), Monitor and troubleshoot (Monitorar e solucionar problemas), Get system log (Obter log do sistema).

6. Revise o log que aparece na tela e use a lista de declarações conhecidas de erro do log do sistema, abaixo, para solucionar seu problema.

7. Se seu problema não for resolvido, você pode publicar seu problema no AWS re:Post.

Solução de problemas de erros de logs do sistema para instâncias baseadas em Linux

Para instâncias baseadas em Linux que reprovaram em uma verificação de status da instância, como a verificação de acessibilidade da instância, verifique se você seguiu as etapas acima para recuperar o log do sistema. A lista a seguir contém alguns erros comuns no log do sistema e ações sugeridas que é possível utilizar para resolver o problema de cada erro.

Erros de memória

• Sem memória: encerrar processo

• ERRO: falha em mmu_update (falha na atualização do gerenciamento de memória)

Erros do dispositivo

• Erro de E/S (falha de dispositivo de blocos)

• ERRO DE E/S: nem disco local nem disco remoto (o dispositivo de blocos distribuído está quebrado)

Erros de kernel

• request_module: modprobe de loop descontrolado (modprobe do kernel legado do looping, em versões mais antigas do Linux)

• "FATAL: kernel antigo demais" e "fsck: Não existe esse arquivo ou diretório ao tentar abrir /dev" (falta de correspondência entre o kernel e a AMI)

• "FATAL: Não foi possível carregar os módulos /lib/" ou "BusyBox" (módulos do kernel ausentes)

• ERRO Kernel inválido (kernel incompatível com EC2)

Erros do sistema de arquivos

• fsck: Nenhum arquivo ou diretório ao tentar abrir… (Sistema de arquivos não encontrado)

• Erro geral ao montar os sistemas de arquivos (falha na montagem)

• VFS: Não foi possível montar o fs raiz em um bloco desconhecido (falta de correspondência no sistema de arquivos-raiz)

• Erro: não foi possível determinar o número principal/secundário do dispositivo raiz... (Incompatibilidade entre sistema de arquivos/dispositivo raiz)

• XENBUS: Dispositivo sem driver…

• …dias sem ser verificada, verificação forçada (verificação necessária para o sistema de arquivos)

• O fsck morreu com status de saída… (Dispositivo ausente)

Erros do sistema operacional

• Prompt do GRUB (grubdom>)

• Acessando a interface eth0: O dispositivo eth0 tem um endereço MAC diferente do esperado, ignorando. (Endereço MAC hard-coded)

• Não foi possível carregar a Política do SELinux. A máquina está no modo de força. Parando agora. (Erro de configuração do SELinux)

• XENBUS: Excedido o limite de tempo para se conectar a dispositivos (tempo limite do Xenbus)

Sem memória: encerrar processo

O erro de falta de memória é indicado por uma entrada no log de sistema semelhante à exibida abaixo.

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879
or a child 
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-
rss:101196kB, file-rss:204kB

Possível causa

Memória exaurida

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseada no Amazon EBS	Execute um destes procedimentos: Pare a instância, modifique-a para usar um tipo de instância diferente e inicie-a novamente. Por exemplo, um tipo de instância maior ou otimizado para memória. Reinicialize a instância para ela retornar ao status não prejudicado. O problema provavelmente ocorrerá outra vez, a menos que você altere o tipo de instância.
Com armazenamento de instâncias	Execute um destes procedimentos: Encerre a instância e execute uma nova instância, especificando um tipo de instância diferente. Por exemplo, um tipo de instância maior ou otimizado para memória. Reinicialize a instância para ela retornar ao status não prejudicado. O problema provavelmente ocorrerá outra vez, a menos que você altere o tipo de instância.

ERRO: falha em mmu_update (falha na atualização do gerenciamento de memória)

As falhas de atualização do gerenciamento de memória são indicadas por uma entrada no logo do sistema semelhante à seguinte:

...
Press `ESC' to enter the menu... 0   [H[J  Booting 'Amazon Linux 2011.09 (2.6.35.14-95.38.amzn1.i686)'


root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /boot/vmlinuz-2.6.35.14-95.38.amzn1.i686 root=LABEL=/ console=hvc0 LANG=

en_US.UTF-8 KEYTABLE=us

initrd /boot/initramfs-2.6.35.14-95.38.amzn1.i686.img

ERROR: mmu_update failed with rc=-22

Possível causa

Problema com Amazon Linux

Ação sugerida

Publique seu problema nos Fóruns de desenvolvedores ou entre em contato com o AWS Support.

Erro de E/S (falha de dispositivo de blocos)

Um erro de entrada/saída é indicado por uma entrada no log do sistema semelhante ao exemplo a seguir:

[9943662.053217] end_request: I/O error, dev sde, sector 52428288
[9943664.191262] end_request: I/O error, dev sde, sector 52428168
[9943664.191285] Buffer I/O error on device md0, logical block 209713024
[9943664.191297] Buffer I/O error on device md0, logical block 209713025
[9943664.191304] Buffer I/O error on device md0, logical block 209713026
[9943664.191310] Buffer I/O error on device md0, logical block 209713027
[9943664.191317] Buffer I/O error on device md0, logical block 209713028
[9943664.191324] Buffer I/O error on device md0, logical block 209713029
[9943664.191332] Buffer I/O error on device md0, logical block 209713030
[9943664.191339] Buffer I/O error on device md0, logical block 209713031
[9943664.191581] end_request: I/O error, dev sde, sector 52428280
[9943664.191590] Buffer I/O error on device md0, logical block 209713136
[9943664.191597] Buffer I/O error on device md0, logical block 209713137
[9943664.191767] end_request: I/O error, dev sde, sector 52428288
[9943664.191970] end_request: I/O error, dev sde, sector 52428288
[9943664.192143] end_request: I/O error, dev sde, sector 52428288
[9943664.192949] end_request: I/O error, dev sde, sector 52428288
[9943664.193112] end_request: I/O error, dev sde, sector 52428288
[9943664.193266] end_request: I/O error, dev sde, sector 52428288
...

Possíveis causas

Tipo de instância	Possível causa
Baseado em Amazon EBS	Um volume do Amazon EBS com falha
Com armazenamento de instâncias	Uma unidade física com falha

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância. Separe o volume. Tentativa de recuperar o volume. nota É boa prática tirar um snapshot dos seus volumes do Amazon EBS com frequência. Isso diminui drasticamente o risco de perda de dados como resultado da falha. Reassocie o volume à instância. Inicie a instância.
Com armazenamento de instâncias	Encerre a instância e execute uma nova instância. nota Os dados não podem ser recuperados. Recupere os backups. nota É uma boa prática usar Amazon S3 ou Amazon EBS para backup. Os volumes de armazenamento de instâncias estão diretamente vinculados a um único host e a falhas únicas de disco.

ERRO DE E/S: nem disco local nem disco remoto (o dispositivo de blocos distribuído está quebrado)

Um erro de entrada/saída no dispositivo é indicado por uma entrada no log do sistema semelhante ao exemplo a seguir:

...
block drbd1: Local IO failed in request_timer_fn. Detaching...

Aborting journal on device drbd1-8.

block drbd1: IO ERROR: neither local nor remote disk

Buffer I/O error on device drbd1, logical block 557056

lost page write due to I/O error on drbd1

JBD2: I/O error detected when updating journal superblock for drbd1-8.

Possíveis causas

Tipo de instância	Possível causa
Baseado em Amazon EBS	Um volume do Amazon EBS com falha
Com armazenamento de instâncias	Uma unidade física com falha

Ação sugerida

Encerre a instância e execute uma nova instância.

Para uma instância baseada no Amazon EBS, é possível recuperar os dados de um snapshot recente ao criar uma imagem a partir de deles. Alguns dados adicionados depois do snapshot não podem ser recuperados.

request_module: modprobe de loop descontrolado (modprobe do kernel legado do looping, em versões mais antigas do Linux)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo. Usar um kernel instável ou antigo do Linux (por exemplo, 2.6.16-xenU) pode causar uma condição de loop interminável no startup.

Linux version 2.6.16-xenU ([e-mail]) (gcc version 4.0.1 
20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007

BIOS-provided physical RAM map:

 Xen: 0000000000000000 - 0000000026700000 (usable)

0MB HIGHMEM available.
...

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

request_module: runaway loop modprobe binfmt-464c

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use um kernel mais novo, baseado em GRUB ou estático, usando uma das seguintes opções: Opção 1: Encerre a instância e execute uma nova, especificando os parâmetros -kernel e -ramdisk. Opção 2: Pare a instância. Modifique os atributos de kernel e ramdisk para usar um kernel mais recente. Inicie a instância.
Com armazenamento de instâncias	Encerre a instância e execute uma nova, especificando os parâmetros -kernel e -ramdisk.

"FATAL: kernel antigo demais" e "fsck: Não existe esse arquivo ou diretório ao tentar abrir /dev" (falta de correspondência entre o kernel e a AMI)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

Linux version 2.6.16.33-xenU ([e-mail]) 
(gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)) #2 SMP Wed Aug 15 17:27:36 SAST 2007
...
FATAL: kernel too old
Kernel panic - not syncing: Attempted to kill init!

Possíveis causas

Kernel e userland incompatíveis

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância. Modifique a configuração para usar um kernel mais recente. Inicie a instância.
Com armazenamento de instâncias	Use o procedimento a seguir: Crie uma AMI que use um kernel mais recente. Encerre a instância. Execute uma nova instância com base na AMI criada.

"FATAL: Não foi possível carregar os módulos /lib/" ou "BusyBox" (módulos do kernel ausentes)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

[    0.370415] Freeing unused kernel memory: 1716k freed 
Loading, please wait...
WARNING: Couldn't open directory /lib/modules/2.6.34-4-virtual: No such file or directory
FATAL: Could not open /lib/modules/2.6.34-4-virtual/modules.dep.temp for writing: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
Couldn't get a file descriptor referring to the console
Begin: Loading essential drivers... ...
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root file system... ...
Begin: Running /scripts/local-top ...
Done.
Begin: Waiting for root file system... ...
Done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
FATAL: Could not load /lib/modules/2.6.34-4-virtual/modules.dep: No such file or directory
ALERT! /dev/sda1 does not exist. Dropping to a shell!


BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu5) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Possíveis causas

Uma ou mais das condições a seguir podem causar esse problema:

• Ramdisk ausente

• Módulos corretos do ramdisk ausentes

• Volume do dispositivo raiz do Amazon EBS não associado corretamente como /dev/sda1

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Selecione o ramdisk corrigido para o volume do Amazon EBS. Pare a instância. Desanexe o volume e repare-o. Associe o volume à instância. Inicie a instância. Modifique a AMI para usar o ramdisk corrigido.
Com armazenamento de instâncias	Use o procedimento a seguir: Encerre a instância e execute uma nova instância com o ramdisk correto. Crie uma nova AMI com o ramdisk correto.

ERRO Kernel inválido (kernel incompatível com EC2)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

...
root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /vmlinuz root=/dev/sda1 ro

initrd /initrd.img

ERROR Invalid kernel: elf_xen_note_check: ERROR: Will only load images 
built for the generic loader or Linux images
xc_dom_parse_image returned -1

Error 9: Unknown boot failure

  Booting 'Fallback'
  
root (hd0)

 Filesystem type is ext2fs, using whole disk

kernel /vmlinuz.old root=/dev/sda1 ro

Error 15: File not found

Possíveis causas

Uma ou ambas as condições a seguir podem causar esse problema:

• O kernel fornecido não é compatível com GRUB

• O kernel de fallback não existe

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância. Substitua por um kernel em funcionamento. Instale um kernel de fallback. Modifique a AMI corrigindo o kernel.
Com armazenamento de instâncias	Use o procedimento a seguir: Encerre a instância e execute uma nova instância com o kernel correto. Crie uma AMI com o kernel correto. (Opcional) Procure assistência técnica para recuperação de dados usando o AWS Support.

fsck: Nenhum arquivo ou diretório ao tentar abrir… (Sistema de arquivos não encontrado)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

		Welcome to Fedora 
		Press 'I' to enter interactive startup.
Setting clock : Wed Oct 26 05:52:05 EDT 2011 [  OK  ]

Starting udev: [  OK  ]

Setting hostname localhost:  [  OK  ]

No devices found
Setting up Logical Volume Management: File descriptor 7 left open
  No volume groups found
[  OK  ]

Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 
/dev/sda1: clean, 82081/1310720 files, 2141116/2621440 blocks
[/sbin/fsck.ext3 (1) -- /mnt/dbbackups] fsck.ext3 -a /dev/sdh 
fsck.ext3: No such file or directory while trying to open /dev/sdh

/dev/sdh: 
The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[FAILED]


*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D to continue):

Possíveis causas

• Existe um bug nas definições de /etc/fstab do sistema de arquivos do ramdisk

• Definições do sistema de arquivos com configuração errada em /etc/fstab

• Unidade ausente/com falha

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância, separe o volume do dispositivo raiz, repare/modifique /etc/fstab o volume, associe o volume à instância e inicie a instância. Corrija o ramdisk para incluir o /etc/fstab modificado (se aplicável). Modifique as AMIs para usar um ramdisk mais recente. O sexto campo do fstab define os requisitos de disponibilidade da montagem – um valor diferente de zero implica que um fsck será feito nesse volume e deve ter sucesso. Usar esse campo pode ser problemático no Amazon EC2, pois a falha tipicamente resulta em um prompt do console interativo que não está disponível atualmente no Amazon EC2. Tenha cuidado com esse recurso e leia a man page do Linux para fstab.
Com armazenamento de instâncias	Use o procedimento a seguir: Encerre a instância e execute uma nova instância. Separe todos os volumes do Amazon EBS com erro e a instância de reinicialização. (Opcional) Procure assistência técnica para recuperação de dados usando o AWS Support.

Erro geral ao montar os sistemas de arquivos (falha na montagem)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

Loading xenblk.ko module 
xen-vbd: registered block device major 8

Loading ehci-hcd.ko module
Loading ohci-hcd.ko module
Loading uhci-hcd.ko module
USB Universal Host Controller Interface driver v3.0

Loading mbcache.ko module
Loading jbd.ko module
Loading ext3.ko module
Creating root device.
Mounting root filesystem.
kjournald starting.  Commit interval 5 seconds

EXT3-fs: mounted filesystem with ordered data mode.

Setting up other filesystems.
Setting up new root fs
no fstab.sys, mounting internal defaults
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
mountall:/proc: unable to mount: Device or resource busy
mountall:/proc/self/mountinfo: No such file or directory
mountall: root filesystem isn't mounted
init: mountall main process (221) terminated with status 1

General error mounting filesystems.
A maintenance shell will now be started.
CONTROL-D will terminate this shell and re-try.
Press enter for maintenance
(or type Control-D to continue):

Possíveis causas

Tipo de instância	Possível causa
Baseado em Amazon EBS	Volume do Amazon EBS destacado ou com falha. Sistema de arquivos corrompido. Combinação malfeita de ramdisk e AMI (por exemplo, ramdisk Debian com AMI SUSE).
Com armazenamento de instâncias	Uma unidade com falha. Um sistema de arquivos corrompido. Combinação malfeita de ramdisk e AMI (por exemplo, ramdisk Debian com AMI SUSE).

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância. Separe o volume de raiz. Associe o volume do dispositivo raiz a uma instância de trabalho conhecida. Execute uma verificação no sistema de arquivos (fsck -a /dev/...). Corrija todos os erros. Separe o volume de instância de trabalho conhecida. Associe o volume à instância parada. Inicie a instância. Verifique novamente o status da instância.
Com armazenamento de instâncias	Faça uma das coisas a seguir: Execute uma nova instância. (Opcional) Procure assistência técnica para recuperação de dados usando o AWS Support.

VFS: Não foi possível montar o fs raiz em um bloco desconhecido (falta de correspondência no sistema de arquivos-raiz)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

Linux version 2.6.16-xenU ([e-mail]) (gcc version 4.0.1 
 20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
...
Kernel command line:  root=/dev/sda1 ro 4
...
Registering block device major 8
...
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Possíveis causas

Tipo de instância	Possível causa
Baseado em Amazon EBS	Dispositivo não associado corretamente. O dispositivo raiz não foi associado no ponto correto do dispositivo. O sistema de arquivos não está no formato esperado. Uso do kernel de legado (por exemplo, 2.6.16-XenU). Uma atualização de kernel recente na sua instância (atualização defeituosa ou bug de atualização)
Com armazenamento de instâncias	Falha no dispositivo de hardware.

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseada no Amazon EBS	Execute um destes procedimentos: Pare e reinicie a instância. Modifique o volume do dispositivo raiz para associar no ponto correto do dispositivo, possível /dev/sda1 em vez de /dev/sda. Pare e modifique para usar o kernel moderno. Consulte a documentação para sua distribuição Linux para verificar bugs conhecidos da atualização. Altere ou reinstale o kernel.
Com armazenamento de instâncias	Encerre a instância e execute uma nova instância usando um kernel moderno.

Erro: não foi possível determinar o número principal/secundário do dispositivo raiz... (Incompatibilidade entre sistema de arquivos/dispositivo raiz)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

...
XENBUS: Device with no driver: device/vif/0
XENBUS: Device with no driver: device/vbd/2048
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Initializing network drop monitor service
Freeing unused kernel memory: 508k freed
:: Starting udevd...
done.
:: Running Hook [udev]
:: Triggering uevents...<30>udevd[65]: starting version 173
done.
Waiting 10 seconds for device /dev/xvda1 ...
Root device '/dev/xvda1' doesn't exist. Attempting to create it.
ERROR: Unable to determine major/minor number of root device '/dev/xvda1'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[ramfs /]#

Possíveis causas

• Driver do dispositivo de blocos virtual ausente ou configurado incorretamente

• Conflito de enumeração de dispositivos (sda versus xvda ou sda em vez de sda1)

• Escolha incorreta do kernel da instância

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância. Separe o volume. Corrija o problema de mapeamento de dispositivos. Inicie a instância. Modifique a AMI para abordar os problemas de mapeamento de dispositivos.
Com armazenamento de instâncias	Use o procedimento a seguir: Crie nova AMI com a correção apropriada (mapeie o dispositivo de blocos corretamente). Encerre a instância e execute uma nova a partir da AMI criada.

XENBUS: Dispositivo sem driver…

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

XENBUS: Device with no driver: device/vbd/2048
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Initializing network drop monitor service
Freeing unused kernel memory: 508k freed
:: Starting udevd...
done.
:: Running Hook [udev]
:: Triggering uevents...<30>udevd[65]: starting version 173
done.
Waiting 10 seconds for device /dev/xvda1 ...
Root device '/dev/xvda1' doesn't exist. Attempting to create it.
ERROR: Unable to determine major/minor number of root device '/dev/xvda1'.
You are being dropped to a recovery shell
    Type 'exit' to try and continue booting
sh: can't access tty; job control turned off
[ramfs /]#

Possíveis causas

• Driver do dispositivo de blocos virtual ausente ou configurado incorretamente

• Conflito de enumeração de dispositivos (sda versus xvda)

• Escolha incorreta do kernel da instância

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância. Separe o volume. Corrija o problema de mapeamento de dispositivos. Inicie a instância. Modifique a AMI para abordar os problemas de mapeamento de dispositivos.
Com armazenamento de instâncias	Use o procedimento a seguir: Crie uma AMI com a correção apropriada (mapeie o dispositivo de blocos corretamente). Encerre a instância e execute uma nova usando a AMI criada.

…dias sem ser verificada, verificação forçada (verificação necessária para o sistema de arquivos)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

...
Checking filesystems
Checking all file systems.
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a /dev/sda1 
/dev/sda1 has gone 361 days without being checked, check forced

Possíveis causas

Tempo de verificação do sistema de arquivos passado; uma verificação do sistema de arquivos está sendo forçada.

Ações sugeridas

• Espere até que a verificação do sistema de arquivos seja concluída. Uma verificação do sistema de arquivos pode demorar bastante, dependendo do tamanho do sistema de arquivos raiz.

• Modifique seus sistemas de arquivos para remover a obrigatoriedade de verificação do sistema de arquivos (fsck) usando tune2fs ou ferramentas apropriadas para seu sistema de arquivos.

O fsck morreu com status de saída… (Dispositivo ausente)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

Cleaning up ifupdown....
Loading kernel modules...done.
...
Activating lvm and md swap...done.
Checking file systems...fsck from util-linux-ng 2.16.2
/sbin/fsck.xfs: /dev/sdh does not exist
fsck died with exit status 8
[31mfailed (code 8).[39;49m

Possíveis causas

• Ramdisk procurando unidade ausente

• Verificação de consistência do sistema de arquivos forçada

• Unidade falha ou separada

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Teste uma ou mais das opções a seguir para resolver o problema: Pare a instância, associe o volume a uma instância em execução existente. Execute manualmente verificações de consistência. Conserte o ramdisk para incluir utilitários relevantes. Modifique os parâmetros de ajuste do sistema de arquivos para remover os requisitos de consistência (não recomendados).
Com armazenamento de instâncias	Teste uma ou mais das opções a seguir para resolver o problema: Reempacote o ramdisk com as ferramentas corretas. Modifique os parâmetros de ajuste do sistema de arquivos para remover os requisitos de consistência (não recomendados). Encerre a instância e execute uma nova instância. (Opcional) Procure assistência técnica para recuperação de dados usando o AWS Support.

Prompt do GRUB (grubdom>)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

    GNU GRUB  version 0.97  (629760K lower / 0K upper memory)

       [ Minimal BASH-like line editing is supported.   For

         the   first   word,  TAB  lists  possible  command

         completions.  Anywhere else TAB lists the possible

         completions of a device/filename. ]

grubdom> 

Possíveis causas

Tipo de instância	Possíveis causas
Baseado em Amazon EBS	Arquivo de configuração do GRUB ausente. Imagem incorreta de GRUB usada, esperando arquivo de configuração do GRUB em um local diferente. Sistema de arquivos não compatível usado para armazenar seu arquivo de configuração de GRUB (por exemplo, convertendo o sistema de arquivos raiz a um tipo que não é compatível com uma versão anterior do GRUB).
Com armazenamento de instâncias	Arquivo de configuração do GRUB ausente. Imagem incorreta de GRUB usada, esperando arquivo de configuração do GRUB em um local diferente. Sistema de arquivos não compatível usado para armazenar seu arquivo de configuração de GRUB (por exemplo, convertendo o sistema de arquivos raiz a um tipo que não é compatível com uma versão anterior do GRUB).

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Opção 1: Modifique a AMI e reexecute a instância: Modifique as AMIs de origem para criar um arquivo de configuração GRUB no local padrão (/boot/grub/menu.lst). Verifique se sua versão do GRUB oferece suporte ao tipo de sistema de arquivos e atualize o GRUB, se necessário. Escolha a imagem de GRUB adequada, (unidade hd0-1st ou hd00 – 1º unidade, 1ª partição). Encerre a instância e execute uma nova usando a AMI criada. Opção 2: Corrija a instância existente: Pare a instância. Separe o sistema de arquivos-raiz. Associe o sistema de arquivos raiz para uma instância de trabalho conhecida. Monte o sistema de arquivos. Crie o arquivo de configuração do GRUB. Verifique se sua versão do GRUB oferece suporte ao tipo de sistema de arquivos e atualize o GRUB, se necessário. Separe o sistema de arquivos. Associe à instância original. Modifique o atributo do kernel para usar a imagem adequada do GRUB (1º disco ou 1ª partição no 1ª disco). Inicie a instância.
Com armazenamento de instâncias	Opção 1: Modifique a AMI e reexecute a instância: Crie a nova AMI com um arquivo de configuração GRUB no local padrão (/boot/grub/menu.lst). Escolha a imagem de GRUB adequada, (unidade hd0-1st ou hd00 – 1º unidade, 1ª partição). Verifique se sua versão do GRUB oferece suporte ao tipo de sistema de arquivos e atualize o GRUB, se necessário. Encerre a instância e execute uma nova usando a AMI criada. Opção 2: Encerre a instância e execute uma nova, especificando o kernel correto. nota Para recuperar dados da instância existente, entre em contato com o AWS Support.

Acessando a interface eth0: O dispositivo eth0 tem um endereço MAC diferente do esperado, ignorando. (Endereço MAC hard-coded)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

... 
Bringing up loopback interface:  [  OK  ]

Bringing up interface eth0:  Device eth0 has different MAC address than expected, ignoring.
[FAILED]

Starting auditd: [  OK  ]

Possíveis causas

Há uma interface MAC hard-coded na configuração da AMI

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseada no Amazon EBS	Execute um destes procedimentos: Modifique a AMI para remover o hard code e reexecute a instância. Modifique a instância para remover o endereço MAC hard-coded. OU Use o procedimento a seguir: Pare a instância. Separe o volume de raiz. Associe o volume a outra instância e modifique o volume para remover o endereço MAC hard-coded. Associe o volume à instância original. Inicie a instância.
Com armazenamento de instâncias	Execute um destes procedimentos: Modifique a instância para remover o endereço MAC hard-coded. Encerre a instância e execute uma nova instância.

Não foi possível carregar a Política do SELinux. A máquina está no modo de força. Parando agora. (Erro de configuração do SELinux)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

audit(1313445102.626:2): enforcing=1 old_enforcing=0 auid=4294967295
Unable to load SELinux Policy. Machine is in enforcing mode. Halting now.
Kernel panic - not syncing: Attempted to kill init!

Possíveis causas

O SELinux foi habilitado por engano:

• O kernel fornecido não é compatível com GRUB

• O kernel de fallback não existe

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseado em Amazon EBS	Use o procedimento a seguir: Pare a instância com falha. Separe o volume do dispositivo raiz da instância com falha. Associe o volume do dispositivo raiz a outra instância do Linux em execução (posteriormente chamada de instância de recuperação). Conecte-se à instância de recuperação e monte o volume do dispositivo raiz da instância falha. Desabilite o SELinux no volume do dispositivo raiz montado. Esse processo varia nas distribuições de Linux; para obter mais informações, consulte a documentação específica do seu SO. nota Em alguns sistemas, você desabilita o SELinux configurando SELINUX=disabled no arquivo /mount_point/etc/sysconfig/selinux, onde mount_point é o local onde você montou o volume da sua instância de recuperação. Desmonte e separe o volume do dispositivo raiz da instância de recuperação e reassocie-o à instância original. Inicie a instância.
Com armazenamento de instâncias	Use o procedimento a seguir: Encerre a instância e execute uma nova instância. (Opcional) Procure assistência técnica para recuperação de dados usando o AWS Support.

XENBUS: Excedido o limite de tempo para se conectar a dispositivos (tempo limite do Xenbus)

Essa condição é indicada por um log no sistema semelhante ao exibido abaixo.

Linux version 2.6.16-xenU ([e-mail]) (gcc version 4.0.1 
20050727 (Red Hat 4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
...
XENBUS: Timeout connecting to devices!
...
Kernel panic - not syncing: No init found.  Try passing init= option to kernel.

Possíveis causas

• O dispositivo de blocos não está conectado à instância

• Essa instância está usando um kernel de uma instância antiga

Ações sugeridas

Para este tipo de instância	Faça o seguinte
Baseada no Amazon EBS	Execute um destes procedimentos: Modifique a AMI e a instância para usar um kernel moderno e reexecutar a instância. Reinicialize a instância.
Com armazenamento de instâncias	Execute um destes procedimentos: Encerre a instância. Modifique as AMIs para usar um kernel moderno e execute uma nova instância usando essa AMI.