Risolvi i problemi delle istanze Amazon EC2 Linux con controlli di stato non riusciti - Amazon Elastic Compute Cloud
Esame delle informazioni di verifica dello statoRecupero dei log di sistemaRisolvi gli errori di registro di sistema per le istanze LinuxOut of memory: kill processERROR: mmu_update non riuscito (aggiornamento della gestione della memoria non riuscito)I/O Error (errore dei dispositivi a blocchi)I/OERROR: né disco locale né remoto (dispositivo a blocchi distribuito rotto)request_module: runaway loop modprobe (looping del modprobe del kernel legacy sulle versioni precedenti di Linux)"FATAL: kernel too old» e «fsck: File o directory inesistenti durante il tentativo di aprire /dev" (Kernel e mismatch) AMI "FATAL: Impossibile caricare /lib/modules" o "BusyBox" (moduli del kernel mancanti)ERRORKernel non valido (kernel incompatibile) EC2fsck: No such file or directory while trying to open... file system non trovatoGeneral error mounting filesystems (errore di montaggio)VFS: Impossibile montare root fs su un blocco sconosciuto (mancata corrispondenza del filesystem root)Error: Unable to determine major/minor number of root device... (mancata corrispondenza file system/dispositivo root)XENBUS: Dispositivo senza driver...... days without being checked, check forced (verifica del file system richiesta)fsck died with exit status... (dispositivo mancante)GRUBprompt (grubdom>)Visualizzazione dell'interfaccia eth0: il dispositivo eth0 ha un MAC indirizzo diverso da quello previsto, che viene ignorato. (Indirizzo codificato) MAC Impossibile caricare SELinux la politica. Machine is in enforcing mode. Halting now. (SELinuxconfigurazione errata)XENBUS: Timeout per la connessione ai dispositivi (timeout Xenbus)

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risolvi i problemi delle istanze Amazon EC2 Linux con controlli di stato non riusciti

Le seguenti informazioni possono aiutarti a risolvere i problemi se l'istanza Linux non supera il controllo dello stato. Determina innanzitutto se le applicazioni in uso presentano dei problemi. Se risulta che l'istanza non esegue le applicazioni come previsto, esamina le informazioni di verifica dello stato e i log di sistema.

Per vedere degli esempi di problemi che causano il mancato superamento dei controlli dello stato, vedere Controlli dello stato per le EC2 istanze Amazon.

Indice

Esame delle informazioni di verifica dello stato

Per esaminare le istanze danneggiate utilizzando la console Amazon EC2
  1. Apri la EC2 console Amazon all'indirizzo https://console.aws.amazon.com/ec2/.

  2. Nel pannello di navigazione, scegli Instances (Istanze) e seleziona l'istanza desiderata.

  3. Nel riquadro dei dettagli scegliere Stato e allarmi per visualizzare i singoli risultati di tutte le Verifiche dello stato del sistema e le Verifiche dello stato delle istanze.

Se una verifica dello stato del sistema ha avuto esito negativo, provare una delle seguenti opzioni:

  • Creare un allarme di ripristino istanze. Per ulteriori informazioni, consulta Creazione di allarmi che arrestano, terminano, riavviano o recuperano un'istanza.

  • Se hai cambiato il tipo di istanza con un'istanza basata su AWS Nitro System, i controlli di stato hanno esito negativo se hai eseguito la migrazione da un'istanza che non dispone dei driver ENA e NVMe dei requisiti. Per ulteriori informazioni, consulta Compatibilità per la modifica del tipo di istanza.

  • Per un'istanza che utilizza un'istanza EBS supportata da AmazonAMI, interrompi e riavvia l'istanza.

  • Per un'istanza che utilizza un'istanza supportata da instance-storeAMI, interrompi l'istanza e avvia un'istanza sostitutiva.

  • Attendi EC2 che Amazon risolva il problema.

  • Pubblica un post relativo alla tua problematica su AWS re:Post.

  • Se la tua istanza fa parte di un gruppo Auto Scaling, il servizio Amazon Auto EC2 Scaling avvia automaticamente un'istanza sostitutiva. Per ulteriori informazioni, consulta Health Checks for Auto Scaling Instances nella Amazon EC2Auto Scaling User Guide.

  • Recuperare il log di sistema e individuare eventuali errori.

