View Full Version : anyone else having a problem using forcefsck?
DBelton
22nd March 2012, 09:17 AM
I have on several occasions now needed to force a full filesystem check on boot, so I did as I always have in the past...
touch /forcefsck
then reboot.
In the past, when the system rebooted, it would check the filesystems, then remove the /forcefsck file.
Now I am seeing it leaving the /forcefsck file and it tries to run a filesystem check on every boot until I manually go in and remove the file.
It's doing it on F17, and I tried it on my F16 systems and it does it on them as well now. I know it worked properly on F16 before, but something has changed and now it's not longer removing the file.
Anyone else noticed this problem?
Edit:
Anyone know what application i supposed to remove the file? I suppose if it's a bug, I should file it under e2fsprogs?
greyhound
22nd March 2012, 10:01 AM
Have the same here on F16 since some days. Message while booting is "started Recreate Volatile Files and Direcories", slows down the boot-process everytime. Cannot find any /forcecheck and dont know what to do.
DBelton
22nd March 2012, 04:29 PM
the "Recreate volatile files an directories" is a normal part of the boot process, and happens on all systems using systemd.
the /forcefsck is a file you can create and it tells the system you wish to have it run a full filesystem check on boot, before the filesystems get mounted. That is really about the only way to check your root filesystem without booting a livecd, since you can't unmount hte root filesystem once the system is booted up and running.
su -
(root password)
touch /forcefsck
That creates the /forcefsck file so that the filesystems get checked on the next boot. When working properly, once the filesystems get checked and are clean, then the /forcefsck file is supposed to be deleted so that on the next boot, a filesystem check isn't forced.
On my systems here, the /forcefsck file is created, then on the next boot, the filesystems get checked. However, the /forcefsck file isn't removed once the filesystem check is completed. So, on every boot after that, until the file is manually deleted, a full filesystem check is done.
Thinking more on this, I don't believe the bug is in e2fsprogs. I believe it's more in systemd. It would be the only thing that would know when ALL filesystems are finished being checked so that it could remove the file.
vallimar
23rd March 2012, 03:33 PM
You are correct, this is systemd. In older versions, this was handled by the rc.sysinit SysV script.
You may want to file a report in bugzilla against systemd.
DBelton
23rd March 2012, 04:05 PM
well, I finally did file a bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=806369
greyhound
23rd March 2012, 05:55 PM
So my problem seemed to be another one.
Inspecting the var/log/boot.log i could see that an swap was not recognized correctly. Some days ago i had replaced an installed system. After correcting the UUID in fstab the system starts again as expected.
DBelton
23rd March 2012, 06:02 PM
Glad you figured out your problem :)
The /forcefsck file not being removed is looking like it's a SElinux issue rather than a systemd issue. It appears that SElinux is preventing systemd from removing the file.
vallimar
23rd March 2012, 07:12 PM
Just read through the bug report, good work!
This just further encourages my policy of keeping selinux disabled though.
I seem to never read success stories about how it prevented something bad..
only in how it did something bad to prevent smooth operation. ;)
DBelton
23rd March 2012, 09:37 PM
I really do have to commend Michal Schmidt for his work and very prompt response. Less than 20 minutes after the initial bug report, he had responded and was working on finding a solution. Less that one and a half hours from bug report being filed until the problem was known. Now it's up to the SElinux people to fix it.
Heck, I can't even get one response in nearly a year on some of the Gnome bug reports I've filed! :lol: (Only one I have gotten a response to was only after the intervention of AdamW when mentioned possibly putting it on the blocker list.)
But, I tend to keep SElinux enabled on my systems here unless it does something to really prevent my system from working. I usually don't have problems with it preventing things that should happen, though. When it does, it's a fairly simple matter to allow it if I want it to happen.
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.