Feeds:
Posts
Comments

Archive for the ‘Veritas’ Category

Details:

By default, a newly created volume will only have permissions for the root user only, i.e below is a ‘test’ volume under disk group testdg:
/dev/vx/dsk/testdg# ls -l
total 0
brw-------   1 root     root      79,76000 Jun  9 14:33 test
The permissions on the volume can be changed by using the chmod command:
/dev/vx/dsk/testdg# chmod 777 test
/dev/vx/dsk/testdg# ls -l
total 0
brwxrwxrwx   1 root     root      79,76000 Jun  9 14:33 test 
However, because chmod is an OS command, after the system reboots, the permissions on the volume are restored to what they were before, root.
In order to permanently change the permissions, a VERITAS Volume Manager command is needed to change the permission records within the disk group configuration:
vxedit set user=username group=groupname mode=xxxx volumename
Here is an example:
/dev/vx/dsk/testdg# ls -l
total 0
brw-------   1 root     root      79,76000 Jun  9 14:33 test
/dev/vx/dsk/testdg# vxedit set mode=777 test
/dev/vx/dsk/testdg# ls -l
total 0
brwxrwxrwx   1 root     root      79,76000 Jun  9 14:33 test     
This will allow the volume to retain its permissions even after the system reboots.

Group Permissions on a Volume

Here is the list of the current permissions on the volumes in testdg for a test system:
# cd /dev/vx/dsk/testdg
# ls -al
total 4
drwxr-xr-x   2 root     root         512 Apr  9 13:20 .
drwxr-xr-x   4 root     root         512 Apr  6 14:46 ..
brw-------   1 root     root     137,10002 Apr  9 13:20 pedvol
brw-r--r--   1 root     root     137,10001 Apr  3 08:31 testvol
brw-------   1 root     root     137,10000 Apr  3 08:21 vol01
To change the group that owns the volume:
# vxedit -g testdg set group=other testvol
The results are shown below:
# ls -al
total 4
drwxr-xr-x   2 root     root         512 Apr  9 13:20 .
drwxr-xr-x   4 root     root         512 Apr  6 14:46 ..
brw-------   1 root     root     137,10002 Apr  9 13:20 pedvol
brw-r--r--   1 root     other    137,10001 Apr  3 08:31 testvol
brw-------   1 root     root     137,10000 Apr  3 08:21 vol01
The group permission was changed from root to other.

Advertisements

Read Full Post »

Details:

