At boot vinum often does not remember these drives should be striped. Booting (usually, but not always as sometimes vinum works) drops me into single user where I have to manually run the above vinum command again which finally creates /dev/vinum/vinum0. At that point my fs will mount cleanly. I don't believe the config is being written to the disks and not sure that I'm not the one doing something wrong:
[EMAIL PROTECTED]  uname -a
FreeBSD Opus.home 5.2.1-RELEASE-p9 FreeBSD 5.2.1-RELEASE-p9 #1: Mon Aug 9 14:42:06 CDT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OPUS i386
[EMAIL PROTECTED]  vinum list
D vinumdrive1 State: up /dev/ad6s1d A: 0/156041 MB (0%)
D vinumdrive0 State: up /dev/ad4s1d A: 0/156041 MB (0%)
V vinum0 State: up Plexes: 1 Size: 304 GB
P vinum0.p0 S State: up Subdisks: 2 Size: 304 GB
S vinum0.p0.s0 State: up D: vinumdrive0 Size: 152 GB
S vinum0.p0.s1 State: up D: vinumdrive1 Size: 152 GB
[EMAIL PROTECTED]  vinum saveconfig
[EMAIL PROTECTED]  vinum setdaemon
Options mask: 0
[EMAIL PROTECTED]  vinum dumpconfig
[EMAIL PROTECTED] 
If I'm not mistaken "dumpconfig" should have produced results similar to "list" but while "list" displays running information from kernel space, "dumpconfig" should go direct to the media for its answer? And dumpconfig is finding nothing?
Have tried putting vinum_load="YES" in /boot/loader.conf in addition to start_vinum="YES" in /etc/rc.conf. Vinum_load only seems to cause the rc scripts to say, "vinum already loaded" or similar.
-- David Kelly N4HHE, [EMAIL PROTECTED] ======================================================================== Whom computers would destroy, they must first drive mad.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"