Bug 19673 - Always does fsck on power on.
Summary: Always does fsck on power on.
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-24 08:29 UTC by Alan McIvor
Modified: 2014-03-17 02:16 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-24 22:29:25 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Alan McIvor 2000-10-24 08:29:31 UTC
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
umounted cleanly
and then performs a fsck on /

Comment 1 Bernhard Rosenkraenzer 2000-10-24 08:34:22 UTC
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")?

Comment 2 Alan McIvor 2000-10-24 08:57:50 UTC
This is happening on a machine that is being shutdown by selecting shutdown from
the
gdm menu after logging out.

Comment 3 Bernhard Rosenkraenzer 2000-10-24 09:03:05 UTC
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?

Comment 4 Alan McIvor 2000-10-25 09:13:37 UTC
The problem still occurs if I shutdown the machine using 'shutdown -h now' from
a console
window.

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.

Comment 5 Alan McIvor 2000-10-26 08:51:12 UTC
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.

Comment 6 Bernhard Rosenkraenzer 2000-11-02 13:19:57 UTC
I don't see this problem anywhere - did it reappear for you when you removed the sleeps?

Comment 7 Alan McIvor 2000-11-05 08:12:40 UTC
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
determining
HALTARGS and executing the halt, eg

HALTARGS="-i -d"
if [ -f /poweroff -o ! -f /halt ]; then
 HALTARGS="$HALTARGS -p"
fi

sleep 10

eval $command $HALTARGS


Comment 8 Bernhard Rosenkraenzer 2000-11-05 09:15:51 UTC
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?

Comment 9 Alan McIvor 2000-11-06 09:08:40 UTC
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
require it.



Comment 10 Bernhard Rosenkraenzer 2001-03-06 15:13:15 UTC
Assigning to initscripts (where a sleep could be added). Still can't reproduce 
this though.


Comment 11 Bill Nottingham 2001-03-06 16:52:58 UTC
This is the only report I've seen of this; I've tested this here
and I can't reproduce this.

Comment 12 Alan McIvor 2001-03-06 19:40:28 UTC
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.

Comment 13 Need Real Name 2001-04-02 15:57:56 UTC
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.

Comment 14 Bill Nottingham 2003-01-24 22:29:25 UTC
As before, we've never seen this in testing here. Closing as WORKSFORME/US.


Note You need to log in before you can comment on or make changes to this bug.