Amazon Elastic Compute Cloud
Guía del usuario de instancias de Linux

Solucione los problemas de las instancias con comprobaciones de estado no superadas.

Temas

Pasos iniciales

Si la instancia no supera una comprobación de estado, determine en primer lugar si las aplicaciones muestran algún problema. Para comprobar si las instancias no ejecutan las aplicaciones como se espera, siga estos pasos:

Para investigar las instancias en mal estado con la consola de Amazon EC2

  1. Abra la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.

  2. En el panel de navegación, elija Instances y seleccione la instancia.

  3. En el panel de detalles, elija Status Checks para ver los resultados individuales de todas las System Status Checks e Instance Status Checks.

Si una comprobación de estado del sistema ha dado error, intente con alguna de las opciones siguientes:

  • Cree una alarma de recuperación de instancias. Para obtener más información, consulte Crear alarmas para parar, terminar, reiniciar o recuperar una instancia en la guía Guía del usuario de Amazon CloudWatch.

  • Con una instancia que use una AMI respaldada por Amazon EBS, detenga y reinicie la instancia.

  • Con una instancia que use una AMI respaldada por un almacén de instancias, termine la instancia y lance un remplazo.

  • Espere a que Amazon EC2 resuelva el problema.

  • Envíe el problema al Amazon EC2 forum.

  • Recupere el registro del sistema y busque errores.

Recuperación de los logs del sistema

Si la comprobación de estado de la instancia da error, puede reiniciar la instancia y recuperar los logs del sistema. Los logs pueden revelar un error que puede ayudarle a solucionar el problema. La reinicialización elimina la información innecesaria de los logs.

Para reiniciar una instancia y recuperar el registro del sistema

  1. Abra la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/.

  2. En el panel de navegación, elija Instances y seleccione la instancia.

  3. Elija Actions, Instance State, Reboot. El reinicio de la instancia puede demorar unos minutos.

  4. Verifique que el problema persiste, ya que en algunos casos, el reinicio puede solucionarlo.

  5. Cuando la instancia esté en estado running, elija Actions, Instance Settings, Get System Log.

  6. Revise el log que aparece en la pantalla y use la lista enunciados de errores conocidos del registro del sistema para solventar el problema.

  7. Si su experiencia difiere de los resultados de comprobación o si tiene algún problema en la instancia no detectado en nuestras comprobaciones, elija Submit feedback en la pestaña Status Checks para ayudarnos a mejorar nuestras pruebas de detección.

  8. Si el problema no se resuelve, puede publicarlo en el Amazon EC2 forum.

Solución de errores del registro del sistema en instancias basadas en Linux

En las instancias basadas en Linux que han dado error en la comprobación de estado, como la prueba accesibilidad de la instancia, compruebe que ha seguido los pasos anteriores para recuperar el registro del sistema. La lista siguiente incluye algunos errores habituales del sistema y sugiere acciones que se pueden tomar para solucionarlos.

Errores de memoria

Errores de dispositivo

Errores de Kernel

Errores del sistema de archivos

Errores del sistema operativo

Out of memory: kill process

Un error de falta de memoria viene indicado en una entrada del log del sistema similar a la siguiente.

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

Memoria agotada

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Aplique alguna de las siguientes acciones:

  • Detenga la instancia y modifíquela para usar un tipo de instancia diferente, y vuelva a iniciarla. Por ejemplo, un tipo de instancia mayor u optimizada para memoria.

  • Reinicie la instancia para devolverla a un estado no deteriorado. Es probable que el problema vuelva a producirse a menos que cambie el tipo de instancia.

Con respaldo en el almacén de instancias

Aplique alguna de las siguientes acciones:

  • Termine la instancia y lance una nueva especificando un tipo de instancia distinto. Por ejemplo, un tipo de instancia mayor u optimizada para memoria.

  • Reinicie la instancia para devolverla a un estado no deteriorado. Es probable que el problema vuelva a producirse a menos que cambie el tipo de instancia.

ERROR: mmu_update failed (Memory management update failed)

Los errores de actualización de administración de memoria se indican con una entrada de registro similar a la siguiente:

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

Problema con Amazon Linux

Acción sugerida

Publique el problema en el foro de desarrolladores o contacte con AWS Support.

Error de E/S (error del dispositivo de bloques)

Un error de entrada/salida viene indicado en una entrada del registro del sistema similar al ejemplo siguiente:

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

Causas posibles

Tipo de instancia Causa posible

Respaldada por Amazon EBS

Un volumen de Amazon EBS con errores

