Force fsck.ext4 on reboot, but really "forceful"

Question

One of my Ubuntu 10.04 servers is giving me trouble. When I run fsck.ext4 -n /dev/sda5 it tells me there are errors in the free inode count, free block count, and more.

I have tried:

touch /forcefsck

Also tried:

shutdown -rF now

and still, after reboot, I see errors.

I also just checked on my eeePC netbook, Ubuntu 10.10, and have the same issue!

How can I force a really "forced" "forceful" "seriously fix my filesystem" fsck of the "/" filesystem on reboot?

Clarification: I run fsck.ext4 -n because it's a mounted filesystem, to check if there are errors. This tells me that there are. I thought that the automatic fsck every 30 mounts during the boot-up process is precisely to take care of errors in the root filesystem. But it doesn't do it in my case. I could reboot with a LiveCD and fix the errors, and then reboot again, but that's some serious downtime for a live server. A reboot, auto fsck, then continue booting is much more sustainable on a live server, and I believe should be the right behaviour.

Additional info: Here is the output. It looks like something that the autofsck would fix, doesn't it?

root@server:~# fsck.ext4 -n /dev/sda5
e2fsck 1.41.11 (14-Mar-2010)
Warning!  /dev/sda5 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/sda5 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1849368, counted=1948909).
Fix? no

Free inodes count wrong (545504, counted=552134).
Fix? no


/dev/sda5: ********** WARNING: Filesystem still has errors **********

/dev/sda5: 116752/662256 files (0.2% non-contiguous), 795324/2644692 blocks

Solution 1

From the e2fsck man page :

"Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted. If e2fsck asks whether or not you should check a filesystem which is mounted, the only correct answer is ''no''. Only experts who really know what they are doing should consider answering this question in any other way."

So if you check a mounted FS with fsck even using the -n option the result may be not valid at all. Don't check mounted filesystems. Use a Live-CD/Live-USB.

If you don't check the filesystem while it is mounted, I don't understand why you need to use touch /forcefsck you can just unmount it and fix it. But if it is the case and after a fix your FS still have errors then you can consider using :

e2fsck -cy /dev/sda5

That will fix an hard drive related issue called bad blocks you may have (this will take a long time).

If you want to check a mounted filesystem, I don't know how to proceed but I think you should create another question.

Solution 2

I know this is a really old thread, but I recently had to solve this problem so I wanted to post how to force the OS to fix problems found with fsck during bootup (for 12.04).

You do need to run the command sudo touch /forcefsck. This will cause it to perform an fsck on the next boot. You can see the results of the fsck in /var/log/boot.log.

However, you are not guaranteed that fsck will fix anything it finds. To do this, you would need to edit the file /etc/default/rcS. There is a line at the end of that file:

FSCKFIX=no

This needs to be changed to the following:

FSCKFIX=yes

This will have the same effect as running the fsck with the -y option which will force all fixes that are possible to be implemented and it will not ask for user interaction.

This will allow you to run the fsck like the OP was asking to without having to resort to booting from a live disk which isn't always possible especially if you are on a remote system.

Solution 3

sudo touch /forcefsck
sudo reboot

You've got a typo- you're touching /forcefcsk. The "c" and the "s" are swapped. fsck is short for FileSystemChecK.

Solution 4

You can not force a fsck on / that will repair because the partition is in use. Try running the check from a different partition or live cd.

Solution 5

You can have the revisions done automatically in the following way:

Tune2fs -c 5 -i 10 / dev / sda1

-c is the maximum number of mounts before running fsck and -i is the maximum number of days before running fsck.

In this case will be done every 5 mounts or every 10 days, whichever comes first.

I have two computers, one with Linux SuSE 13.2 and the other with Linux Mint 18.0 and in both it works perfectly.

View more solutions

Comments

[Nicholas Jordan]

10.04. I'll edit my question.

[Jason Southwell]

I don't think you can actually do that, in fact you might be better off doing the check manually.

[crncosta]

Sorry but I still need more info. Are you doing fsck on mounted filesystems? can you boot from a LiveCD and check again (with your /dev/sda5 unmounted)?