vxdisk list displays duplicate entries for the disk device (c#t#d#s#) along with an error status:
# vxdisk list
DEVICE       TYPE      DISK       GROUP    STATUS
ct0d0s2       sliced    rootdisk      rootdg       online
c4t0d0s2     sliced    rootmirror    rootdg      online
c6t32d0s2   sliced    testdg02     testdg       error
c6t32d0s2   sliced           -            -              error
c6t33d0s2   sliced    testdg03     testdg       error
c6t33d0s2   sliced           -            -              error
c6t34d0s2   sliced           -            -              error
c6t34d0s2   sliced     testdg04     testdg      error
c6t35d0s2   sliced     testdg05     testdg      error
c6t35d0s2   sliced           -            -              error
c6t58d0s2   sliced     testdg06     testdg      error
c6t58d0s2   sliced           -            -              error

However, vxprint -ht -g testdg shows that the testvol volume is ENABLED and ACTIVE:
v  testvol      -                ENABLED  ACTIVE   314572800 RAID     -            raid5
pl testvol-01   testvol     ENABLED  ACTIVE   314592960 RAID     4/32       RW
sd testdg02-01  testvol-01   testdg02 0        17678493 0/0             c6t32d0  ENA
sd testdg03-01  testvol-01   testdg03 0        17678493 0/17678493 c6t33d0  ENA
sd testdg04-01  testvol-01   testdg04 0        17075205 0/35356986 c6t34d0  ENA
sd testdg05-01  testvol-01   testdg05 0        17678493 1/0             c6t35d0  ENA
pl testvol-02       testvol      ENABLED  LOG   7182     CONCAT    -              RW
sd testdg06-01  testvol-02   testdg06 0          7182         0             c6t58d0  ENA
Data on the disks remains accessible through VERITAS Volume Manager (VxVM) and the mounted file system. Therefore, vxdisk list displays incorrect information in regard to the disk group being in an error status.
Possible Root Causes:

  • Duplicate entries in the /etc/path_to_inst file.
  • Cables are crossed between controllers connecting to the disk array.

Solution:

1. Make sure all the SCSI or fiber channel connections are correct.


2. On Solaris, remove all duplicate entries in the /etc/path_to_inst file. If there are multiple hosts sharing the array, this will apply for all Sun systems.

3. The Sun system or systems must perform two configuration reboots this way: reboot -- -r. 
The results from validating SCSI and fiber connections, clearing out duplicate entries for path_to_inst and rebooting twice:
# vxdisk list
DEVICE       TYPE      DISK       GROUP    STATUS
c3t0d0s2      sliced    rootdisk       rootdg      online
c4t0d0s2      sliced    rootmirror     rootdg     online
c6t32d0s2    sliced    testdg02      testdg      online
c6t33d0s2    sliced    testdg03      testdg      online
c6t34d0s2    sliced    testdg04      testdg      online
c6t35d0s2    sliced    testdg05      testdg      online
c6t58d0s2    sliced    testdg06      testdg      online  

Read Full Post »

1 kilobyte = 1024 bytes

1 megabyte = 1024 kilobytes

1 gigabyte = 1024 megabytes

Example

The command below creates a 2 gigabytes concat volume, named “vol01”

# vxassist -g datadg make vol01 2g layout=concat init=active

Figure 1

The size of “vol01”, shown in Figure 1, is 4194304 sectors. Another method to retrieve the sector size of a volume is the command

# vxprint -g <dg-name> -Qqv <volume-name> | awk ‘{ print $5 }’

# vxprint -g datadg -Qqv vol01 | awk ‘{ print $5 }’

4194304

4194304 sectors can be converted to 2 gigabytes as follows:

4194304 sectors * 512 bytes per sector = 2147483648 bytes

2147483648 bytes / 1024 bytes per kilobyte = 2097152 kilobytes

2097152 kilobytes / 1024 kilobytes per megabyte = 2048 megabytes

2048 megabytes / 1024 megabytes per gigabyte = 2 gigabytes

Read Full Post »

Exact Error Message
cannot open /etc/path_to_inst

Details:

Note : This will only work if the rootdisk is encapsulated. You don’t have to break the root mirror.
Under VERITAS Volume Manager ™ rootdisk encapsulation, the administrator must take an extra step to ensure the path_to_inst file is created and populated. The difference lies in the root device. This value is not the same as the default offered during the boot, use the value specified for rootdev in the /etc/system file.
At the OK prompt, do the following:

1. boot -ar
Rebooting with command: boot -ar                                     
Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0  File and args: -ar
2. At the following prompts, just hit enter:
Enter filename [kernel/sparcv9/unix]: << ——–Hit enter
Enter default directory for modules [/platform/SUNW,Ultra-5_10/kernel /platform/sun4u/kernel /kernel /usr/kernel]:
Name of system file [etc/system]:  <<< Hit enter
SunOS Release 5.8 Version Generic_108528-15 64-bit
Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.
3. When the system asks about rebuilding the path_to_inst, type yes
The /etc/path_to_inst on your system does not exist or is empty.
Do you want to rebuild this file [n]? yes <<<<————–type yes
root filesystem type [ufs]: <<<<———— Hit enter
4. When you get to the following prompt enter /pseudo/vxio@0:0
Enter physical name of root device [/pci@1f,0/pci@1,1/ide@3/disk@0,0:a]: /pseudo/vxio@0:0 <<<<—- Enter this (this comes from /etc/system).
System will now boot OK.
WARNING: forceload of drv/ide failed
WARNING: forceload of drv/ide failed
WARNING: forceload of drv/pci failed
Starting VxVM restore daemon...
VxVM starting in boot mode...
configuring IPv4 interfaces: hme0.
Hostname: sunhost
VxVM starting special volumes ( swapvol )...
Configuring /dev and /devices
Configuring the /dev directory (compatibility devices)
VxVM general startup...
The system is coming up.  Please wait.
starting rpc services: rpcbind done.
Setting netmask of hme0 to 255.255.248.0
starting internet domain name server.
Setting default IPv4 interface for multicast: add net 224.0/4: gateway sunhost
syslog service starting.
Print services started.
volume management starting.
checking : /usr/sbin/luxadm
checking : /usr/lib/liba5k.so.2
checking : /usr/lib/libg_fc.so.2
checking : /usr/lib/sparcv9/liba5k.so.2
checking : /usr/lib/sparcv9/libg_fc.so.2
The system is ready.

Read Full Post »

Removing and reinstalling VEA packages can correct this symptom in many cases.

In version 5.0 VRTSvmpro has dependencies on VRTSfas.

To be able to remove VRTSvmpro the package VRTSfas must be removed first.

The VEA packages must be removed and re-installed in the order specified below.

1. Un-install the following packages in this order:

VRTSfas

VRTSfspro

VRTSvmpro

VRTSobgui

VRTSob

2. Install packages in this order:

VRTSob

VRTSobgui

VRTSvmpro

VRTSfspro

VRTSfas

NOTE – The VRTSvsvc package is obsolete in version 5.0 and should be removed to prevent any problems.

Refer to LBN article 282024 for additional detail.

Read Full Post »

Exact Error Message
bpcd: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory

Details:

Overview:
In Veritas NetBackup ™ Enterprise Server 5.x or 6.0, master servers may be unable to connect to the bpcd daemon on Linux clients using the administration console or may have backups failing with timeout errors.  This can also occur for the bpps and bmrsetupclient commands during the installation of NetBackup 6.0 clients.  These errors occur when the binaries on the client cannot load shared libraries.  Specifically, this is the result of the standard C++  compatibility libraries not being installed. In order to provide support for earlier versions of Linux, the NetBackup binaries were built with earlier versions of the C++ compatibility libraries, which may not have been installed on the problem client.
Troubleshooting:
To verify that the libraries are not installed, telnet to the bpcd port on the client from the master with the following command:

# telnet client 13782

If the libraries are not present, the output will be as follows:

# telnet <client name> 13782

Trying x.x.x.x

Connected to <client name>

Escape character is '^]'.

bpcd: error while loading shared libraries: libstdc++-libc6.2-2.so.3:

cannot open shared object file: No such file or directory

Connection closed by foreign host.

During a NetBackup 6.0 installation the following errors may appear if the standard C++ compatibility libraries are not installed.
/usr/openv/netbackup/bin/bpps: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory
/usr/openv/netbackup/bin/bmrsetupclient: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory
Log Files:  n/a
Resolution:
The solution is to install the standard C++ compatibility libraries in order to satisfy this library dependency. The version of Linux on the client will determine what RPM or software package needs to be installed.  Also check the Veritas NetBackup ™ OS Compatibility lists in the Related Documents section, below, to ensure the RedHat version is supported with the version of NetBackup that is running. 

For RedHat 4.0 Clients

The location of the required standard C++ compatibility library has been changed in RedHat 4.0 distributions. There is a different RPM that is required in order to install the library required for these binaries to run. Install the compat-libstdc++-296-2.96.132.7.2.i386.rpm package, which is located on the RedHat 4.0 Installation Disc 3.  

For RedHat 3.0 AS/ES/WS Clients

Install the compat-libstdc++-7.3-2.96.122.i386.rpm package, which is located on RedHat 3.0 Installation Disc 3 in ./RedHat/RPMS/compat-libstdc++-7.3-2.96.122.i386.rpm

For RedHat 9.0 Clients

Install the compat-libstdc++-7.3-2.96.118.i386.rpm package.

For RedHat 8.0 Clients

Install the compat-libstdc++7.3-2.96.110.I386.rpm package.

Depending on the version of Linux, the installation may require additional supporting packages to be installed long with the compat-libstdc++ package.  Contact RedHat support for assistance with locating and installing the correct version of the RedHat standard C++ compatibility RPMs as well as any other required packages.  An online search for RPMs is also available at the following Web site:  http://www.rpmfind.net/

Related Documents:
283789: GENERAL ERROR: Getting an error regarding the libncurses.so.5 library when trying to install a license key on a 64-bit Linux server
http://support.veritas.com/docs/283789
263839: Veritas NetBackup ™ 5.x Operating System Compatibility (updated July 16 2007)
http://support.veritas.com/docs/263839
278064: Veritas NetBackup ™ 6.x Operating System Compatibility List (Updated January 14, 2008)
http://support.veritas.com/docs/278064
251712: VERITAS NetBackup ™ DataCenter and NetBackup BusinesServer 4.5 Operating System Compatibility List (Updated December 2, 2005)
http://support.veritas.com/docs/251712

Supplemental Material:

Error Code: 58
NetBackup Error 58: can’t connect to client

Read Full Post »

Exact Error Message
cannot open /etc/path_to_inst

Details:

Note : This will only work if the rootdisk is encapsulated. You don’t have to break the root mirror.
Under VERITAS Volume Manager ™ rootdisk encapsulation, the administrator must take an extra step to ensure the path_to_inst file is created and populated. The difference lies in the root device. This value is not the same as the default offered during the boot, use the value specified for rootdev in the /etc/system file.
At the OK prompt, do the following:
1. boot -ar
Rebooting with command: boot -ar
Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0 File and args: -ar
2. At the following prompts, just hit enter:
Enter filename [kernel/sparcv9/unix]: << ——–Hit enter
Enter default directory for modules [/platform/SUNW,Ultra-5_10/kernel /platform/sun4u/kernel /kernel /usr/kernel]:
Name of system file [etc/system]: <<< Hit enter
SunOS Release 5.8 Version Generic_108528-15 64-bit
Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved.
3. When the system asks about rebuilding the path_to_inst, type yes
The /etc/path_to_inst on your system does not exist or is empty.
Do you want to rebuild this file [n]? yes <<<<————–type yes
root filesystem type [ufs]: <<<<———— Hit enter
4. When you get to the following prompt enter /pseudo/vxio@0:0
Enter physical name of root device [/pci@1f,0/pci@1,1/ide@3/disk@0,0:a]: /pseudo/vxio@0:0 <<<<—- Enter this (this comes from /etc/system).
System will now boot OK.
WARNING: forceload of drv/ide failed
WARNING: forceload of drv/ide failed
WARNING: forceload of drv/pci failed
Starting VxVM restore daemon...
VxVM starting in boot mode...
configuring IPv4 interfaces: hme0.
Hostname: sunhost
VxVM starting special volumes ( swapvol )...
Configuring /dev and /devices
Configuring the /dev directory (compatibility devices)
VxVM general startup...
The system is coming up. Please wait.
starting rpc services: rpcbind done.
Setting netmask of hme0 to 255.255.248.0
starting internet domain name server.
Setting default IPv4 interface for multicast: add net 224.0/4: gateway sunhost
syslog service starting.
Print services started.
volume management starting.
checking : /usr/sbin/luxadm
checking : /usr/lib/liba5k.so.2
checking : /usr/lib/libg_fc.so.2
checking : /usr/lib/sparcv9/liba5k.so.2
checking : /usr/lib/sparcv9/libg_fc.so.2
The system is ready.

Products Applied:
Volume Manager for UNIX/Linux 3.5 (Solaris), 4.0 (Solaris), 4.1 (Solaris)

Read Full Post »