I'm running the lastest Ubuntu 12.04 AMI (
ami-a29943cb) from Canonical on Amazon EC2 and quite often when I log in I get the message:
*** /dev/xvda1 will be checked for errors at next reboot ***
I have read a bunch of documentation on this and seem to understand that every so many reboots (around 37 see
Mount count /
Maximum mount count below) Ubuntu wants to check a disk for errors. I can see that by using
dumpe2fs -h /dev/xvda1 (reference) to get information such as:
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
I've tried these things to get rid of the message and usually the
badblocks is what does it for me:
Run this command and reboot:
sudo touch /forcefsck
Run badblocks to check the disk:
/etc/fstab and change the last "0" which is the
fs_passno column accordingly and then reboot:
The root filesystem should be specified with a fs_passno of 1, and other filesystems should have a fs_passno of 2.
I don't understand:
- If this is a virtual drive shouldn't it be less prone to errors?
- Was the image created with one of the flags set? If not what is triggering it?
- Why is
0on Amazon EC2 Ubuntu images? This is not the first one that is like this.