Ubuntu 12.04 auf Amazon EC2: / dev / xvda1 wird beim nächsten Neustart auf Fehler überprüft?

Ich verwende das neueste Ubuntu 12.04 AMI ( ami-a29943cb) von Canonical auf Amazon EC2 und erhalte ziemlich oft die folgende Meldung, wenn ich mich anmelde :

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

Ich habe eine Reihe von Dokumentationen dazu gelesen und scheine zu verstehen, dass Ubuntu nach so vielen Neustarts (etwa 37 siehe Mount count/ Maximum mount countunten) eine Festplatte auf Fehler überprüfen möchte. Ich kann das sehen, indem ich dumpe2fs -h /dev/xvda1( Referenz ) benutze , um Informationen zu erhalten, wie zum Beispiel:

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

Ich habe diese Dinge ausprobiert, um die Nachricht loszuwerden, und normalerweise badblocksist es das, was es für mich tut:

Führen Sie diesen Befehl aus und starten Sie neu:

sudo touch /forcefsck

Führen Sie badblocks aus, um die Festplatte zu überprüfen:

badblocks /dev/sda1

Bearbeiten /etc/fstabund ändern Sie die letzte "0" in der fs_passnoSpalte entsprechend und starten Sie dann neu:

Das Root-Dateisystem sollte mit einem fs_passno von 1 angegeben werden, und andere Dateisysteme sollten einen fs_passno von 2 haben.

Ich verstehe nicht

1. Wenn dies ein virtuelles Laufwerk ist, sollte es nicht weniger fehleranfällig sein?
2. Wurde das Bild mit einem der gesetzten Flags erstellt? Wenn nicht, was löst es aus?
3. Warum wird fs_passnoauf 0auf Amazon EC2 Ubuntu - Bilder? Dies ist nicht der erste, der so ist.

Warum ist fs_passno auf Amazon EC2 Ubuntu-Images auf 0 gesetzt?

Wenn fsck beim Booten ausgeführt wird und Probleme findet, wartet es möglicherweise auf die Antwort auf eine Eingabeaufforderung. Da Amazon EC2 jedoch keinen Zugriff auf die Konsole einer Instanz bietet, können Sie die Eingabeaufforderung nicht beantworten, und die Instanz wird unbrauchbar.

Verknüpfte Fragen und Antworten:

• Persistente "Festplatte wird überprüft ..." in der Nachricht des Tages (motd) auch nach dem Neustart

Die Kurzversion von Eric's Q & A lautet:

Es ist ein Fehler in Ubuntu 11.04 und 12.04, der dazu führt, dass eine Datei mit einem zukünftigen Zeitstempel erstellt wird, der diese Nachricht enthält.

Die einfachste Lösung, um diesen Fehler zu beheben, besteht darin, die Benachrichtigungsdatei zu löschen:

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

Weitere Möglichkeiten, damit umzugehen, finden Sie in dieser Frage und Antwort .