Very Computer

Friends,

I installed LM6.1 on a friend's machine the other day and
amazed myself at how good I'm getting at installing and
configuring. I was just in the process of drawing to my
friend's attention just how great I am when something odd
occurred the likes of which I've not seen before! (Darn, I
hate it when that happens...)

When booting into Linux, I got the error message that
"running fsck on a mounted filesystem can cause SEVERE
damage" and did I want to continue with that? Well, I typed
no and it booted okay but it tries to fsck the mounted root
partition each time it boots up.

Obviously, I figured it must be a switch in some config file
that I tweaked inadvertently that's causing it to do that.
So, I checked /etc/fstab and the ext2 partitions are listed
with 1 2 in the fifth and sixth slot with the exception of
the root partition which is 1 1. According to fstab this is
correct. One of the O'Reilly books said that
/etc/rc.d/rc.sysinit calls the fsck process and I sort of
scoured through that file but I can't quite piece together
what might be wrong.

Has anyone had this experience before? Which file(s) do you
suggest I check to stop this strange behaviour from making
me look like a fool in front of my friend? ;-)

Dave Fluri
North Bay, Ontario  Canada

On Tue, 20 Jun 2000 12:31:50 -0400, D F

Quote:>When booting into Linux, I got the error message that
>"running fsck on a mounted filesystem can cause SEVERE
>damage" and did I want to continue with that? Well, I typed
>no and it booted okay but it tries to fsck the mounted root
>partition each time it boots up.

Big question:  Does the machine shut down correctly?  If so, no serious
problem... but there's no reason why fsck should be run on every single
boot!  I think the problem can be solved by adding the following line to
/etc/lilo.conf before any image= lines and then rerunning lilo.
read-only

This will mount the root filesystem read-only first, allowing fsck to run
and fix whatever problem it thinks exists.  (You can fsck a read-only
filesystem with much less risk of severe damage.)

--
Matt G / Dances With Crows      /\    "Man could not stare too long at the face
\----[this space for rent]-----/  \   of the Computer or her children and still
 \There is no Darkness in Eternity \  remain as Man." --David Zindell "So did
But only Light too dim for us to see\ they become Gods, or Usenetters?" --/me

allowing fsck to run

Quote:>and fix whatever problem it thinks exists.  (You can fsck a
read-only
>filesystem with much less risk of severe damage.)

Thanks for your helpful reply.

Yes, the machine shuts down correctly and all seems to be
functioning normally. Come to think of it, I think that
error msg comes up while the root partition IS ro. I think
it's after I say 'no' that it says the thing about
'remounting root rw.'

I'll go over to her place tonight to check it out. If it's
while the root partition is mounted ro, then, you'd suggest
that it's safe to fsck it?

Dave Fluri
North Bay, Ontario  Canada

On Tue, 20 Jun 2000 15:05:12 -0400, D F

Quote:>Yes, the machine shuts down correctly and all seems to be
>functioning normally. Come to think of it, I think that
>error msg comes up while the root partition IS ro. I think
>it's after I say 'no' that it says the thing about
>'remounting root rw.'
>I'll go over to her place tonight to check it out. If it's
>while the root partition is mounted ro, then, you'd suggest
>that it's safe to fsck it?

More than likely.  From your description, it seems as though the root
filesystem wasn't properly umounted somewhere along the line, resulting in
the superblock being marked "dirty" even though no filesystem damage
occurred.  (If any had, you would probably have seen very bad things
happening.)  Let fsck do its thing and flag the filesystem as clean; the
message shouldn't pop up and bother you again unless the power fails or
the disk gets hit with a hammer....

--
Matt G / Dances With Crows      /\    "Man could not stare too long at the face
\----[this space for rent]-----/  \   of the Computer or her children and still
 \There is no Darkness in Eternity \  remain as Man." --David Zindell "So did
But only Light too dim for us to see\ they become Gods, or Usenetters?" --/me

Firstly, let me thank Matt (Dances with Crows) for his
thoughtful and helpful contributions in this matter.

Okay, I tried letting it fsck the root in ro and it didn't
make a whit of difference. So I scoured the file I'd
suspected earlier

     /etc/rc.d/rc.sysinit

more closely. In particular, I compared the invocations of
fsck in the general boot section versus the fast boot
section. In the end, after reading the man pages to decipher
the various switches, I changed

     fsck -T -a $fsckoptions / -- -C 0

