[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RAID, fs labels, and fsck

I'm working on a test machine which is running an XFS filesystem on a
software RAID0 volume.  The XFS filesystem has a lable ("foo").  In
/etc/fstab I have the following entry associated with it:

LABEL=foo	/mnt	xfs	defaults	0	0

Since the last field listed is 0, I expect the XFS filesystem not to be
fscked at boot time.  This is intentional as fsck.xfs is essentially a
big nop.  However, at boot time, I do not see the behavior I expect.  In
fact I get an error that halts the boot sequence.  The error is 
Couldn't find matching filesystem: LABLE=foo

fsck fails and I'm prompted for the root password.  If I hit CTRL-D to
skip the root login and proceed with the boot sequence, everything
continues as expected and the RAID filesystem is mounted as it should

I tried adding "-t ext2" to the list of options passed to fsck in
/etc/rcS.d/S30checkfs.sh hoping that it would cause fsck to completely
ignore xfs filesystems listed in fstab.  But that didn't help;
apparently fsck still wants to actually confirm that the filesystems are

I disabled the boot time fsck completely by adding "exit 0" to the top
of S30checkfs.sh, which works.  That work around is OK since I'm using
all XFS filesystems, but it would obviously not be acceptable if I was
using a combination of filesystems.

It seems like the problem is with the interaction between fsck and RAID,
though it doesn't seem like that should be the case.  The RAID subsystem
is initialized before checkfs.sh is run.  Is it a bug in fsck?  I'm
using the version included with e2fsprogs 1.20-0.bunk, part of Adrian
Bunk's collection of packages for using kernel 2.4.x with potato.  Has
anybody else seen similar behavior?  Did you find a fix for it?


| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html 

Attachment: pgpzjLq9ksEyX.pgp
Description: PGP signature

Reply to: