Ignite error anew

Chapter 19. After Antonia received a beating from a Brigatisti, Beowulf Agate saved and brought her to a doctor. I was reading this novel when Maki asked if I encountered the error below:

[root@server21:/opt/ignite/bin]
# /opt/ignite/bin/make_net_recovery -s ignite_server -x inc_entire=vg00
* Creating NFS mount directories for configuration files.
======= 07/16/08 23:12:49 EDT Started /opt/ignite/bin/make_net_recovery. (Wed
Jul 16 23:12:49 EDT 2008)
@(#)Ignite-UX Revision C.7.4.157
@(#)ignite/net_recovery (opt) Revision:
/branches/IUX_RA0712/ignite/src@72068 Last Modified: 2007-11-01 14:16:06 -0600 (Thu, 01 Nov 2007)

* Testing for necessary pax patch.
* Checking Versions of Recovery Tools
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
00E7FED2223/recovery/2008-07-16,23:12
/system_cfg vg00/opt/ignite/bin/save_config[16]: lssf: Execute permission denied.
save_config: Error - unknown disk type for /dev/dsk/c0t6d0s2, not SCSI or HPFL
awk: Cannot find or open file /var/tmp/swapinfo.tmp.
The source line number is 1.
awk: Cannot find or open file /var/tmp/swapinfo.tmp.
The source line number is 1.
save_config: Error - cannot determine primary swap size
ERROR: /opt/ignite/bin/save_config failed
======= 07/16/08 23:13:26 EDT make_net_recovery completed unsuccessfully

[root@server21:/opt/ignite/bin]
#

Well the first course of action is to check on the execution of `lssf` [which btw, resolved the issue - check with the permission or file rule on this: "SEC team"]. However, just out of curiosity, I checked on the swap. It showed 3 but upon checking on the /etc/fstab entries, it listed only 2.?. So, here comes the experiment, I added the missing and activated it. Then tried to run the ignite backup again. But, to no avail. Still getting the same error. Well, see, I learned.

Ignite backup error - The list_expander command failed

Hello team, I'd like to share one of the common errors you will find during ignite backup.

[root@hpux02:/root]
# /opt/ignite/bin/make_net_recovery -s hpux03 -x inc_entire=vg00
* Creating NFS mount directories for configuration files.

======= 04/11/08 10:56:30 SST Started /opt/ignite/bin/make_net_recovery. (Fri
Apr 11 10:56:30 SST 2008)
@(#) Ignite-UX Revision B.5.4.50
@(#) net_recovery (opt) $Revision: 10.637 $

* Testing pax for needed patch
* Passed pax tests.
* Checking Versions of Recovery Tools
ERROR: Cannot stat device file: /dev/old_vg_apps/lv_mom: No such file or
directory (errno = 2). Check /etc/fstab for a bad entry.
ERROR: The list_expander command failed. This could be due to a problem with
the -x options specified - see messages above.

======= 04/11/08 10:57:11 SST make_net_recovery completed unsuccessfully

[root@hpux02:/root]
#

AND/OR

# /opt/ignite/lbin/list_expander
ERROR: Cannot stat device file: /dev/old_vg_hr03/lv_u01: No such file or
directory (errno = 2). Check /etc/fstab for a bad entry.

[root@hpux02:/root]
#

This occurs when certain FS is no longer in use and was not removed in /etc/fstab. I check it using:

# bdf <block_device_name>
# bdf /dev/old_vg_apps/lv_mom

OR

# mount -v grep -i <pattern>

AND/OR

# lvdisplay <block_device_name>
# lvdisplay /dev/old_vg_apps/lv_mom

If it does NOT return any of your expected result, then it is safe to say that the FS is NOT is use. From here, we can proceed by commenting [deleting] this but, make sure to have a backup just in case. Systems admins know this by heart. "He who laughs last, made a backup!". Proceeding..

# cp -p /etc/fstab /etc/fstab.backup1.20080411
# vi /etc/fstab
....
/dev/old_vg_hr03/lv_u01 /old/var/opt/vghr03/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr04/lv_u01 /old/var/opt/vghr04/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr05/lv_u01 /old/var/opt/vghr05/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr06/lv_u01 /old/var/opt/vghr06/u01 vxfs delaylog,mincache=direct 0 2
/dev/old_vg_hr07/lv_u01 /old/var/opt/vghr07/u01 vxfs delaylog,mincache=direct 0 2
....

So, our target here is to comment these lines so that it will not be read by ignite. For this case, we can comment it one by one. But for cases where we want to comment hundreds of lines, it'll take a lot of time. So I searched for some vi commands that will do this task for me. And I found it here: http://sparky.rice.edu/~hartigan/vi.html.

I executed this in command mode: :218,$s/^/\#

This means that, I'd like to insert a "#" character at the beginning of each line from line 218 to the last. Save and exit. Then re-ran ignite. As of this writing, it's running smoothly.

Interesting topic: http://forums12.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1207883792669+28353475&threadId=996179

Ignite backup

I was surprised to receive a PM from my colleague. As part of the process we follow, we need to make an ignite backup of system we do patching on. Most of the time, it goes smooth but they can never be perfect, 82-0 is just impossible. Anyway, I have encountered this issue a couple of times already. I've read some discussions on this but still trying to understand. Way to far, to many to learn! Going back, here's the error:

...
* Saving the information about archive to
/var/opt/ignite/recovery/previews
* Creating The Networking Archive

Permission denied
ERROR: Unable to mount or write
server1:/var/opt/ignite/recovery/archives/client_svr1
On server1 you may need to:
mkdir -p /var/opt/ignite/recovery/archives/client_svr1
chown bin:bin /var/opt/ignite/recovery/archives/client_svr1

vi /etc/exports (add or modify an entry). The /etc/exports file on
"server1" should contain the entry:
"/var/opt/ignite/recovery/archives/client_svr1 -anon=2,access=client_svr1".
After editing the /etc/exports file, run exportfs -av

If you need to change the owner of the directory,
you will also need to re-export the directory.

See make_net_recovery(1M) for more information.
ERROR: Failed to Create NFS mount Archive directory.

======= 04/10/08 09:07:54 SST make_net_recovery completed unsuccessfully

[root@server1:/var/opt/ignite/recovery]
#

I followed the suggestion here: `mkdir`; `chmod`; and `exportfs` but to no avail. Well, the workaround is NOT to limit access to the specific client, i.e., delete the entry "access=client_svr1" from /etc/exports; then run re-export the FSes. Now, it's working well. As mentioned earlier, it's just a workaround. So we need to restore the entries in the config files.

Read on: http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1017493&admit=109447627+1207790553782+28353475