Recupero dei log di sistema

Se la verifica dello stato di un'istanza ha esito negativo, è possibile riavviare l'istanza e recuperare i log di sistema. Questi log possono rivelare la presenza di un errore che può aiutare a risolvere il problema. Il riavvio elimina le informazioni inutili dai log.

Per riavviare un'istanza e recuperare il log di sistema
  1. Apri la EC2 console Amazon all'indirizzo https://console.aws.amazon.com/ec2/.

  2. Nel riquadro di navigazione scegliere Instances (Istanze) e selezionare l'istanza desiderata.

  3. Scegliere Instance state (Stato istanza), Reboot instance (Riavvia istanza). Per il riavvio dell'istanza possono essere necessari alcuni minuti.

  4. Verificare se il problema è ancora presente; talvolta il riavvio consente di risolvere il problema.

  5. Quando l'istanza è in stato running, selezionare Actions (Operazioni), Monitor and troubleshoot (Monitoraggio e risoluzione dei problemi), Get system log (Ottieni il log di sistema).

  6. Esaminare il log visualizzato e utilizzare l'elenco delle dichiarazioni di errore note del log di sistema per risolvere il problema.

  7. Se la problematica non si risolve, puoi pubblicare un post relativo a tale problematica su AWS re:Post.

Risolvi gli errori di registro di sistema per le istanze Linux

Per le istanze Linux che non hanno superato un controllo dello stato dell'istanza, ad esempio il controllo di raggiungibilità dell'istanza, verifica di aver seguito i passaggi precedenti per recuperare il registro di sistema. L'elenco seguente contiene alcuni errori comuni del log di sistema e suggerisce alcune operazioni che potrebbero risolvere il problema di ogni errore.

Errori di memoria

Errori dei dispositivi

Errori del kernel

Errori del file system

Errori del sistema operativo

Out of memory: kill process

Un out-of-memory errore viene indicato da una voce del registro di sistema simile a quella mostrata di seguito.

