Conference decwet::advfs_support

    Is there anyway to "undo" the -r switch once a domain has been created
    to allow multiple volumes?
    
    Apparently, either the Installation GUI or volencap (system disk) is
    setting this switch for the usr domain. Actually, now that I think of
    it, the only time I have seen this problem is when using the FIS
    operating system.
    
    -Ron
    

Not to my knowledge.  I know that the installation GUI is not setting it for
/usr, so my guess would be that you should file a QAR/CLD against FIS.

--Ken

    So, ALL of our UNIX customers have FIS'd /usr with -r.
    
    I know a my customer (new to Digital Unix, and AdvFS, of course) was
    struggling with trying to add volumes to the use domain but could not. 
    He has a few disks sitting on his KZPSC RAID controller that he would
    like to use.
    
    What would a recommendation be to work around his disk 0 that came with
    root and usr FIS'd with -r.  Actually I guess root must be -r, but how
    to fix /usr?  Reinstall?  If so, how much of what?

First, please file a showstopper QAR against FIS for doing this in the first
place.  *sigh*

To fix systems that are already out there, the best suggestion I have requires
enough extra disk space to make a copy.

Here's a "script" you can use to fix things.  Note that I'm typing this in off
the top of my head, so there may be typos or I may screw up a flag or two.  Read
the man page(s) to double check me.

This assumes that /dev/rz3g is an unused disk partition at least as large as the
disk space that's used up in the current usr_domain.

	# mkfdmn /dev/rz3g usr_domain2
	# mkfset usr_domain2 usr
	# mount usr_domain2#usr /new_usr
	# clonefset usr_domain usr usr_clone
	# mount usr_domain#usr_clone /usr_clone
	# cp -pR /usr_clone /new_usr		[or use vdump | vrestore, or
						 whatever your favorite copy
						 routine is]
	# mv /etc/fdmns/usr_domain /etc/fdmns/old_usr_domain
	# mv /etc/fdmns/usr_domain2 /etc/fdmns/usr_domain
	# shutdown -r now

If everything is working correctly, and you know you've got all the data from
/usr properly copied over, then you can do the following if you want the old
partition to still be used in /usr:

	# rmfdmn old_usr_domain
	# addvol /dev/rz0g usr_domain
	# rmvol /dev/rz3g usr_domain

Ta-da.

--Ken

    I just got word of this problem (sorry, I'm not a regular reader here).
    Yes, FIS does have a bug that unintentionally reversed things. /usr is
    getting the -r, and / isn't (sigh!). We're preparing an update now;
    it'll take a little time for it to propagate to the plants.

    - tom

    
    It will be helpful if a simple command can be issued to check whether a
    domain had been created with -r option before.
    
    The following vods command can only be found on V3.2x system. What is
    the equivalent command under V4.0x ?
     
    # /usr/field/vods  /dev/rz1d | grep maxVds
    maxVds 256                 	<--- default
    # /usr/field/vods  /dev/rz1a | grep maxVds
    maxVds 1                    <--- with -r
    
    ~Song-Huat

    OK, assuming .8 (Thank-you!) fixes the problem with usr, how do you get 
    the root domain to be -r.  
    
    (Pardon if this is trivial, I have an
    inexperienced customer wrt Digital UNIX, and I want to minimize the
    negative impact of this situation - thay are also being directed to our
    formal CSC support channel).

"How do you get the root domain to be -r?"

Hmmmm.  Very carefully.  :-)

The easiest thing to do would be to just tell the customer to *NEVER* addvol a
volume to root_domain.

The next easiest thing would be to try the following.  Use all the same caveats
that apply to 330.8.

	# mkfdmn -r /dev/rz3a tmp_root_domain
	# mkfset tmp_root_domain root
	# mount tmp_root_domain root /new_root
	# clonefset root_domain root root_clone
	# mount root_domain#root_clone /root_clone
	# cp -pR /usr_clone /new_usr		[or use vdump | vrestore, or
						 whatever your favorite copy
						 routine is]
	# rm -r /new_root/etc/fdmns/root_domain
	# mv /new_root/etc/fdmns/tmp_root_domain /new_root/etc/fdmns/root_domain
	# shutdown -h now
	>>> set bootdef_dev DKA300
	>>> boot

The main thing to remember is that the bootdef_dev has to point at the disk
containing the new root domain, and the /etc/fdmns/root_domain directory in the
new domain has to point at the same disk.  I've managed to screw up my system
before by having them point to two different disks, and the system gets VERY,
VERY confused.  Because you've got two copies of "working" root domains on the
'a' partition of two disks, everything can look normal until you reboot and find
that some changes you made didn't appear.

Needless to say, be *real* careful when doing this.

--Ken