Thank you to all who responded. The below answer from Matthew Keen was the most useful answer, though I did not manage to get the problem sorted out and started to find it hard to justify the effort in recovering vs the effort in rebuilding the system. Eventually I did rebuild the system and it is now happy. The below doesn't explicitly state it, but it would seem the approximate correct order to rename a system with Veritas encapsulated boot disks is: uname -S <newname> vxdctl hostid <newname> vxdctl init <newname> cd / umountall init 6 log on and fix /etc/hosts and other files, eg under /etc/ > zactomud204 [/var/adm] # /usr/local/scripts/txtgrep "-l `hostname`" /etc Building list of text files... Done building list - found 597 text files. Starting search for RE /etc/default/telnetd /etc/default/ftpd /etc/inet/hosts /etc/net/ticlts/hosts /etc/net/ticots/hosts /etc/net/ticotsord/hosts /etc/mnttab /etc/lp/printers/hplj40500004/alert.sh /etc/lp/printers/hplj40500036/alert.sh /etc/printers.conf /etc/vx/volboot /etc/nodename /etc/master_hosts_file (In that order) The second step automatically fixes the /etc/vx/volboot file, so the file does not need to be manually modified. It did not work for me and I am not sure why, but I could get the system to boot into single-user mode only as it refused to mount /usr or /var, even though these are on the same disk where root was mounted from. Part of the problem is that I did not have access to volume-manager functionality when doing a net boot. I will be looking into a net boot server with volume manager "pre-installed", though I think licensing is going to be a headache. I did not do much testing with changing the vfstab entries back to the original c0t0d0s0 type items or setting install-db mainly due to time contraints. For completeness' sake I also include the best response detailing these, as per Vipin Sharma, and the original request I posted at the bottom. Thanx _Johan Matthew Keen <mkeen To: Johan Hartzenberg/GIS/CSC@CSC @falmail.rta. cc: nsw.gov.au> Subject: RE: Very Urgent: Veritas can't import rootdg after renaming syste m 27/11/2001 11:07 AM Please respond to mkeen Dude, This is direct from veritas support site : Symptom: What to do after changing the host name of the system Solution: There is nothing that needs to be done if the host name of the system is changed. However, once the Solaris name of the machine is changed, it is a good idea to change the name in the /etc/vx/volboot file to match the new host name for cleaner booking. NOTE: Editing the volboot file may corrupt it. VERITAS Volume Manager (VxVM) uses the value in the hostid field in the volboot file and matches this with the hostid field in the private region of each of the disks VxVM imports. When the machine boots, it will scan the private regions on all the disks it can see, and if the fields match, then VxVM imports the disk group. For example, the host name of the box is sptsunvcs3 sptsunvcs3> more /etc/vx/volboot volboot 3.1 0.18 hostid sptsunvcs3 <----hostid end This is one of the private regions of the disks that has been imported: Disk: c1t12d0s2 type: sliced flags: online ready private autoconfig autoimport imported diskid: 998473977.1839.sprsunvcs3 dgname: msdg dgid: 999267390.2270.sprsunvcs3 hostid: sptsunvcs3 <---hostid is the same If the Solaris host name has been changed and the volboot file has been updated to reflect the new name, then use the following command: vxdctl init <new hostname> This will update the private regions on any disks in imported disk groups. If, after running the vxdctl command, some disk groups exist that were not imported, then manually import them after issuing the init command: /usr/sbin/vxdg import newdg When a disk group is manually deported, then the hostid field will be blank in the private region of the disk. Therefore when rebooting the server, the deported disk group will not be imported automatically. If that disk group is to be imported automatically, then issue the following command: /usr/sbin/vxdg -t import newdg This will import the group with the current host name of the server in the private region field. To deport the group and have it auto imported during the next boot, run the following command: /usr/sbin/vxdg -t deport newdg The above holds the value in the private region of the disk instead of making it blank, so it will be auto imported. ---------------------------------------------------------------------------- ---- Regards, Matthew Keen Remove the encapsulation 1. change the /etc/vfstab to all native devices e.g. cxtxdxsx instead of /dev/vx/dsk/rootvol 2. change the /etc/system file 3. remove the /etc/vx/reconfig.d/state.d/root-done 4. touch /etc/vx/reconfig.d/state.d/install-db and boot the system then do the vxinstall and encapsulate the boot disk again , you shouild be all set. vipin -----Original Message----- From: jhartzen@csc.com [mailto:jhartzen@csc.com] Sent: Tuesday, 27 November 2001 6:45 PM To: sunmanagers@sunmanagers.org Subject: Very Urgent: Veritas can't import rootdg after renaming system I am going to try the following but hopefully someone has got an easier procedure boot from net rename system back to original name boot from veritas volumes remove the rootmirror boot from the mirror disk try to remove the original disk from the root dg rename the system again to the new name reboot re-encapsulate the root disk re-add the rootmirror But i'm not sure if this will work. Please let me know how this should be done ASAP, I have a system down! Thanx, _Johan _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Thu Nov 29 11:40:36 2001
This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:32:36 EDT