[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

Causa potenziale

Memoria esaurita

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Esegui una di queste operazioni:

  • Arrestare l'istanza e modificarla per utilizzarne un tipo diverso, quindi avviare nuovamente l'istanza. Ad esempio un tipo di istanza più grande o ottimizzata per la memoria.

  • Riavviare l'istanza affinché torni a uno stato non danneggiato. Se non si cambia il tipo di istanza, probabilmente il problema si ripeterà.

Supportata da instance store

Scegliere una delle seguenti operazioni:

  • Terminare l'istanza e avviarne una nuova, specificando un tipo di istanza diverso. Ad esempio un tipo di istanza più grande o ottimizzata per la memoria.

  • Riavviare l'istanza affinché torni a uno stato non danneggiato. Se non si cambia il tipo di istanza, probabilmente il problema si ripeterà.

ERROR: mmu_update non riuscito (aggiornamento della gestione della memoria non riuscito)

Gli errori relativi all'aggiornamento della gestione della memoria sono indicati da una voce del log di sistema simile alla seguente:

... 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

Causa potenziale

Problema con Amazon Linux

Operazione suggerita

Pubblicare il problema sui forum per sviluppatori oppure contattare AWS Support.

I/O Error (errore dei dispositivi a blocchi)

Un errore di ingressi/uscite viene indicato da una voce del log di sistema simile all'esempio riportato di seguito:

[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 ...

Cause potenziali

Tipo di istanza Causa potenziale

Supportato EBS da Amazon

Un EBS volume Amazon non funzionante

Supportata da instance store

Un'unità fisica in stato di errore

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza.

  2. Distaccare il volume.

  3. Tentare di ripristinare il volume.

    Nota

    È buona norma eseguire spesso uno snapshot dei EBS volumi Amazon. per ridurre notevolmente il rischio di perdite di dati dovuti a guasti.

  4. Ricollegare il volume all'istanza.

  5. Avviare l'istanza.

Supportata da instance store

Terminare l'istanza e avviarne una nuova.

Nota

Non è possibile ripristinare i dati. Eseguire il ripristino dai backup.

Nota

È buona norma utilizzare Amazon S3 o Amazon EBS per i backup. I volumi instance store sono legati direttamente agli errori dei singoli host e dei singoli dischi.

I/OERROR: né disco locale né remoto (dispositivo a blocchi distribuito rotto)

Un errore di ingressi/uscite sul dispositivo viene indicato da una voce del log di sistema simile all'esempio riportato di seguito:

... 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.

Cause potenziali

Tipo di istanza Causa potenziale

Supportato EBS da Amazon

Un EBS volume Amazon non funzionante

Supportata da instance store

Un'unità fisica in stato di errore

Operazione suggerita

Terminare l'istanza e avviarne una nuova.

Per un'istanza EBS supportata da Amazon, puoi recuperare i dati da uno snapshot recente creandone un'immagine. I dati eventualmente aggiunti dopo la snapshot non possono essere ripristinati.

request_module: runaway loop modprobe (looping del modprobe del kernel legacy sulle versioni precedenti di Linux)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto. L'utilizzo di un kernel Linux instabile o datato (ad esempio 2.6.16-xenU) può causare una condizione di loop interminabile all'avvio.

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (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

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Usa un kernel più recente, GRUB basato o statico, usando una delle seguenti opzioni:

Opzione 1: terminare l'istanza e avviarne una nuova, specificando i parametri -kernel e -ramdisk.

Opzione 2:

  1. Arrestare l'istanza.

  2. Modificare gli attributi di kernel e ramdisk per utilizzare un kernel più recente.

  3. Avviare l'istanza.

Supportata da instance store

Terminare l'istanza e avviarne una nuova, specificando i parametri -kernel e -ramdisk.

"FATAL: kernel too old» e «fsck: File o directory inesistenti durante il tentativo di aprire /dev" (Kernel e mismatch) AMI

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

Linux version 2.6.16.33-xenU (root@dom0-0-50-45-1-a4-ee.z-2.aes0.internal) (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!

Cause potenziali

Kernel e userland non compatibili

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza.

  2. Modificare la configurazione per utilizzare un kernel più recente.

  3. Avviare l'istanza.

Supportata da instance store

Attenersi alla seguente procedura:

  1. Crea un file AMI che utilizzi un kernel più recente.

  2. Terminare l'istanza.

  3. Avvia una nuova istanza da quella AMI che hai creato.

"FATAL: Impossibile caricare /lib/modules" o "BusyBox" (moduli del kernel mancanti)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

[ 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)

Cause potenziali

Questo problema può essere causato da una o più delle condizioni seguenti:

  • Ramdisk mancante

  • Moduli corretti mancanti nel ramdisk

  • Volume EBS root Amazon non collegato correttamente come /dev/sda1

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Seleziona ramdisk corretto per il volume AmazonEBS.

  2. Arrestare l'istanza.

  3. Distaccare il volume e ripararlo.

  4. Collegare il volume all'istanza.

  5. Avviare l'istanza.

  6. Modifica il AMI per utilizzare il ramdisk corretto.

Supportata da instance store

Attenersi alla seguente procedura:

  1. Terminare l'istanza e avviarne una nuova con il ramdisk corretto.

  2. Creane uno nuovo AMI con il ramdisk corretto.

ERRORKernel non valido (kernel incompatibile) EC2

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

... 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

Cause potenziali

Questo problema può essere causato da una o entrambe le condizioni seguenti:

  • Il kernel fornito non è supportato da GRUB

  • Il kernel di fallback non esiste

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza.

  2. Sostituire con un kernel funzionante.

  3. Installare un kernel di fallback.

  4. Modifica il AMI correggendo il kernel.

Supportata da instance store

Attenersi alla seguente procedura:

  1. Terminare l'istanza e avviarne una nuova con il kernel corretto.

  2. Crea un file AMI con il kernel corretto.

  3. (Opzionale) Richiedere assistenza tecnica per il ripristino dei dati tramite AWS Support.

fsck: No such file or directory while trying to open... file system non trovato

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

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):

Cause potenziali

  • È presente un bug nelle definizioni del file system del ramdisk /etc/fstab

  • Le definizioni del file system non sono configurate correttamente in /etc/fstab

  • Unità mancante o in stato di errore

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza, distaccare il volume root, riparare o modificare il file di configurazione /etc/fstab del volume, collegare il volume all'istanza e avviare l'istanza.

  2. Correggere il ramdisk per includere il file /etc/fstab modificato (se applicabile).

  3. Modificalo AMI per utilizzare un ramdisk più recente.

Il sesto campo nel file fstab definisce i requisiti di disponibilità del punto di montaggio (un valore diverso da zero implica l'esecuzione di un fsck su quel volume che deve avere esito positivo). L'utilizzo di questo campo può essere problematico in Amazon EC2 perché un errore in genere comporta un prompt interattivo della console che non è attualmente disponibile in Amazon. EC2 Prestare attenzione a questa caratteristica e leggere la pagina man di Linux relativa al file fstab.

Supportata da instance store

Attenersi alla seguente procedura:

  1. Terminare l'istanza e avviarne una nuova.

  2. Scollega eventuali EBS volumi Amazon errati e l'istanza di riavvio.

  3. (Opzionale) Richiedere assistenza tecnica per il ripristino dei dati tramite AWS Support.

General error mounting filesystems (errore di montaggio)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

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):

Cause potenziali

Tipo di istanza Causa potenziale

Supportato EBS da Amazon

  • EBSVolume Amazon scollegato o guasto.

  • File system danneggiato.

  • Ramdisk e AMI combinazione non corrispondenti (ad esempio ramdisk Debian con a). SUSE AMI

Supportata da instance store

  • Unità in stato di errore.

  • File system danneggiato.

  • Ramdisk e combinazione non corrispondenti (ad esempio, un ramdisk Debian con a). SUSE AMI

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza.

  2. Distaccare il volume root.

  3. Collegare il volume root a un'istanza funzionante nota.

  4. Esegui il controllo del file system (fsck -a /dev/...).

  5. Correggere eventuali errori.

  6. Distaccare il volume dall'istanza funzionante nota.

  7. Collegare il volume all'istanza arrestata.

  8. Avviare l'istanza.

  9. Verificare di nuovo lo stato dell'istanza.

Supportata da instance store

Provare con una delle seguenti operazioni:

  • Avviare una nuova istanza.

  • (Opzionale) Richiedere assistenza tecnica per il ripristino dei dati tramite AWS Support.

VFS: Impossibile montare root fs su un blocco sconosciuto (mancata corrispondenza del filesystem root)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (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)

Cause potenziali

Tipo di istanza Causa potenziale

Supportato EBS da Amazon

  • Dispositivo non collegato correttamente.

  • Dispositivo root non collegato al punto corretto.

  • File system non nel formato previsto.

  • Uso del kernel legacy (come 2.6.16-XenU).

  • Aggiornamento recente del kernel sull'istanza (aggiornamento errato o bug dell'aggiornamento).

Supportata da instance store

Errore dei dispositivi hardware.

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Esegui una di queste operazioni:

  • Arrestare e riavviare l'istanza.

  • Modificare il volume root da collegare al punto dispositivi corretto, possibilmente /dev/sda1 invece di /dev/sda.

  • Arrestare e modificare per usare un kernel moderno.

  • Per controllare i bug di aggiornamento noti, consultare la documentazione della distribuzione Linux in uso. Cambiare o reinstallare il kernel.

Supportata da instance store

Terminare l'istanza e avviarne una nuova utilizzando un kernel moderno.

Error: Unable to determine major/minor number of root device... (mancata corrispondenza file system/dispositivo root)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

... 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 /]#

Cause potenziali

  • Driver dispositivi a blocchi virtuali mancante o configurato in modo non corretto

  • Conflitto di enumerazione dei dispositivi (sda versus xvda o sda invece di sda1)

  • Scelta errata del kernel dell'istanza

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza.

  2. Distaccare il volume.

  3. Correggere il problema di mappatura dei dispositivi.

  4. Avviare l'istanza.

  5. Modifica il AMI per risolvere i problemi di mappatura dei dispositivi.

Supportata da instance store

Attenersi alla seguente procedura:

  1. Creane uno nuovo AMI con la correzione appropriata (mappa il dispositivo deve essere bloccato correttamente).

  2. Termina l'istanza e avvia una nuova istanza dall'istanza AMI che hai creato.

XENBUS: Dispositivo senza driver...

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

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 /]#

Cause potenziali

  • Driver dispositivi a blocchi virtuali mancante o configurato in modo non corretto

  • Conflitto di enumerazione dei dispositivi (sda versus xvda)

  • Scelta errata del kernel dell'istanza

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza.

  2. Distaccare il volume.

  3. Correggere il problema di mappatura dei dispositivi.

  4. Avviare l'istanza.

  5. Modifica il AMI per risolvere i problemi di mappatura dei dispositivi.

Supportata da instance store

Attenersi alla seguente procedura:

  1. Crea un dispositivo AMI con la correzione appropriata (mappa correttamente il dispositivo).

  2. Termina l'istanza e avvia una nuova istanza utilizzando l'istanza AMI che hai creato.

... days without being checked, check forced (verifica del file system richiesta)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

... 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

Cause potenziali

Il momento della verifica del file system è trascorso; viene forzata una verifica del file system.

Operazioni suggerite

  • Attendere il completamento della verifica del file system. Una verifica del file system può richiedere molto tempo a seconda delle dimensioni del file system root.

  • Modificare i file system per rimuovere l'applicazione della relativa verifica (fsck) utilizzando tune2fs o strumenti appropriati al file system in uso.

fsck died with exit status... (dispositivo mancante)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

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

Cause potenziali

  • Ramdisk in cerca di unità mancante

  • Verifica di consistenza del file system forzata

  • Unità in stato di errore o distaccata

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Tentare una o più delle operazioni seguenti per risolvere il problema:

  • Arrestare l'istanza e collegare il volume a un'istanza in esecuzione esistente.

  • Eseguire manualmente le verifiche di coerenza.

  • Correggere il ramdisk per includere le utility pertinenti.

  • Modificare i parametri di ottimizzazione del file system per rimuovere i requisiti di coerenza (operazione non consigliata).

Supportata da instance store

Tentare una o più delle operazioni seguenti per risolvere il problema:

  • Ricompilare il ramdisk con gli strumenti corretti.

  • Modificare i parametri di ottimizzazione del file system per rimuovere i requisiti di coerenza (operazione non consigliata).

  • Terminare l'istanza e avviarne una nuova.

  • (Opzionale) Richiedere assistenza tecnica per il ripristino dei dati tramite AWS Support.

GRUBprompt (grubdom>)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

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>

Cause potenziali

Tipo di istanza Cause potenziali

Supportato EBS da Amazon

  • File di GRUB configurazione mancante.

  • È stata utilizzata GRUB un'immagine errata, in attesa GRUB di un file di configurazione in una posizione diversa.

  • Filesystem non supportato utilizzato per archiviare il file di GRUB configurazione (ad esempio, conversione del file system root in un tipo non supportato da una versione precedente di). GRUB

Supportata da instance store

  • GRUBFile di configurazione mancante.

  • È stata utilizzata GRUB un'immagine errata, in attesa GRUB di un file di configurazione in una posizione diversa.

  • Filesystem non supportato utilizzato per archiviare il file di GRUB configurazione (ad esempio, conversione del file system root in un tipo non supportato da una versione precedente di). GRUB

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Opzione 1: modifica AMI e riavvia l'istanza:

  1. Modificate il codice sorgente AMI per creare un file di GRUB configurazione nella posizione standard (/boot/grub/menu.lst).

  2. Verificate che la vostra versione di GRUB supporti il tipo di file system sottostante e aggiornatela se necessario. GRUB

  3. Scegliete l'GRUBimmagine appropriata (hd0-1st drive o hd00 — 1st drive, 1st partition).

  4. Termina l'istanza e avviane una nuova utilizzando quella che hai creato. AMI

Opzione 2: correggere l'istanza esistente:

  1. Arrestare l'istanza.

  2. Distaccare il file system root.

  3. Collegare il file system root a un'istanza funzionante nota.

  4. Montare il file system.

  5. Crea un file GRUB di configurazione.

  6. Verificate che la versione di in GRUB uso supporti il tipo di file system sottostante e, GRUB se necessario, aggiornatela.

  7. Distaccare il file system.

  8. Collegare all'istanza originale.

  9. Modifica l'attributo del kernel per utilizzare l'GRUBimmagine appropriata (primo disco o prima partizione sul primo disco).

  10. Avviare l'istanza.

