Red Hat Bugzilla – Bug 19673
Always does fsck on power on.
Last modified: 2014-03-16 22:16:58 EDT
This problem occurs on a system that was upgraded from RH6.1 to RH7.0,
followed by the installation of mount-2.10m-6.i386.rpm:
On every boot after power on, the initscripts report that / was not
and then performs a fsck on /
I can't reproduce this.
Do you shutdown the machine properly (using the shutdown -h, shutdown -r, reboot, halt or poweroff commands)?
This is supposed to happen if you just turn off the machine or something like that.
If you're shutting down the system properly, do you see any error messages at shutdown time (e.g. "cannot umount /: filesystem busy")?
This is happening on a machine that is being shutdown by selecting shutdown from
gdm menu after logging out.
Does it happen when you shutdown from the console using one of the commands I've mentioned? If so, do you see any errors while shutting down?
The problem still occurs if I shutdown the machine using 'shutdown -h now' from
At first I had two failure messages appearing (xinetd failed to shutdown, and
something about failing to save the mixer settings) - these related to problems
during the boot sequence which I have now fixed. There are now no error messages
during shutdown that appear on the console window, nor
in any system log. There are no problems reported at system start-up, except for
the unclean umount of / and it doing a fsck.
I tried putting a label on the / partition and changed /etc/fstab to be the same
as that on our other
RH7.0 machines (all installs, not upgrades) but the problem has not gone away.
I added some sleeps into /etc/rc.d/init.d/halt so as to be sure that I saw all
of the messages on the console before the system powered down. But in doing so,
the problem has gone away. I have yet to check if the problem returns if I
remove the sleeps!
Interestingly, I have also found that the problem does not happen on a reboot.
I don't see this problem anywhere - did it reappear for you when you removed the sleeps?
The problem reappears if I remove the sleeps.
The only sleep I need in the system to prevent the problem is a sleep in between
HALTARGS and executing the halt, eg
if [ -f /poweroff -o ! -f /halt ]; then
eval $command $HALTARGS
I don't think this can have anything to do with it - the shell isn't threaded, so it can't execute a command before executing a command that came before it.
If you add a sleep after the line saying
runcmd "Sending all processes the KILL signal..." /sbin/killall5 -9
and remove yours, does that fix the problem?
I put "sleep 10" where you suggested and removed mine. The problem came back.
If I put the "sleep 10" after the line
runcmd "Unmounting proc file system: " umount /proc
then it is okay.
Also, I don't understand your comment about threading. What I had does not
Assigning to initscripts (where a sleep could be added). Still can't reproduce
This is the only report I've seen of this; I've tested this here
and I can't reproduce this.
The machine that this problem occured on was stolen recently. So obviously
I can no longer test any patches, etc. It doesn't occur with any of the
other machines I have.
After installing both Redhat 7.0 and 7.1 I get this same exact problem. The disk is never cleanly umounted during shutdown, although when I restart fsck does not have to fix anything on the disk.
As before, we've never seen this in testing here. Closing as WORKSFORME/US.