[flo]

Isn't it possible that not the file system but the hard drive is broken? In which case it would be expected that ext4 isn't fixing errors as well as it would were there just a few bad sectors.

[Nicholas Jordan]

Yes, I am running "fsck -n" on the mounted root filesystem, so that it doesn't change anything. And this tells me there are errors. Rebooting with a LiveCD would be an option, and it would solve the issue, but that's not sustainable. Shouldn't the fsck on reboot take care of them? Is a LiveCD really the only way to fix filesystem errors on a root filesystem???

[Jason Southwell]

no you can do it in recovery mode, and if the drive does not have major problems a reboot check normally fixes those. The fact that it's not fixing errors when it reboots means most likely you have some kind of damage or something is really mixed up that requires a manual check.

[Nicholas Jordan]

I'll add the output of fsck -n, because it doesn't look like major errors to me. And going to the server room way after hours to do the LiveCD scan is... quite inconvenient.

[Nicholas Jordan]

You are correct, the filesystem is mounted. And of course I need to do fsck when unmounted. But I run fsck -n to check while mounted, without making changes, and it tells me there are errors. And shouldn't the fsck on reboot fix them???

[Nicholas Jordan]

Very true, but the automatic fsck on boot should happen before the partition is in use, precisely to be able to fix errors on "/". Otherwise, what's the point?

[Nicholas Jordan]

I just noticed what you say in the first sentence: why would fsck -n not be valid on a mounted filesystem? How can I check if a mounted filesystem has errors in a reliable way?

[developer]

You can check the e2fsck man page that say: "Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted. If e2fsck asks whether or not you should check a filesystem which is mounted, the only correct answer is ''no''. Only experts who really know what they are doing should consider answering this question in any other way."

[Nicholas Jordan]

Can you add those two last comments to your answer? Then I'll accept it. I didn't know that, so that's why... I think it's because fsck -n doesn't process the journal, so the filesystem state is inconsistent without looking at the latest changes kept there.

[charlie-tca]

I believe the check happens before use, however, it is more of an advisory check. It is up to you to decide how to fix the errors. An easy check is when looking at /etc/fstab. The "/" gets a different check then the other partitions.

[HDave]

This wouldn't work for me because the root filesystem is mounted read-only due to errors I to fix with fsck! Chicken and the egg problem that can only be solved via liveCD or pulling the drive into another machine.

[c.gutierrez]

Editing this entry on my Ubuntu EC2 instance along with the sudo touch /forcefsck and sudo shutdown -r commands successfully resolved the file system issues and the check warning upon login. Easy and non-disruptive - cheers.

[ichbinblau]

The same question was asked on Server Fault, and this answer was also the one that worked for me, on an Ubuntu 14.04 system. Just doing the sudo touch /forcefsck and then rebooting did not; editing rcS was necessary.

[Serrano Pereira]

Why is this the accepted answer? It doesn't answer the question at all. The answer by Brian does answer the question.

[developer]

No, my answer clearly state that the error he is seeing are linked to the fact that he is trying to check a mounted filesystem which he shouldn't do. Also Brian is 4 years late.

[hk3jld]

What are the forms and comments in the automatic form as follows: Tune2fs -c 5 -i 10 / dev / sda1 Where: -c is the maximum number of mounts before running fsck Where: -i is the maximum number of days before running fsck In this case will be done every 5 mounts or every 10 days, whichever comes first. I have two computers, one with Linux SuSE 13.2 and the other with Linux MInt 18.0 and both works perfectly.

[hk3jld]

What are the forms and comments in the automatic form as follows: Tune2fs -c 5 -i 10 / dev / sda1 Where: -c is the maximum number of mounts before running fsck Where: -i is the maximum number of days before running fsck In this case will be done every 5 mounts or every 10 days, whichever comes first. I have two computers, one with Linux SuSE 13.2 and the other with Linux MInt 18.0 and both works perfectly. I do not know English but I use a translator, I hope the training is fine

[George Udosen]

Does it work on Ubuntu too ?

[mckenzm]

It does happen before root is pivoted ? ie. INITial Ram Disk.