How to generate HP Array Diagnostic Report (ADU Report) in Linux

How to generate HP Array Diagnostic Report (ADU Report) in Linux

We need to understand what is an Array, RAID and Array Configuration Utility (ACU). In the case of hardware RAID, multiple hard disk drives are combined to one logical drive and data is distributed across multiple hard drives. You can have RAID levels like RAID 0, RAID 1, RAID 5 etc.

I hope you are familiar with Array Configuration Utility. Using Array Configuration Utility, we can generate Array Diagnostics report (ADU).  ADU report is used for troubleshooting issues related to Hard drives, Smart Array Controller, Array Accelerator and Cache battery etc.

Please be informed that ADU report will not collect data content of logical/Physical drives. It only captures hardware information hence all of your data information is secured. ADU report could not capture File system types, contents, Software RAID information, Partition types, sizes etc.

ADU report can give consolidated view of any error or warning conditions encountered across the Array/RAID. ADU report also provides extensive information about all the storage devices.Information such as Device status, Firmware version number, RAID Configuration, Physical drive errorflags are available in ADU report.

In this article, we will learn how to generate ADU report using Array Configuration Utility (ACU). If you are not sure how to open ACU on your Server, then please read our article “Guide: Configure RAID using HP ACU on your HP Server” before you proceed. ACU can be launched within OS or from HP SmartStart CD. More information is available in above said guide.

Well, generating HP ADU report is quite simple and easy in Windows Operating System. However, when it comes to linux, everything is based on the CLI version, so here’s how to generate HP Array Diagnostic Report in Linux.

The name of the application is HP Array Configuration Utility CLI and executable name is hpacucli, so if not installed, this needs to be downloaded from hp.com download page and installed. (Refer my Note at the bottom on how to download the program). Also note that older versions of HP ACU (Versions older than 8.3) may not have the diagnostic features in it, in this case, you will have to update the utility to a newer version OR use the hpaducli  (HP Array Diagnostic Utility CLI) and NOT hpacucli (HP Array Configuration Utility CLI) which would have already been installed in the system.

Here’s the commands:

Generating Array Diagnostic report using the HPADUCLI:
Type: hpaducli -f OutputFileName.zip in the Linux prompt

Fig: hpaducli command

The “OutputFileName” could be any name you wanted to specify. In the picture above, i used adutestfile as the filename. The output would generally be saved in the /tmp folder. To get the generated txt file, type cd /tmp in the root and type ls to browse the folder.

Generating Array Diagnostic Report using the HPACUCLI

Type: hpacucli ENTER
If the hpacucli program is installed, it will take you inside the hpacucli program
Type: ctrl all diag file=/tmp/ADUReport.zip ENTER

Fig: hpacucli

The above command generate the HP Array Diagnostic report in a .zip format. The contents of the zip file depends on the version of HP ACU version used.You may also use the one line command to generate the report as under:
hpacucli ctrl all diag file=/tmp/ADUReport.zip

That is it, now you have generated the Array Diagnostic report, how do you extract it?

If unzip is installed you can simply type unzip filename.zip which should unzip the file for you.

Note: How to download the HP Array Configuration Utility CLI for Linux

1. Go to hp.com, click support & drivers at the top.

2. On the (green) box where it says Drivers & Software type the name of the Proliant server, eg.DL380 G7.

3. You will get many results out of which select the “HP Prolaint DL380 G7 Server“

4. Choose the Operating System.

5. Next, you are at the actual download page, search for HP Array Configuration Utility CLI

6. Download and install that file

RHEL-to-Solaris compare

Shutdown

RHEL	Solaris
shutdown -h now (or) poweroff	shutdown -y -g0 -i5
reboot	reboot (or) shutdown -y -g0 -i6
halt	halt

Kernel

RHEL	Solaris
/sbin/lsmod	modinfo
/sbin/insmod	modload
/sbin/rmmod	modunload
scanpci	/usr/X11/bin/scanpci (or) prtconf -v

Printing

RHEL	Solaris
lp (or) lpr	lp (or /usr/ucb/lpr)
lpstat (or) lpq	lpstat (or /usr/ucb/lpq)

Services

RHEL	Solaris
/sbin/service --status-all	svcs -a
/sbin/service sendmail stop	svcadm disable sendmail
/sbin/service sendmail start	svcadm enable sendmail
/sbin/service sendmail status	svcs sendmail
/sbin/chkconfig --list	svcs -a
/sbin/chkconfig --add /etc/rc3.d/f00	svccfg import f00.xml
/sbin/chkconfig sendmail on	svcadm enable sendmail