Con respaldo en el almacén de instancias

Una unidad física fallida

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Detenga la instancia.

  2. Retire el volumen.

  3. Intente recuperar el volumen.

    nota

    Es una práctica recomendada tomar una instantánea de los volúmenes de Amazon EBS con frecuencia. Esto reduce de manera significativa el riesgo de pérdida de datos como resultado de un error.

  4. Vuelva a adjuntar el volumen a la instancia.

  5. Retire el volumen.

Con respaldo en el almacén de instancias

Termine la instancia y lance una nueva.

nota

No se pueden recuperar los datos. Recupere a partir de los backup.

nota

Es una práctica recomendada usar bien Amazon S3 o Amazon EBS para crear backup. Los volúmenes con almacén de instancias se vinculan directamente con errores de host único y de disco único.

I/O ERROR: neither local nor remote disk (Broken distributed block device)

Un error de entrada/salida en el dispositivo viene indicado en una entrada del registro del sistema similar al ejemplo siguiente:

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

Causas posibles

Tipo de instancia Causa posible

Respaldada por Amazon EBS

Un volumen de Amazon EBS con errores

Con respaldo en el almacén de instancias

Una unidad física fallida

Acción sugerida

Termine la instancia y lance una nueva.

En el caso de una instancia respaldada por Amazon EBS, puede recuperar los datos desde una instantánea reciente creando una imagen de esta. Cualquier dato agregado después de tomar la instantánea no se recuperará.

request_module: runaway loop modprobe (Looping legacy kernel modprobe on older Linux versions)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente. El uso de un kernel de Linux antiguo o inestable (por ejemplo, 2.6.16-xenU) puede provocar un problema de bucle infinito en el inicio.

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

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use un kernel más reciente, bien basado en GRUB o estático, con una de las opciones siguientes:

Opción 1: Termine la instancia y lance una nueva especificando los parámetros –kernel y –ramdisk.

Opción 2:

  1. Detenga la instancia.

  2. Modifique el kernel y los atributos ramdisk para usar el kernel nuevo.

  3. Inicie la instancia.

Con respaldo en el almacén de instancias

Termine la instancia y lance una nueva especificando los parámetros –kernel y –ramdisk.

"FATAL: kernel too old" and "fsck: No such file or directory while trying to open /dev" (Kernel and AMI mismatch)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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!

Causas posibles

Kernel y espacio de usuario incompatibles

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Detenga la instancia.

  2. Modifique la configuración para usar un nuevo kernel.

  3. Inicie la instancia.

Con respaldo en el almacén de instancias

Use el procedimiento siguiente:

  1. Cree una AMI que use un kernel más reciente.

  2. Termine la instancia.

  3. Inicie una nueva instancia desde la AMI que ha creado.

"FATAL: Could not load /lib/modules" o "BusyBox" (Missing kernel modules)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

Este problema puede deberse a una o varias de las siguientes causas:

  • Falta ramdisk

  • Faltan los módulos correctos de ramdisk

  • El volumen raíz de Amazon EBS no está correctamente adjuntado como /dev/sda1

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Seleccione el ramdisk corregido para el volumen Amazon EBS.

  2. Detenga la instancia.

  3. Separe el volumen y arréglelo.

  4. Adjunte el volumen a la instancia.

  5. Inicie la instancia.

  6. Modifique la AMI para usar el ramdisk corregido.

Con respaldo en el almacén de instancias

Use el procedimiento siguiente:

  1. Termine la instancia y lance una nueva con el ramdisk correcto.

  2. Cree una nueva AMI con el ramdisk correcto.

ERROR Invalid kernel (EC2 incompatible kernel)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

Esto puede deberse a uno o a ambos de los problemas siguientes:

  • El kernel proporcionado no es compatible con GRUB

  • No existe kernel alternativo

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Detenga la instancia.

  2. Remplácelo con un kernel en funcionamiento.

  3. Instale un kernel alternativo.

  4. Modifique la AMI corrigiendo el kernel.

Con respaldo en el almacén de instancias

Use el procedimiento siguiente:

  1. Termine la instancia y lance una nueva con el kernel correcto.

  2. Cree una AMI con el kernel correcto.

  3. (Opcional) Busque asistencia técnica para la recuperación de datos a través de AWS Support.

request_module: runaway loop modprobe (Looping legacy kernel modprobe on older Linux versions)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente. El uso de un kernel de Linux antiguo o inestable (por ejemplo, 2.6.16-xenU) puede provocar un problema de bucle infinito en el inicio.

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

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use un kernel más reciente, bien basado en GRUB o estático, con una de las opciones siguientes:

Opción 1: Termine la instancia y lance una nueva especificando los parámetros –kernel y –ramdisk.

Opción 2:

  1. Detenga la instancia.

  2. Modifique el kernel y los atributos ramdisk para usar el kernel nuevo.

  3. Inicie la instancia.

Con respaldo en el almacén de instancias

Termine la instancia y lance una nueva especificando los parámetros –kernel y –ramdisk.

fsck: No such file or directory while trying to open... (File system not found)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

  • Hay un error en las definiciones del sistema de archivos de ramdisk /etc/fstab

  • Definiciones del sistema de archivos mal configuradas en /etc/fstab

  • Falta la unidad o da error

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Pare la instancia, separe el volumen raíz, repare o modifique el volumen, adjunte el volumen a la instancia e inicie la instancia.

  2. Corrija ramdisk para incluir /etc/fstab modificado (si procede).

  3. Modifique la AMI para usar un ramdisk más reciente.

El sexto campo de fstab define los requisitos de disponibilidad del montaje: un valor distinto de cero implica que se hará un fsck en dicho volumen y debe ser correcto. El uso de este campo puede ser problemático en Amazon EC2 porque un error genera, por lo general, una pregunta interactiva de la consola que no está disponible actualmente en Amazon EC2. Tenga precaución con esta característica y lea la página de Linux man sobre fstab.

Con respaldo en el almacén de instancias

Use el procedimiento siguiente:

  1. Termine la instancia y lance una nueva.

  2. Separe los volúmenes errantes de Amazon EBS y reinicie la instancia.

  3. (Opcional) Busque asistencia técnica para la recuperación de datos a través de AWS Support.

General error mounting filesystems (Failed mount)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

Tipo de instancia Causa posible

Respaldada por Amazon EBS

  • Volumen de Amazon EBS separado o con errores.

  • Sistema de archivos dañado.

  • Combinación de ramdisk y AMI errónea (por ejemplo, ramdisk Debian con AMI SUSE).

Con respaldo en el almacén de instancias

  • Una unidad fallida.

  • Un sistema de archivos dañado.

  • Una combinación de ramdisk y AMI errónea (por ejemplo, ramdisk Debian con SUSE AMI).

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Detenga la instancia.

  2. Separe el volumen raíz.

  3. Adjunte el volumen raíz a una instancia conocida activa.

  4. Ejecute una comprobación del sistema de archivos (fsck –a /dev/...).

  5. Corrija los posibles errores.

  6. Separe el volumen de la instancia conocida activa.

  7. Adjunte el volumen a la instancia detenida.

  8. Inicie la instancia.

  9. Vuelva a comprobar el estado de la instancia.

Con respaldo en el almacén de instancias

Pruebe con una de las siguientes acciones:

  • Inicie una nueva instancia.

  • (Opcional) Busque asistencia técnica para la recuperación de datos a través de AWS Support.

VFS: Unable to mount root fs on unknown-block (Root filesystem mismatch)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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)

Causas posibles

Tipo de instancia Causa posible

Respaldada por Amazon EBS

  • El dispositivo no se ha adjuntado correctamente.

  • El dispositivo raíz no se ha adjuntado en el punto correcto.

  • El sistema de archivos no está en el formato esperado.

  • Se usa un kernel heredado (por ejemplo, 2.6.16-XenU).

  • Una reciente actualización del kernel en la instancia (actualización con errores o un error de actualización)

Con respaldo en el almacén de instancias

Error del dispositivo de hardware.

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Aplique alguna de las siguientes acciones:

  • Detenga y vuelva a iniciar la instancia.

  • Modifique el volumen raíz para adjuntarlo en el punto correcto de dispositivo, /dev/sda1 en lugar de /dev/sda.

  • Pare y modifique para usar el kernel moderno.

  • Consulte la documentación de la distribución de Linux para saber cuáles son los errores de actualización conocidos. Cambie o vuelva a instalar el kernel.

Con respaldo en el almacén de instancias

Termine la instancia y lance una nueva usando con un kernel actual.

Error: Unable to determine major/minor number of root device... (Root file system/device mismatch)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

  • Falta la unidad de dispositivo de bloques virtual o está incorrectamente configurada

  • Discrepancia en la enumeración del dispositivo (sda versus xvda o sda en lugar de sda1)

  • Elección incorrecta del kernel de la instancia

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Detenga la instancia.

  2. Retire el volumen.

  3. Corrija el problema de mapeo del dispositivo.

  4. Inicie la instancia.

  5. Modifique la AMI para abordar los problemas de mapeo del dispositivo.

