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
pgpXuJ14htkBv.pgp
Description: PGP signature