Supportata da instance store

Opzione 1: modifica AMI e riavvia l'istanza:

  1. Create la nuova AMI con un file di GRUB configurazione nella posizione standard (/boot/grub/menu.lst).

  2. Scegliete l'GRUBimmagine appropriata, (unità hd0-1st o hd00 — prima unità, prima partizione).

  3. Verificate che la versione di in uso GRUB supporti il tipo di file system sottostante e aggiornatela se necessario. GRUB

  4. Termina l'istanza e avvia una nuova istanza utilizzando l'istanza AMI che hai creato.

Opzione 2: terminare l'istanza e avviarne una nuova specificando il kernel corretto.

Nota

Per ripristinare i dati dell'istanza esistente, contatta AWS Support.

Visualizzazione dell'interfaccia eth0: il dispositivo eth0 ha un MAC indirizzo diverso da quello previsto, che viene ignorato. (Indirizzo codificato) MAC

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

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

Cause potenziali

Nella configurazione è presente un'interfaccia codificata MAC AMI

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Esegui una di queste operazioni:

  • Modifica il AMI per rimuovere il codice rigido e riavviare l'istanza.

  • Modifica l'istanza per rimuovere l'indirizzo codificato. MAC

O

Attenersi alla seguente procedura:

  1. Arrestare l'istanza.

  2. Distaccare il volume root.

  3. Collega il volume a un'altra istanza e modifica il volume per rimuovere l'indirizzo MAC codificato.

  4. Collegare il volume all'istanza originale.

  5. Avviare l'istanza.

Supportata da instance store

Esegui una di queste operazioni:

  • Modifica l'istanza per rimuovere l'indirizzo MAC codificato.

  • Terminare l'istanza e avviarne una nuova.

Impossibile caricare SELinux la politica. Machine is in enforcing mode. Halting now. (SELinuxconfigurazione errata)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

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!

Cause potenziali

SELinuxè stato abilitato per errore:

  • Il kernel fornito non è supportato da GRUB

  • Il kernel di fallback non esiste

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Attenersi alla seguente procedura:

  1. Arrestare l'istanza non riuscita.

  2. Distaccare il volume root dell'istanza non riuscita.

  3. Collegare il volume root a un'altra istanza Linux in esecuzione (in seguito detta istanza di ripristino).

  4. Connettersi all'istanza di ripristino e montare il volume root dell'istanza non riuscita.

  5. Disabilita SELinux sul volume root montato. Questo processo varia tra le distribuzioni Linux; per ulteriori informazioni, consultare la documentazione specifica del sistema operativo in uso.

    Nota

    Su alcuni sistemi, si disattiva SELinux impostando SELINUX=disabled nel /mount_point/etc/sysconfig/selinux file, dove si trova la posizione in cui mount_point è stato montato il volume sull'istanza di ripristino.

  6. Smontare e distaccare il volume root dall'istanza di ripristino e ricollegarlo all'istanza originale.

  7. Avviare l'istanza.

Supportata da instance store

Attenersi alla seguente procedura:

  1. Terminare l'istanza e avviarne una nuova.

  2. (Opzionale) Richiedere assistenza tecnica per il ripristino dei dati tramite AWS Support.

XENBUS: Timeout per la connessione ai dispositivi (timeout Xenbus)

Questa condizione viene indicata da un log di sistema simile a quello mostrato sotto.

Linux version 2.6.16-xenU (builder@xenbat.amazonsa) (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.

Cause potenziali

  • Il dispositivo a blocchi non è connesso all'istanza

  • L'istanza utilizza un kernel datato.

Operazioni suggerite

Per questo tipo di istanza Esegui questa operazione

Supportato EBS da Amazon

Esegui una di queste operazioni:

  • Modifica l'istanza AMI and per utilizzare un kernel moderno e riavvia l'istanza.

  • Riavviare l'istanza.

Supportata da instance store

Scegliere una delle seguenti operazioni:

  • Terminare l'istanza.

  • Modifica il kernel AMI per utilizzare un kernel moderno e avvia una nuova istanza utilizzando questo. AMI