I controlli dello stato delle istanze sulla mia istanza Linux EC2 hanno esito negativo a causa di problemi del sistema operativo. In che modo posso risolvere il problema?

Breve descrizione

La tua istanza Linux EC2 potrebbe avere esito negativo sui controlli dello stato delle istanze per i seguenti motivi:

• Hai aggiornato il kernel e il nuovo kernel non si è avviato.
• Le voci del file system in /etc/fstab sono errate o il file system è danneggiato.
• L'istanza presenta configurazioni di rete errate.

Risoluzione

Importante: Alcune delle seguenti procedure richiedono l'arresto dell'istanza. Quando si arresta un'istanza, si perdono i dati archiviati nei volumi dell'archivio dell'istanza. Salva un backup dei dati prima di interrompere l'istanza. A differenza dei volumi supportati da Amazon Elastic Block Store (Amazon EBS), i volumi dell’archivio dell’istanza sono temporanei e non supportano la persistenza dei dati. Per altre informazioni, consulta Stop and start Amazon EC2 instances.

L'indirizzo IPv4 pubblico statico che Amazon EC2 ha assegnato automaticamente all'istanza cambia dopo l'arresto e l'avvio. Per mantenere un indirizzo IPv4 pubblico che non cambia se l'istanza viene interrotta, usa un indirizzo IP elastico.

Nota: i seguenti metodi utilizzano esempi basati su Amazon Linux 2. Tuttavia, questi concetti si applicano alle distribuzioni Linux in generale. Se hai una distribuzione Linux diversa da Amazon Linux 2, i comandi, i percorsi e gli output potrebbero variare.

Usa la console seriale EC2 per istanze Linux

Se hai attivato la console seriale EC2 per istanze Linux, puoi utilizzarla per risolvere i tipi di istanze basate su Nitro supportati e le istanze bare metal. La console seriale consente di risolvere problemi di avvio, configurazione di rete e configurazione SSH. La console seriale può connettersi all'istanza senza una connessione di rete funzionante. Per accedere alla console seriale, usa la console Amazon EC2 o l'interfaccia della linea di comando AWS (AWS CLI).

La prima volta che utilizzi la console seriale EC2, rivedi i prerequisiti e configura l'accesso prima di connetterti.

Se la tua istanza non è raggiungibile e non hai configurato l'accesso alla console seriale, consulta la sezione Esecuzione dello strumento EC2Rescue per Linux. o vedi Uso dell'istanza di ripristino. Per configurare la console seriale EC2 per Linux, consulta Configure access to the EC2 serial console.

Nota: se visualizzi dei messaggi di errore quando esegui i comandi dell'interfaccia della linea di comando AWS (AWS CLI), consulta la sezione Troubleshoot AWS CLI errors. Inoltre, assicurati di utilizzare la versione più recente di AWS CLI.

Esecuzione dello strumento EC2Rescue per Linux

EC2Rescue per Linux diagnostica e risolve automaticamente i problemi dei sistemi operativi su istanze irraggiungibili. Per altre informazioni, consulta Come posso usare EC2Rescue per Linux per risolvere problemi a livello di sistema operativo?

Uso di un'istanza di ripristino per correggere manualmente gli errori

1. Avvia una nuova istanza EC2 nel tuo cloud privato virtuale (VPC). Utilizza la stessa Amazon Machine Image (AMI) nella stessa zona di disponibilità dell'istanza compromessa. La nuova istanza diventa la tua istanza di ripristino.

   Oppure, usa un'istanza esistente. L'istanza esistente deve utilizzare la stessa AMI e trovarsi nella stessa zona di disponibilità dell'istanza danneggiata.

2. Arresta l'istanza danneggiata.

3. Scollega il volume root Amazon EBS (/dev/xvda o /dev/sda1) dall'istanza danneggiata. Annota il nome del dispositivo del tuo volume root.

4. Collega il volume come dispositivo secondario (/dev/sdf) all'istanza di ripristino.

5. Connettiti alla tua istanza di ripristino tramite SSH.

6. Crea una directory dei punti di montaggio (/rescue) per il nuovo volume che hai collegato all'istanza di ripristino:

   $ sudo mkdir /rescue

7. Monta il volume nella nuova directory:

   $ sudo mount /dev/xvdf1 /rescue

   Se ricevi un errore, ad esempio "Wrong Fs type or UUID duplicate, Superblock is missing or badblock found", vedi Perché non riesco a montare il mio volume Amazon EBS?

   Nota: il dispositivo (/dev/xvdf1) potrebbe essere collegato all'istanza di ripristino con un nome di dispositivo diverso. Per determinare i nomi corretti dei dispositivi, utilizza il comando lsblk per visualizzare i dispositivi su disco disponibili insieme ai relativi punti di montaggio.

8. Se non l'hai già fatto, recupera il log di sistema dell'istanza per controllare l’errore. I passaggi successivi dipendono dal messaggio di errore indicato nel log di sistema.

   Di seguito è riportato un elenco di errori comuni che causano un errore di controllo dello stato dell'istanza. Per altri errori, consulta Troubleshoot system log errors for Linux-based instances.

Risoluzione dei problemi relativi a "Kernel panic"

Se nel log di sistema è presente il messaggio di errore Kernel Panic, è possibile che il kernel non contenga i file vmlinuz o initramfs. I file vmlinuz e initramfs sono necessari per un avvio corretto.

1. Esegui i seguenti comandi:

   cd /rescue/boot
   ls -l

2. Controlla l'output per verificare che ci siano i file vmlinuz e initramfs corrispondenti alla versione del kernel che intendi avviare.

   Il seguente esempio di output è per un'istanza Amazon Linux 2 con versione kernel, 4.14.165-131.185.amzn2.x86_64. La directory /boot contiene i file initramfs-4.14.165-131.185.amzn2.x86_64.img e vmlinuz-4.14.165-131.185.amzn2.x86_64 per essere avviata correttamente.

   uname -r
   4.14.165-131.185.amzn2.x86_64
   
   cd /boot; ls -l
   total 39960
   -rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
   drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
   drwx------ 5 root root       79 Feb 12 04:08 grub2
   -rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
   -rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
   -rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
   -rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
   -rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

3. Se i file initramfs e vmlinuz non sono presenti, avvia l'istanza utilizzando un kernel precedente che contiene entrambi questi file. Per le istruzioni, vedi How do I revert to a known stable kernel after an update prevents my Amazon EC2 instance from rebooting successfully?

4. Esegui il comando unmount per smontare il dispositivo secondario dall'istanza di ripristino:

   $ sudo umount /rescue

   Se l'operazione di smontaggio non va a buon fine, potrebbe essere necessario interrompere o riavviare l'istanza di ripristino per eseguire uno smontaggio pulito.

5. Scollega il volume secondario (/dev/sdf) dall'istanza di ripristino. Quindi, collegalo all'istanza originale come /dev/xvda (volume root).

6. Avvia l'istanza e verifica se è reattiva.

Per altre informazioni sulla risoluzione degli errori di kernel panic, consulta Why do I see a "Kernel panic" error after I upgrade the kernel or reboot my EC2 Linux instance?

Risoluzione dei problemi "Failed to mount" o "Dependency failed"

Errori quali "Failed to mount" o "Dependency failed" nel log di sistema indicano che il file /etc/fstab contiene voci di punti di montaggio errate.

1. Verifica che le voci del punto di montaggio in /etc/fstab siano corrette. Per correggere le voci del file /etc/fstab, vedi Perché la mia istanza EC2 Linux entra in modalità di emergenza quando cerco di avviarla?

2. È consigliabile eseguire lo strumento fsck o xfs\ _repair per correggere le incongruenze nel file system.

   Nota: crea un backup del file system prima di eseguire lo strumento fsck o xfs_repair.

   Esegui il comando unmount per smontare il punto di montaggio prima di eseguire lo strumento fsck o xfs_repair:

   $ sudo umount /rescue

   Esegui lo strumento fsck o xfs_repair, a seconda del tuo file system.

   Per i file system ext4, esegui il comando seguente:

   $ sudo fsck /dev/sdf
   fsck from util-linux 2.30.2
   e2fsck 1.42.9 (28-Dec-2013)
   /dev/sdf: clean, 11/6553600 files,
   459544/26214400 blocks

   Per i file system XFS, esegui il comando seguente:

   $ sudo xfs_repair /dev/sdf
   xfs_repair /dev/xvdf
   Phase 1 - find and verify superblock...
   Phase 2 - using internal log
           - zero log...
           - scan filesystem freespace and inode maps...
           - found root inode chunk
   Phase 3 - for each AG...
           - scan and clear agi unlinked lists...
           - process known inodes and perform inode discovery...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
           - process newly discovered inodes...
   Phase 4 - check for duplicate blocks...
           - setting up duplicate extent list...
           - check for inodes claiming duplicate blocks...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
   Phase 5 - rebuild AG headers and trees...
           - reset superblock...
   Phase 6 - check inode connectivity...
           - resetting contents of realtime bitmap and summary inodes
           - traversing filesystem ...
           - traversal finished ...
           - moving disconnected inodes to lost+found ...
   Phase 7 - verify and correct link counts...
   done

3. Scollega il volume secondario (/dev/sdf) dall'istanza di ripristino. Quindi, collegalo all'istanza originale come /dev/xvda (volume root).

4. Avvia l'istanza e verifica se è reattiva.

Risoluzione dei problemi relativi a "interface eth0: failed"

Verifica che le voci di rete del file ifcfg-eth0 siano corrette. Il file della configurazione di rete corrispondente all'interfaccia primaria, eth0, si trova in /etc/sysconfig/network-scripts/ifcfg-eth0. Se il nome del dispositivo dell'interfaccia principale non è eth0, il nome del file inizia con ifcfg ed è seguito dal nome del dispositivo. Il file si trova nella directory /etc/sysconfig/network-scripts dell'istanza.

1. Esegui il comando cat per visualizzare il file di configurazione di rete per l'interfaccia primaria, eth0.

   Le seguenti sono le voci corrette per il file di configurazione di rete che si trova in /etc/sysconfig/network-scripts/ifcfg-eth0.

   Nota: se necessario, sostituisci eth0 nel seguente comando con il nome della tua interfaccia principale.

   $ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
   DEVICE=eth0
   BOOTPROTO=dhcp
   ONBOOT=yes
   TYPE=Ethernet
   USERCTL=yes
   PEERDNS=yes
   DHCPV6C=yes
   DHCPV6C_OPTIONS=-nw
   PERSISTENT_DHCLIENT=yes
   RES_OPTIONS="timeout:2 attempts:5"
   DHCP_ARP_CHECK=no

2. Verifica che ONBOOT sia impostato su yes. Se ONBOOT non è impostato su yes, significa che eth0 (o la tua interfaccia di rete principale) non dispone della configurazione per la visualizzazione all'avvio.

   Per modificare il valore ONBOOT, apri prima il file in un editor. Questo esempio utilizza l'editor vi:

   $ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

   Premi I per inserire i valori.

   Scorri il cursore fino alla voce ONBOOT, quindi modifica il valore in yes.

   Per salvare e uscire dal file, premi :wq!

3. Esegui il comando unmount per smontare il dispositivo secondario dall'istanza di ripristino:

   $ sudo umount /rescue

   Se l'operazione di smontaggio non va a buon fine, potrebbe essere necessario interrompere o riavviare l'istanza di ripristino per inizializzare uno smontaggio corretto.

4. Scollega il volume secondario (/dev/sdf) dall'istanza di ripristino. Quindi, collegalo all'istanza originale come /dev/xvda (volume root).

5. Avvia l'istanza e verifica se è reattiva.

Informazioni correlate

Perché la mia istanza Linux EC2 è irraggiungibile e non supera i controlli di stato?

Troubleshoot instances with failed status checks

Perché la mia istanza Linux non si avvia dopo aver cambiato il tipo con un tipo di istanza basato su Nitro?