Con respaldo en el almacén de instancias

Use el procedimiento siguiente:

  1. Cree una nueva AMI con la corrección (asigne el dispositivo de bloques correctamente).

  2. Termine la instancia y lance una nueva desde la AMI que ha creado.

XENBUS: Device with no driver...

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

XENBUS: Device with no driver: device/vbd/2048 drivers/rtc/hctosys.c: unable to open rtc device (rtc0) Initalizing 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 /]#

Causas posibles

  • Falta la unidad de dispositivo de bloques virtual o está incorrectamente configurada

  • Discrepancia en la enumeración del dispositivo (sda frente a xvda)

  • Elección incorrecta del kernel de la instancia

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Detenga la instancia.

  2. Retire el volumen.

  3. Corrija el problema de mapeo del dispositivo.

  4. Inicie la instancia.

  5. Modifique la AMI para abordar los problemas de mapeo del dispositivo.

Con respaldo en el almacén de instancias

Use el procedimiento siguiente:

  1. Cree una AMI con la corrección adecuada (asigne el dispositivo de bloques correctamente).

  2. Termine la instancia y lance una nueva con la AMI que ha creado.

... days without being checked, check forced (File system check required)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

Terminado el tiempo de comprobación del sistema de archivos; se fuerza una comprobación del sistema de archivos.

Acciones sugeridas

  • Espere hasta que finalice la comprobación del sistema de archivos. La comprobación puede llevar mucho tiempo en función del tamaño del sistema de archivos raíz.

  • Modifique los sistemas de archivos para quitar el cumplimiento de la comprobación del sistema de archivos (fsck) usando tune2fs o las herramientas adecuadas para el sistema de archivos.

fsck died with exit status... (Missing device)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

  • Ramdisk busca la unidad que falta

  • Forzada la comprobación de la coherencia del sistema de archivos

  • Error en la unidad o unidad separada

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Pruebe una o varias de las siguientes opciones para corregir el problema:

  • Detenga la instancia y adjunte el volumen a una instancia existente en ejecución.

  • Haga comprobaciones de consistencia manualmente.

  • Corrija ramdisk para incluir las utilidades relevantes.

  • Modifique los parámetros de ajuste del sistema de archivos para eliminar los requisitos de consistencia (no se recomienda).

Con respaldo en el almacén de instancias

Pruebe una o varias de las siguientes opciones para corregir el problema:

  • Vuelva a empaquetar ramdisk con las herramientas correctas.

  • Modifique los parámetros de ajuste del sistema de archivos para eliminar los requisitos de consistencia (no se recomienda).

  • Termine la instancia y lance una nueva.

  • (Opcional) Busque asistencia técnica para la recuperación de datos a través de AWS Support.

Símbolo de sistema GRUB (grubdom>)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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>

Causas posibles

Tipo de instancia Causas posibles

Respaldada por Amazon EBS

  • Falta el archivo de configuración de GRUB.

  • Se ha usado la imagen de GRUB incorrecta, se espera el archivo de configuración de GRUB en una ubicación diferente.

  • Se ha utilizado un sistema de archivos no compatible para almacenar el archivo de configuración de GRUB (por ejemplo, convertir el sistema de archivos raíz en un tipo que no es compatible con una versión anterior de GRUB).

Con respaldo en el almacén de instancias

  • Falta el archivo de configuración de GRUB.

  • Se ha usado la imagen de GRUB incorrecta, se espera el archivo de configuración de GRUB en una ubicación diferente.

  • Se ha utilizado un sistema de archivos no compatible para almacenar el archivo de configuración de GRUB (por ejemplo, convertir el sistema de archivos raíz en un tipo que no es compatible con una versión anterior de GRUB).

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Opción 1: Modifique la AMI y vuelva a lanzar la instancia:

  1. Modifique la AMI de origen para crear un archivo de configuración de GRUB en la ubicación estándar (/boot/grub/menu.lst).

  2. Verifique que la versión de GRUB admite el tipo de sistema de archivos subyacente y actualice GRUB si es necesario.

  3. Elija la imagen de GRUB adecuada, (unidad hd0-1st o unidad hd00 – 1st, 1ª partición).

  4. Termine la instancia y lance una nueva con la AMI que ha creado.

