Hi,

First a short intrduction: my company makes an embedded Linux device
(www.museresearch.com). It is a PC in a box with an AMD Athlon, a 40 GB
hard drive, and a custom front panel. The customer can use our front
panel or our custom UI, but does not have access to the command line or
any other programs.

Our kernel is based on 2.4.19 and our distribution is based on RedHat.
We have 4 partition, swap is the third one.

We are observing the exact same strange behavior on all our boxes. Once
we are up and running in multi-user mode, we login and run "fsck -f -n"
The root partition (/dev/hda2) always gives errors. The other two
partitions (/dev/hda1 and /dev/hda4) have no errors. Then, we boot in
single user mode umount /dev/hda2 and run "fsck -f" There are no
errors.

I also tried "touch /forcefsck" This will force fsck during boot. The
very first time I got an error and I was dropped in "repair file
system." I ran fsck and it did not find any errors. After that,
every-time I force an fsck during boot it does not find any errors.

Can anyone explain this? Should I be worried? Or should I ignore fsck
in multi-user mode and rely on what fsck tells me in single user mode?
Thanks,

Dan Timis
Muse Research, Inc.

In article <1103068679.403971.104960@z14g2000cwz.googlegroups .com>,
timis@museresearch.com writes:
>
> We are observing the exact same strange behavior on all our boxes. Once
> we are up and running in multi-user mode, we login and run "fsck -f -n"
> The root partition (/dev/hda2) always gives errors. The other two
> partitions (/dev/hda1 and /dev/hda4) have no errors. Then, we boot in
> single user mode umount /dev/hda2 and run "fsck -f" There are no
> errors.

The mounted partition with programms having open files is seldom clean.
You can try sync bevore checking, but i think you are playing
"russian roulett" with your data.

--
MFG Gernot

timis@museresearch.com wrote:

> We are observing the exact same strange behavior on all our boxes. Once
> we are up and running in multi-user mode, we login and run "fsck -f -n"


.... really? running a mounted filesystem and booted
into runlevel 3(5)? you dont happen to be a sysadmin
or Linux developer for this company, i hope.

the filesystem, in that condition, is considered
dirty - a better question is:

"why would you want to run fsck on a mounted filesystem
and that that system is 'up and running'"?
--
<< http://michaeljtobler.homelinux.com/ >>
He who attacks the fundamentals of the American broadcasting industry
attacks democracy itself. - William S. Paley, chairman of CBS

Gernot Fink wrote:
> In article <1103068679.403971.104960@z14g2000cwz.googlegroups .com>,
> timis@museresearch.com writes:
> >
> > We are observing the exact same strange behavior on all our boxes.
Once
> > we are up and running in multi-user mode, we login and run "fsck -f
-n"
> > The root partition (/dev/hda2) always gives errors. The other two
> > partitions (/dev/hda1 and /dev/hda4) have no errors. Then, we boot
in
> > single user mode umount /dev/hda2 and run "fsck -f" There are no
> > errors.
>
> The mounted partition with programms having open files is seldom
clean.
> You can try sync bevore checking, but i think you are playing
> "russian roulett" with your data.
>

I'm using "-n" so I am not changing any data, so the command is safe.
There is nowhere in the fsck manual any mention that running fsck -n on
a mounted system would give you wrong results. They say that it is
dangerous to run fsck without -n on a mounted file system, but I'm not
doing that.

I also did an extensive google search and found nothing to explain the
behavior. I'm not surprised of what I'm finding out from your response,
but I could not confirm this without asking.

I was probably asking the wrong question. The right question would be:
if I am running "fsck -n -f" on a mounted file system, can I get a
reliable diagnosis and find out if the file system is OK or corrupted?
Apparently the answer is no. Correct?

Thanks,

Dan

p.s. Someone asked why would I want to do that. Our product is a box
with a custom front panel. Attaching a VGA monitor keyboard and mouse
is optional, and most of our customers use the box without any
attachments. If we run fsck from rc.sysinit and it finds a problem and
it drops into repair disk mode, the user will have no way of knowing
without a monitor attached. The box would just sit there forever
partially started.

The way we do updates for our product is that the customer connects a
Mac or PC with an Ethernet cable and using samba they mount a portion
of the hard drive and copy an rpm to a specific folder. Then, they
press a button on the front panel.

I was hoping that we can check the integrity of the file systems
including the root file system during the %pre section of the rpm and
do not perform the update if there is a problem. We can use umount on
the two other partitions, but not on the root partition.

In article <1103230742.551756.80520@f14g2000cwb.googlegroups. com>,
"timis@museresearch.com" <timis@museresearch.com> writes:
>
> I was probably asking the wrong question. The right question would be:
> if I am running "fsck -n -f" on a mounted file system, can I get a
> reliable diagnosis and find out if the file system is OK or corrupted?
> Apparently the answer is no. Correct?
>

Yes this is correct. A working filesystem is the most time inconsistent.

--
MFG Gernot