O Ubuntu 12.04 no Amazon EC2: / dev / xvda1 será verificado quanto a erros na próxima reinicialização?

Estou executando o último Ubuntu 12.04 AMI ( ami-a29943cb) da Canonical no Amazon EC2 e, muitas vezes, quando faço login, recebo a mensagem:

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

Eu li um monte de documentação sobre isso e parece entender que a cada reinicialização (cerca de 37 veja Mount count/ Maximum mount countabaixo) o Ubuntu quer verificar se há erros no disco. Eu posso ver isso usando dumpe2fs -h /dev/xvda1( referência ) para obter informações 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

Eu tentei essas coisas para me livrar da mensagem e, geralmente, badblocksé isso que faz para mim:

Execute este comando e reinicie:

sudo touch /forcefsck

Execute badblocks para verificar o disco:

badblocks /dev/sda1

Edite /etc/fstabe altere o último "0", que é a fs_passnocoluna de acordo e, em seguida, reinicie:

O sistema de arquivos raiz deve ser especificado com um fs_passno igual a 1, e outros sistemas de arquivos devem ter um fs_passno igual a 2.

Eu não entendo:

Se esta é uma unidade virtual, não deveria ser menos propensa a erros?
A imagem foi criada com um dos sinalizadores definidos? Se não, o que está provocando isso?
Por que está fs_passnodefinido 0nas imagens do Amazon EC2 Ubuntu? Este não é o primeiro que é assim.

amazon-ec2

— cwd
fonte

Não que isso importe para essa pergunta, mas o ami-a29943cb (20120424) não é a mais recente AMI de 64 bits de inicialização do EBS 12.04 da Canonical em us-east-1. A partir desta publicação, é ami-9c78c0f5 (20121026).

— Eric Hammond

Por que isso não aparece aqui? - cloud.ubuntu.com/ami

— cwd

Aparentemente, o problema de identificação da AMI do ubuntu.com é um problema conhecido. Não tenho certeza de quando será corrigido. Enquanto isso, uso a API de identificação de AMI do Ubuntu para publicar os últimos IDs de AMI no meu blog de tecnologia. Basta selecionar a região do EC2 no menu suspenso no canto superior direito da Alestic.com

— Eric Hammond

Respostas:

Por que fs_passno é definido como 0 nas imagens do Amazon EC2 Ubuntu?

Se o fsck foi executado na inicialização e encontrou problemas, ele pode estar aguardando a resposta para um prompt. No entanto, como o Amazon EC2 não fornece acesso ao console em uma instância, não há como responder ao prompt e a instância se tornaria inutilizável.

Perguntas e Respostas Vinculadas:

"Disco persistente será verificado ..." na mensagem do dia (motd), mesmo após a reinicialização

— Eric Hammond
fonte

Embora a AWS de fato forneça acesso para visualizar a saída do console - img19.imageshack.us/img19/233/screenshot20121108at124o.png . Alguma opinião sobre as perguntas 1 e 2?

— Cwd

@cwd: O EC2 fornece apenas uma captura instantânea da saída do console em um ponto fixo no tempo (cerca de alguns minutos após uma inicialização / reinicialização / término). Esta saída do console não é atualizada. E não há como interagir com o console; é isso que você precisa para responder a um prompt do fsck.

— 11138 Eric Hammond

@cwd: a taxa de falhas dos volumes EBS depende de quantos blocos foram modificados desde o último instantâneo. No entanto, o fsck está corrigindo o sistema de arquivos que pode ser corrompido, mesmo que o dispositivo de bloco subjacente esteja correto.

— 11118 Eric

@cwd: Eu não sei por que você está sendo notificado de que o disco será marcada por erros na próxima reinicialização quando fs_passno é 0.

— Eric Hammond

Nas perguntas e respostas vinculadas por Eric , a versão curta é:

É um bug no Ubuntu 11.04 e 12.04 ... que faz com que um arquivo seja criado com um carimbo de data / hora futuro que contenha essa mensagem.

A solução mais simples para corrigir esse erro é excluir o arquivo de notificação:

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

Outras maneiras de lidar com isso podem ser encontradas nas perguntas e respostas .

— cwd
fonte

trabalhou para mim. usando o Ubuntu 14.04. obrigado!

— hubs

Não resolveu nada para mim em 14.04

— Ron Smith