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
be.
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
there.
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?
Thanks.
noah
--
_______________________________________________________
| Web: http://web.morgul.net/~frodo/
| PGP Public Key: http://web.morgul.net/~frodo/mail.html
Attachment:
pgpqWTfHcwJlB.pgp
Description: PGP signature