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?
I controlli dello stato delle istanze sulla mia istanza Linux Amazon Elastic Compute Cloud (Amazon EC2) hanno esito negativo a causa di problemi del sistema operativo. Ora l'istanza non si avvia correttamente.
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
Esistono tre metodi per risolvere i problemi del sistema operativo.
Importante: alcune delle seguenti procedure richiedono l'arresto dell'istanza. I dati archiviati nei volumi di archivio dell'istanza vengono persi quando l'istanza viene fermata. Assicurati di salvare un backup dei dati prima di interrompere l'istanza. A differenza dei volumi supportati da Amazon Elastic Block Store (Amazon EBS), i volumi di archivio dell'istanza sono temporanei e non supportano la persistenza dei dati.
L'indirizzo IPv4 pubblico statico che Amazon EC2 ha assegnato automaticamente all'istanza all'avvio o all'inizio 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.
Per ulteriori informazioni, vedi Arrestare e avviare automaticamente le istanze.
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 si connette all'istanza senza necessitare di 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).
Se utilizzi la console seriale EC2 per la prima volta, assicurati di rivedere i prerequisiti e configurare l'accesso prima di provare a connetterti.
Se la tua istanza non è raggiungibile e non hai configurato l'accesso alla console seriale, segui le istruzioni in Esegui lo strumento EC2Rescue per Linux o Usa un'istanza di ripristino. Per informazioni sulla configurazione della console seriale EC2 per Linux, consulta Configurazione dell'accesso alla console seriale EC2.
Nota: se visualizzi errori durante l'esecuzione dei comandi dell'Interfaccia della linea di comando AWS, assicurati di utilizzare la versione più recente di AWS CLI.
Esegui lo strumento EC2Rescue per Linux
EC2Rescue per Linux diagnostica e risolve automaticamente i problemi dei sistemi operativi su istanze irraggiungibili. Per ulteriori informazioni, consulta Come posso usare EC2Rescue per Linux per risolvere problemi a livello di sistema operativo?
Correzione manuale degli errori utilizzando un'istanza di ripristino
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 di Amazon Elastic Block Store (Amazon EBS) (/dev/xvda o**/dev/sda1**) dall'istanza danneggiata. Annota il nome del dispositivo (/dev/xvda o /dev/sda1) 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 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 Tipo Fs errato o duplicato UUID, Superblock mancante o trovato un badblock, 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 ulteriori errori, consulta Risoluzione degli errori del log di sistema per le istanze basate su Linux.
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, quindi verrà 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/o vmlinuz non sono presenti, prova ad avviare l'istanza utilizzando un kernel precedente che contiene entrambi questi file. Per istruzioni su come avviare l'istanza utilizzando un kernel precedente, consulta How do I revert to a known stable kernel after an update prevents my Amazon EC2 instance from rebooting successfully?
4. Esegui il comando smonta 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 collega il volume all'istanza originale come /dev/xvda (volume root).
6. Avvia l'istanza, quindi verifica se l'istanza è reattiva.
Per ulteriori 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?
Montaggio non riuscito o Dipendenza non riuscita
Errori quali "Montaggio non riuscito" o "Dipendenza non riuscita" 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 informazioni sulla correzione delle voci del file /etc/fstab, consulta la sezione Auto mount failures because of incorrect entries in the /etc/fstab file di Why is my EC2 Linux instance going into emergency mode when I try to boot it?
2. È consigliabile eseguire lo strumento fsck o xfs_repair per correggere eventuali errori del file system. Se ci sono incongruenze nel file system, lo strumento fsck o xfs_repair le corregge.
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:
$ 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:
$ 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 collega il volume all'istanza originale come /dev/xvda (volume root).
4. Avvia l'istanza, quindi verifica se l'istanza è reattiva.
Avvio dell'interfaccia eth0: non riuscito
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, è presente un file che 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: sostituisci eth0 nel seguente comando con il nome della tua interfaccia principale, se diversa.
$ 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, come mostrato nell'esempio precedente. Se ONBOOT non è impostato su yes, significa che eth0 (o la tua interfaccia di rete principale) non è configurato per essere visualizzato all'avvio.
Per modificare il valore ONBOOT:
apri il file in un editor. In questo esempio, viene utilizzato 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.
Salva ed esci dal file premendo**:wq!**
3. Esegui il comando smonta 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 consentire uno smontaggio corretto.
4. Scollega il volume secondario (/dev/sdf) dall'istanza di ripristino, quindi collega il volume all'istanza originale come /dev/xvda (volume root).
5. Avvia l'istanza e verifica se è reattiva
Informazioni correlate
Risoluzione dei problemi relativi alle istanze con esito negativo delle verifiche dello stato
Contenuto pertinente
- AWS UFFICIALEAggiornata 9 mesi fa
- AWS UFFICIALEAggiornata 10 mesi fa