Ubuntu 12.04 sur Amazon EC2: / dev / xvda1 sera-t-il vérifié pour les erreurs au prochain redémarrage?

28

J'utilise la dernière Ubuntu 12.04 AMI ( ami-a29943cb) de Canonical sur Amazon EC2 et assez souvent lorsque je me connecte, je reçois le message:

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

J'ai lu un tas de documentation à ce sujet et semble comprendre que chaque redémarrage (environ 37 voir Mount count/ Maximum mount countci - dessous) Ubuntu veut vérifier un disque pour les erreurs. Je peux le voir en utilisant dumpe2fs -h /dev/xvda1( référence ) pour obtenir des informations telles que:

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

J'ai essayé ces choses pour se débarrasser du message et généralement badblocksc'est ce que ça fait pour moi:

Exécutez cette commande et redémarrez:

sudo touch /forcefsck

Exécutez des badblocks pour vérifier le disque:

badblocks /dev/sda1

Modifiez /etc/fstabet modifiez le dernier "0" qui est la fs_passnocolonne en conséquence, puis redémarrez:

Le système de fichiers racine doit être spécifié avec un fs_passno de 1 et les autres systèmes de fichiers doivent avoir un fs_passno de 2.

Je ne comprends pas:

  1. S'il s'agit d'un lecteur virtuel, ne devrait-il pas être moins sujet aux erreurs?
  2. L'image a-t-elle été créée avec l'un des drapeaux définis? Sinon qu'est-ce qui le déclenche?
  3. Pourquoi est-il fs_passnodéfini 0sur les images Amazon EC2 Ubuntu? Ce n'est pas le premier qui ressemble à ça.
amazon-ec2 cwd
la source
1
Ce n'est pas important pour cette question, mais ami-a29943cb (20120424) n'est pas la dernière AMI 64 bits de démarrage 12.04 EBS de Canonical en us-east-1. À compter de cette publication, il s'agit de l'ami-9c78c0f5 (20121026).
Eric Hammond
Pourquoi cela n'apparaît pas ici? - cloud.ubuntu.com/ami
cwd
Apparemment, le problème d'ID ubuntu.com AMI est un problème connu. Je ne sais pas quand cela sera corrigé. En attendant, j'utilise l'API Ubuntu AMI id pour publier les derniers ID AMI sur mon blog technologique. Sélectionnez simplement la région EC2 dans le menu déroulant en haut à droite d' Alestic.com
Eric Hammond

Réponses:

10

Pourquoi fs_passno est-il défini sur 0 sur les images Amazon EC2 Ubuntu?

Si fsck a été exécuté au démarrage et a détecté des problèmes, il se peut qu'il attende la réponse à une invite. Cependant, comme Amazon EC2 ne fournit pas d'accès à la console sur une instance, il n'y a aucun moyen que vous puissiez répondre à l'invite et l'instance deviendrait inutilisable.

Questions et réponses liées:

Eric Hammond
la source
Bien qu'AWS fournisse en fait un accès pour afficher la sortie de la console - img19.imageshack.us/img19/233/screenshot20121108at124o.png . Avez-vous des réflexions sur les questions 1 et 2?
cwd
@cwd: EC2 ne fournit qu'un instantané de la sortie de la console à un point fixe dans le temps (environ quelques minutes après un démarrage / redémarrage / fin). Cette sortie de console n'est pas mise à jour. Et, il n'y a aucun moyen d'interagir avec la console, ce dont vous avez besoin pour répondre à une invite fsck.
Eric Hammond
@cwd: Le taux d'échec des volumes EBS dépend du nombre de blocs modifiés depuis le dernier instantané. Cependant, fsck corrige le système de fichiers qui peut être corrompu même si le périphérique de bloc sous-jacent fonctionne correctement.
Eric Hammond
@cwd: Je ne sais pas pourquoi vous êtes averti que le disque vérifiera les erreurs lors du prochain redémarrage lorsque fs_passno est 0.
Eric Hammond
18

D'après les questions et réponses d' Eric , la version courte est:

C'est un bogue sur Ubuntu 11.04 et 12.04 ... qui provoque la création d'un fichier avec un horodatage futur contenant ce message.

La solution la plus simple pour corriger ce bogue est de supprimer le fichier de notification:

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

D'autres façons de le gérer peuvent être trouvées dans cette Q&R .

cwd
la source
travaillé pour moi. en utilisant Ubuntu 14.04. Merci!
hyubs
Je n'ai rien arrangé pour moi le 14.04
Ron Smith