Ubuntu 12.04 en Amazon EC2: / dev / xvda1 ¿se verificará si hay errores en el próximo reinicio?

Estoy ejecutando el último Ubuntu 12.04 AMI ( ami-a29943cb) de Canonical en Amazon EC2 y con bastante frecuencia cuando inicio sesión recibo el mensaje:

*** /dev/xvda1 will be checked for errors at next reboot ***

He leído un montón de documentación sobre esto y parece que entiendo que cada tantos reinicios (alrededor de 37 ver Mount count/ más Maximum mount countabajo) Ubuntu quiere verificar si hay errores en un disco. Puedo ver eso usando dumpe2fs -h /dev/xvda1( referencia ) para obtener información como:

Last mounted on:          /
Filesystem UUID:          1ad27d06-4ecf-493d-bb19-4710c3caf924
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              524288
Block count:              2097152
Reserved block count:     104857
Free blocks:              1778055
Free inodes:              482659
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      511
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Tue Apr 24 03:07:48 2012
Last mount time:          Thu Nov  8 03:17:58 2012
Last write time:          Tue Apr 24 03:08:52 2012
Mount count:              3
Maximum mount count:      37
Last checked:             Tue Apr 24 03:07:48 2012
Check interval:           15552000 (6 months)
Next check after:         Sun Oct 21 03:07:48 2012
Lifetime writes:          2454 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      0a25e04c-6169-4d68-bfa6-a1acd8e39632
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke
Journal size:             128M
Journal length:           32768
Journal sequence:         0x0000158b
Journal start:            1

He intentado estas cosas para deshacerme del mensaje y, por lo general, esto badblockses lo que me sirve:

Ejecute este comando y reinicie:

sudo touch /forcefsck

Ejecute badblocks para verificar el disco:

badblocks /dev/sda1

Edite /etc/fstaby cambie el último "0", que es la fs_passnocolumna correspondiente, y luego reinicie:

El sistema de archivos raíz debe especificarse con un fs_passno de 1, y otros sistemas de archivos deben tener un fs_passno de 2.

No entiendo:

Si se trata de un disco virtual, ¿no debería ser menos propenso a errores?
¿Se creó la imagen con una de las banderas establecidas? Si no, ¿qué lo está desencadenando?
¿Por qué está fs_passnoconfigurado 0en imágenes Amazon Ubuntu EC2? Este no es el primero que es así.

amazon-ec2

— cwd
fuente

No es que sea importante para esta pregunta, pero ami-a29943cb (20120424) no es la última AMI de arranque EBS de 12.04 de 64 bits de Canonical en us-east-1. A partir de esta publicación, es ami-9c78c0f5 (20121026).

— Eric Hammond el

¿Por qué eso no aparece aquí? - cloud.ubuntu.com/ami

— Cwd

Aparentemente, el problema de id AMI de ubuntu.com es un problema conocido. No estoy seguro de cuándo se solucionará. Mientras tanto, uso la API de identificación AMI de Ubuntu para publicar los últimos ID de AMI en mi blog de tecnología. Simplemente seleccione la región EC2 en el menú

— Eric Hammond

Respuestas:

¿Por qué fs_passno se establece en 0 en las imágenes de Amazon EC2 Ubuntu?

Si fsck se ejecutó en el arranque y encontró problemas, entonces podría estar esperando la respuesta a un mensaje. Sin embargo, dado que Amazon EC2 no proporciona acceso a la consola en una instancia, no hay forma de que pueda responder la solicitud y la instancia quedaría inutilizable.

Preguntas y respuestas vinculadas:

El "disco se comprobará ..." persistente en el mensaje del día (motd) incluso después de reiniciar

— Eric Hammond
fuente

Aunque AWS de hecho proporciona acceso para ver la salida de la consola: img19.imageshack.us/img19/233/screenshot20121108at124o.png . ¿Alguna idea sobre las preguntas 1 y 2?

— cwd

@cwd: EC2 solo proporciona una instantánea de la salida de la consola en un punto fijo en el tiempo (unos minutos después de un inicio / reinicio / finalización). Esta salida de la consola no se actualiza. Y, no hay forma de interactuar con la consola, que es lo que necesita para responder una solicitud de fsck.

— Eric Hammond el

@cwd: La tasa de falla de los volúmenes de EBS depende de cuántos bloques se hayan modificado desde la última instantánea. Sin embargo, fsck está arreglando el sistema de archivos que puede corromperse incluso si el dispositivo de bloque subyacente está bien.

— Eric Hammond el

@cwd: No sé por qué te notifican que el disco verificará si hay errores en el próximo reinicio cuando fs_passno es 0.

— Eric Hammond

De las preguntas y respuestas vinculadas de Eric , la versión corta es:

Es un error en Ubuntu 11.04 y 12.04 ... que hace que se cree un archivo con una marca de tiempo futura que contiene ese mensaje.

La solución más simple para solucionar este error es eliminar el archivo de notificación:

sudo rm /var/lib/update-notifier/fsck-at-reboot

Se pueden encontrar otras formas de tratarlo en esas preguntas y respuestas .

— cwd
fuente

trabajó para mi. usando Ubuntu 14.04. ¡Gracias!

— hyubs

No me arregló nada el 14.04

— Ron Smith