[TriLUG] What does action mean in /etc/rc.d/rc.sysinit?

[Tom Bryan]

You may remember that I recently created a new partition for holding 
/usr/share since my /usr partition was almost full.  I've migrated all of the 
data to my new partition, and /etc/fstab now looks like 

LABEL=/                 /                       ext3    defaults        1 1
LABEL=/usr/share        /usr/share              ext3    defaults        1 2
LABEL=/data             /data                   ext3    defaults        1 2
/dev/fd0                /mnt/floppy             auto    noauto,owner    0 0
LABEL=/opt              /opt                    ext3    defaults        1 2
LABEL=/usr              /usr                    ext3    defaults        1 2
LABEL=/usr/local        /usr/local              ext2    defaults        1 2
LABEL=/oracle           /oracle                 ext3    defaults        1 2
LABEL=/mvstar           /mvstar                 ext3    defaults        1 2
inigo:/home             /home                   nfs     rw,bg,hard,intr 0 0
inigo:/usr/local/CvsRoot    /usr/local/CvsRoot  nfs     rw,bg,hard,intr 0 0
none                    /proc                   proc    defaults        0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /dev/pts                devpts  gid=5,mode=620  0 0
/dev/hda11              swap                    swap    defaults        0 0
/dev/cdrom              /mnt/cdrom        iso9660 noauto,owner,kudzu,ro 0 0

The problem is that I keep getting 
Feb  5 22:14:55 localhost mount: mount: mount point /usr/share does not exist
Feb  5 22:14:56 localhost rc.sysinit: Mounting local filesystems:  failed
on boot.

The following line in /etc/rc.d/rc.sysinit seems to be the one that's failing
action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs -O 
no_netdev

I don't know what "action" is.  Once the system finishes booting, I see that 
the /usr/share partition has been mounted
# mount
....
/dev/hdb5 on /usr/share type ext3 (rw)

Running the mount command from rc.sysinit on the command line produced no 
errors.  

Any ideas?  Could the "action" command be detecting a bogus failure?

Thanks,
---Tom