to

     fsck -T -a $fsckoptions -- -C 0

and this solved my troubles nicely. Apparently, somehow that
explicit reference to the root got included in that command
string, forcing a check of it on each and every boot. It's
really unnecessary, since the -a flag makes fsck roll
through the fstab entries when not cleanly umounted or when
their time is up, anyway...

Dave Fluri
North Bay, Ontario  Canada

On Tue, 20 Jun 2000 21:31:07 -0400,

Quote:>Firstly, let me thank Matt (Dances with Crows) for his
>thoughtful and helpful contributions in this matter.

>Okay, I tried letting it fsck the root in ro and it didn't
>make a whit of difference. So I scoured the file I'd
>suspected earlier

>     /etc/rc.d/rc.sysinit

>more closely. In particular, I compared the invocations of
>fsck in the general boot section versus the fast boot
>section. In the end, after reading the man pages to decipher
>the various switches, I changed

>     fsck -T -a $fsckoptions / -- -C 0

>to

>     fsck -T -a $fsckoptions -- -C 0

>and this solved my troubles nicely. Apparently, somehow that
>explicit reference to the root got included in that command
>string, forcing a check of it on each and every boot. It's
>really unnecessary, since the -a flag makes fsck roll
>through the fstab entries when not cleanly umounted or when
>their time is up, anyway...

There are supposed to be two fsck commands in rc.sysinit.  One for the
root quite early before doing most anything else including re-mounting
the root rw.  Much later the other file systems are checked before
mounting the /usr and the other file systems.  Skipping fsck when
required is also dangerous, as continued usage of a damaged file system
will case even more damage, which can't be repaired, whereas if you fsck
early enough the damage can be easily repaired in most cases.  If you
combine everything into one big root file system it is even more important
to do fsck when the system thinks it is required.  A pure root filesystem
without /usr, /var, /home, /root, or any other data file system does not
get updated very often, and runs a much lower risk of being damaged by a
power failure or a kernel crash.

Villy

VIlly

Villy

Quote:

>>Firstly, let me thank Matt (Dances with Crows) for his
>>thoughtful and helpful contributions in this matter.

>>Okay, I tried letting it fsck the root in ro and it didn't
>>make a whit of difference. So I scoured the file I'd
>>suspected earlier

>>     /etc/rc.d/rc.sysinit

>>more closely. In particular, I compared the invocations of
>>fsck in the general boot section versus the fast boot
>>section. In the end, after reading the man pages to
decipher
>>the various switches, I changed

>>     fsck -T -a $fsckoptions / -- -C 0

>>to

>>     fsck -T -a $fsckoptions -- -C 0

>>and this solved my troubles nicely. Apparently, somehow
that
>>explicit reference to the root got included in that
command
>>string, forcing a check of it on each and every boot. It's
>>really unnecessary, since the -a flag makes fsck roll
>>through the fstab entries when not cleanly umounted or
when
>>their time is up, anyway...

>There are supposed to be two fsck commands in rc.sysinit.
One for the
>root quite early before doing most anything else including
re-mounting
>the root rw.  Much later the other file systems are checked
before
>mounting the /usr and the other file systems.  Skipping
fsck when
>required is also dangerous, as continued usage of a damaged
file system
>will case even more damage, which can't be repaired,
whereas if you fsck
>early enough the damage can be easily repaired in most
cases.  If you
>combine everything into one big root file system it is even
more important
>to do fsck when the system thinks it is required.  A pure
root filesystem
>without /usr, /var, /home, /root, or any other data file
system does not
>get updated very often, and runs a much lower risk of being
damaged by a
>power failure or a kernel crash.

>Villy

Thanks very much for your reply, Villy.

Yes, I saw the two places where fsck is invoked, and that's
what I was referring to when I said I compared the two
invocations. By removing the explicit reference to the root
filesystem in the first command I am not preventing the root
fs from being checked, I'm simply preventing it from being
checked on each and every boot. At least that's how I
understand it. If this is in error, perhaps you can correct
me. One thing is for sure, the behaviour before making that
change was not normal whereas the system is behaving quite
normally after I made that change. Perhaps someone could
look at his /etc/rc.d/rc.sysinit and post for me the command
string that's used in the very first invocation of fsck.

Dave Fluri
North Bay, Ontario  Canada