Monitoring

RHEL	Solaris
top	prstat
cat /proc/cpuinfo	psrinfo -v
cat /proc/meminfo	prtconf

NFS

RHEL	Solaris
exportfs	exportfs (or) share
(edit /etc/exports)	share /home
(edit /etc/exports)	unshare /home

Networking

RHEL	Solaris
/sbin/mii-tool	ndd (or) /sbin/dladm show-dev
ifconfig	ifconfig
/sbin/ethtool	ndd
/sbin/dhclient	dhcpagent
iptables	ipfilter

Storage

RHEL	Solaris
fdisk	fdisk (and) format
parted	format
mkfs -t ext3 /dev/hda1	mkfs -F ufs /dev/rdsk/c0t0d0s0
cdrecord dev=2,0 f00.iso	cdrw -i f00.iso
tar xfvj f00.tar.bz2	/usr/sfw/bin/gtar xfvj f00.tar.bz2
lvm/pv*/lv*/vg*	meta*

Dev

RHEL	Solaris
(edit /etc/ld.so.conf)	crle
gcc	/usr/sfw/bin/gcc
ld	/usr/ccs/bin/ld

Cloned Red Hat/CentOS/Scientific Linux Virtual Machines and “Device eth0 does not seem to be present” Message

Recently I was preparing some new virtual machines in VMware running Scientific Linux 6.  I encountered some difficulty with the virtual network interface after preparing clones of the machines.  In particular I was unable to get the virtual NIC on the newly cloned machine to be recognized as a valid interface.  Upon further investigation the NIC on the newly cloned machines was being registered as “eth1″.  We can check the currently registered “eth” devices here:


[root@sl6 ~]# ls /sys/class/net
eth1  lo  sit0
As it turns out there is a device manager for the Linux kernel named “udev” which remembers the settings from the NIC of the virtual machine before it was cloned.  I was not familiar with udev because it was not installed in my previous Linux VM install, which were mainly CentOS 5.

Since the hardware address of the network interface changes as part of the clone, the system sees the NIC after the clone as “new” and assigns it to eth1.  The simple way to move the interface back to eth0 is to edit the strings beginning with “SUBSYSTEM” in udev’s network persistence file.

Start off by removing the first “SUBSYSTEM” entry that represents the “old” eth0 interface.  Then edit the second “SUBSYSTEM” entry, changing the “NAME” parameter from “eth1″ to “eth0″.  Of course your config may vary from mine.  Keep in mind that the “SUBSYSTEM” line may be wrapped in the text below.

Old file:

[root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x15ad:0x07b0 (vmxnet3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:21", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x15ad:0x07b0 (vmxnet3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:25", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
New file:

[root@localhost ~]# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x15ad:0x07b0 (vmxnet3) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:87:00:25", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Now verify that you have a properly configured network config file, the example below is for Red Hat/CentOS/Scientific Linux:

[root@sl6 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="static"
HWADDR="00:50:56:87:00:25"
IPV6INIT="no"
IPV6_AUTOCONF="no"
NM_CONTROLLED="no"
ONBOOT="yes"
IPADDR="192.168.10.125"
NETMASK="255.255.255.0"
NETWORK="192.168.10.0"
BROADCAST="192.168.10.255"

Now reboot the system and the NIC should now be registered as eth0!

Hack the password protected “single user ” mode on Linux

The “single user ” mode could be used to bypass the security layer . Well single user mode can also be password protected , just append the following line in the  “/etc/inittab ” file :

su:S:wait:/sbin/nologin #Single level will be skipped —> goes directly to the default runlevel ie 5
su:S:wait:/sbin/sulogin #Single level will demand root password

Now your machine will demand the root password even if Linux is start on “single user ” mode . This extra layer of protection will only prohibit a newbie to break in to your Linux box . The following 4 steps  show how to bypass the protected “single user ” mode :

1. While booting pass this kernel parameter : init=/bin/bash
   This parameter will prevent the kernel to run the /sbin/init and proceed with the usual /etc/rc.d/*  procedure , it will just give us a shell (no password checks , no filesystem checks , no startup environment) . THE FILESYSTEM WILL BE IN READ -ONLY MODE .
2. The following command will remount the / filesystem writable .
   mount  -o  remount , rw  /
3. Now the password can be changed with the “passwd ” command . Do not reboot yet until :
4. mount  -o remount , ro /
5. Now press the reset button