Opción 2: Corrija la instancia existente:

  1. Detenga la instancia.

  2. Separe el sistema de archivos raíz.

  3. Adjunte el sistema de archivos raíz a una instancia conocida activa.

  4. Monte el sistema de archivos.

  5. Cree un archivo de configuración de GRUB.

  6. Verifique que la versión de GRUB admite el tipo de sistema de archivos subyacente y actualice GRUB si es necesario.

  7. Separe el sistema de archivos.

  8. Adjúntelo a la instancia original.

  9. Modifique el atributo de kernel para usar la imagen de GRUB adecuada (1er disco o 1ª partición del 1er disco).

  10. Inicie la instancia.

Con respaldo en el almacén de instancias

Opción 1: Modifique la AMI y vuelva a lanzar la instancia:

  1. Cree la nueva AMI con un archivo de configuración de GRUB en la ubicación estándar (/boot/grub/menu.lst).

  2. Elija la imagen de GRUB adecuada, (unidad hd0-1st o unidad hd00 – 1st, 1ª partición).

  3. Verifique que la versión de GRUB admite el tipo de sistema de archivos subyacente y actualice GRUB si es necesario.

  4. Termine la instancia y lance una nueva con la AMI que ha creado.

Opción 2: Termine la instancia y lance una nueva especificando el kernel correcto.

nota

Para recuperar los datos de la instancia existente, póngase en contacto con AWS Support.

Bringing up interface eth0: Device eth0 has different MAC address than expected, ignoring. (dirección MAC no modificable)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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

Causas posibles

Hay una MAC de interfaz codificada de forma rígida en la configuración de la AMI.

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Aplique alguna de las siguientes acciones:

  • Modifique la AMI para quitar la codificación rígida y vuelva a lanzar la instancia.

  • Modifique la instancia para quitar la dirección MAC codificada de forma rígida.

O BIEN

Use el procedimiento siguiente:

  1. Detenga la instancia.

  2. Separe el volumen raíz.

  3. Adjunte el volumen a otra instancia y modifique el volumen para quitar la dirección MAC codificada de forma rígida.

  4. Adjunte el volumen a la instancia original.

  5. Inicie la instancia.

Con respaldo en el almacén de instancias

Aplique alguna de las siguientes acciones:

  • Modifique la instancia para quitar la dirección MAC codificada de forma rígida.

  • Termine la instancia y lance una nueva.

Unable to load SELinux Policy. Machine is in enforcing mode. Halting now. (SELinux misconfiguration)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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!

Causas posibles

SELinux se ha habilitado con error:

  • El kernel proporcionado no es compatible con GRUB

  • No existe kernel alternativo

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Use el procedimiento siguiente:

  1. Detenga la instancia fallida.

  2. Separe el volumen raíz de la instancia fallida.

  3. Adjunte el volumen raíz a otra instancia en ejecución de Linux (referida posteriormente como una instancia de recuperación).

  4. Conéctese a la instancia de recuperación y monte el volumen raíz en la instancia fallida.

  5. Deshabilite SELinux en el volumen raíz montado. Este proceso varía entre las distribuciones de Linux; para obtener más información, consulte la documentación específica del sistema operativo.

    nota

    En algunos sistemas, SELinux se deshabilita estableciendo SELINUX=disabled en el archivo /mount_point/etc/sysconfig/selinux, donde mount_point es la ubicación de la instancia de recuperación en la que montó el volumen.

  6. Desmonte y separe el volumen raíz de la instancia de recuperación y vuelva a adjuntarlo a la instancia original.

  7. Inicie la instancia.

Con respaldo en el almacén de instancias

Use el procedimiento siguiente:

  1. Termine la instancia y lance una nueva.

  2. (Opcional) Busque asistencia técnica para la recuperación de datos a través de AWS Support.

XENBUS: Timeout connecting to devices (Xenbus timeout)

Este problema viene indicado por una entrada de registro del sistema similar a la siguiente.

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.

Causas posibles

  • El dispositivo de bloques no está conectado a la instancia

  • Esta instancia usa un kernel de instancias antiguo

Acciones sugeridas

Para cada tipo de instancia Haga lo siguiente

Respaldada por Amazon EBS

Aplique alguna de las siguientes acciones:

  • Modifique la AMI y la instancia para usar un kernel moderno y volver a lanzar la instancia.

  • Reinicie la instancia.

Con respaldo en el almacén de instancias

Aplique alguna de las siguientes acciones:

  • Termine la instancia.

  • Modifique la AMI para usar un kernel moderno y lance una nueva instancia usando con esta AMI.

En esta página: