28

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:

badblocks /dev/sda1

Edit /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:

  1. If this is a virtual drive shouldn't it be less prone to errors?
  2. Was the image created with one of the flags set? If not what is triggering it?
  3. Why is fs_passno set to 0 on Amazon EC2 Ubuntu images? This is not the first one that is like this.
3
  • 1
    Not that it matters for this question, but ami-a29943cb (20120424) is not the latest 12.04 EBS boot 64-bit AMI from Canonical in us-east-1. As of this posting it is ami-9c78c0f5 (20121026). Nov 8, 2012 at 4:20
  • Why is that not showing up here? - cloud.ubuntu.com/ami
    – cwd
    Nov 8, 2012 at 17:47
  • Apparently the ubuntu.com AMI id problem is a known issue. Not sure when it will be fixed. In the mean time, I use the Ubuntu AMI id API to publish the latest AMI ids on my tech blog. Simply select the EC2 region in the pulldown at the top right of Alestic.com Nov 8, 2012 at 22:50

2 Answers 2

18

From Eric's linked Q&A, the short version is:

It is a bug on Ubuntu 11.04 and 12.04 ... which causes a file to be created with a future time stamp that contains that message.

The simplest solution to fix this bug is to delete the notification file:

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

Other ways to deal with it can be found in that Q&A.

1
  • Didn't fix anything for me on 14.04
    – Ron Smith
    Sep 7, 2015 at 20:35
10

Why is fs_passno set to 0 on Amazon EC2 Ubuntu images?

If fsck were run on boot and found problems, then it might be sitting waiting for the answer to a prompt. However, since Amazon EC2 does not provide access to the console on an instance, there is no way that you could answer the prompt and the instance would become unusable.


Linked Q&A:

4
  • Although AWS does in fact provide access to view the console output - img19.imageshack.us/img19/233/screenshot20121108at124o.png . Any thoughts on questions 1 and 2 ?
    – cwd
    Nov 8, 2012 at 17:45
  • @cwd: EC2 only provides a snapshot of the console output at a fixed point in time (about a few minutes after a start/reboot/terminate). This console output is not updated. And, there is no way to interact with the console which is what you need to answer an fsck prompt. Nov 8, 2012 at 22:06
  • @cwd: The failure rate of EBS volumes depends on how many blocks have been modified since the last snapshot. However, fsck is fixing the file system which may get corrupted even if the underlying block device is fine. Nov 8, 2012 at 22:09
  • @cwd: I don't know why you're getting notified that the disk will checked for errors at next reboot when fs_passno is 0. Nov 8, 2012 at 22:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .