tp3440 Ignite/UX Restore Drops to Shell

[Dennis Faucher]

Hello,

When I boot my rp3440 off of my successfully created make_tape_recovery DDS4 tape, the Ignite process stops at:

* Loading insf to create disk device files...
* Creating disk device files...
* Loading in a shell...
NOTE: Pushing a shell, you will have to use "reboot" to reboot the system
when done. Use the "loadfile" command to bring in more commands as
you need them.
#

The last lines of the debug version of this looks like this:

DEBUG: insf -e -S -H 0/4/1/0.8.0.255.0.5.0
insf: Installing special files for sdisk instance 14 address 0/4/1/0.8.0.255.0.5.0
DEBUG: sigchld: wait'ed on process: 121 (last_pid=121)
DEBUG: Free inodes: 2674

DEBUG: Checking for existence of IUXDCMDS
DEBUG: loadfile_main: pid = 122
DEBUG: Rewinding source
DEBUG: Seeking by reading 1792 bytes
DEBUG: Checking for existence of RECCMDS
DEBUG: loadfile_main: pid = 123
DEBUG: Rewinding source
DEBUG: Seeking by reading 1792 bytes
* Loading in a shell...
DEBUG: loadfile_main: pid = 124
DEBUG: loadfile bdf before:
Filesystem kbytes used avail %cap iused ifree iused Mounted on
/ 8532 3741 4791 44% 206 2674 7% ?
DEBUG: Starting raw-loadfile using my_popen
DEBUG: loadfile_main: pid = 125
DEBUG: Rewinding source
DEBUG: Seeking by reading 1792 bytes
DEBUG: Seeking by skipping 36645 blocks
DEBUG: loadfile(125): exiting due to SIGINT or SIGPIPEDEBUG: waiting on loadfile_pid: 125

DEBUG: Done:waiting on loadfile_pid: 125
DEBUG: loadfile bdf after:
Filesystem kbytes used avail %cap iused ifree iused Mounted on
/ 8532 4137 4395 48% 207 2673 7% ?
NOTE: Pushing a shell, you will have to use "reboot" to reboot the system
when done. Use the "loadfile" command to bring in more commands as
you need them.
#

My system is running HP-UX 11.11, Ignite/UX 5.4.5 and all patches and firmware are up to date. The DDS4 drive is in an external TapeArray 5300. The command used to successfully create the tape is:

/opt/ignite/bin/make_tape_recovery -a /dev/rmt/0mn -A -I -t "`hostname` - `date`" -v -x inc_entire=vg00

I have a call open with the Response Center (3206976262), but they are currently unsure of a solution. Any ideas are appreciated. Thank you.

Sincerely,
Dennis Faucher

[Steven E. Protter]

If you are connected to a fiber array, disconnect the cables until after the kernel loads.

I've noticed this helps with certain make_tape_recovery issues.

What's the log of the tape creation look like?

SEP

[Dennis Faucher]

Steven,

Thank you for your reply. I downgraded the Ignite/UX to the version that shipped with the server (5.2.124). This did not solve the problem. I disconnected the fiber channel cables that connect to the ds2405 and rebooted. Unfortunately, this did not solve the problem. The make_tape_recovery was successful. Here is the console output:

* Creating local directories for configuration files and archive.

======= 07/29/04 12:05:12 EDT Started /opt/ignite/bin/make_tape_recovery.
(Thu Jul 29 12:05:12 EDT 2004)
@(#) Ignite-UX Revision B.5.2.124
@(#) net_recovery (opt) $Revision: 10.624 $

* Testing pax for needed patch
* Passed pax tests.
* Recovery Archive Description = Recovery Archive

* Recovery Archive Location = /dev/rmt/1mn

* Number of Archives to Save = 2

* Pax type = tar


In? dsk/vg name minor# Associated disks/mountpoints
2 v /dev/vg00 0x00 /dev/dsk/c2t0d0 /dev/dsk/c2t1d0
/dev/vg00/lvol1 /stand 2
/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol4 /tmp 2
/dev/vg00/lvol5 /home 2
/dev/vg00/lvol6 /opt 2
/dev/vg00/lvol7 /usr 2
/dev/vg00/lvol8 /var 2
0 v /dev/vg01 0x01 /dev/dsk/c4t0d0 /dev/dsk/c5t0d0 /dev/dsk/c4t1d0 /dev/dsk/c5t1d0
/dev/vg01/lvol1 /usr/ud60 0
/dev/vg01/lvol2 /usr/local/backups 0
/dev/vg01/lvol3 /test 0
0 v /dev/vg02 0x02 /dev/dsk/c4t2d0 /dev/dsk/c5t2d0 /dev/dsk/c4t3d0 /dev/dsk/c5t3d0
/dev/vg02/lvol1 /src 0
/dev/vg02/lvol2 /store 0
/dev/vg02/lvol3 /patches 0
0 v /dev/vg03 0x03 /dev/dsk/c4t4d0 /dev/dsk/c5t4d0 /dev/dsk/c4t5d0 /dev/dsk/c5t5d0
/dev/vg03/lvol1 /educ/coll 0
/dev/vg03/lvol2 /dmc/coll 0
/dev/vg03/lvol3 /dmc/ben 0

** 0 - The Volume Group or Filesystem is Not included in the
System Recovery Archive
** 1 - The Volume Group or Filesystem is Partially included in the
System Recovery Archive
** 2 - The Volume Group or Filesystem is Fully included in the
System Recovery Archive

* Checking Versions of Ignite-UX filesets
* Creating System Configuration.
* /opt/ignite/bin/save_config -f
/var/opt/ignite/recovery/2004-07-29,12:05/system_cfg vg00
* Backing Up Volume Group /dev/vg00
* /usr/sbin/vgcfgbackup /dev/vg00
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
* Creating Map Files for Volume Group /dev/vg00
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg00.mapfile /dev/vg00
vgexport: Volume group "/dev/vg00" is still active.

* Backing Up Volume Group /dev/vg01
* /usr/sbin/vgcfgbackup /dev/vg01
Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
* Creating Map Files for Volume Group /dev/vg01
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg01.mapfile /dev/vg01
vgexport: Volume group "/dev/vg01" is still active.

* Backing Up Volume Group /dev/vg02
* /usr/sbin/vgcfgbackup /dev/vg02
Volume Group configuration for /dev/vg02 has been saved in /etc/lvmconf/vg02.conf
* Creating Map Files for Volume Group /dev/vg02
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg02.mapfile /dev/vg02
vgexport: Volume group "/dev/vg02" is still active.

* Backing Up Volume Group /dev/vg03
* /usr/sbin/vgcfgbackup /dev/vg03
Volume Group configuration for /dev/vg03 has been saved in /etc/lvmconf/vg03.conf
* Creating Map Files for Volume Group /dev/vg03
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg03.mapfile /dev/vg03
vgexport: Volume group "/dev/vg03" is still active.

* Creating Control Configuration.
* Creating Archive File List
* Creating Archive Configuration

* /opt/ignite/bin/make_arch_config -c
/var/opt/ignite/recovery/2004-07-29,12:05/archive_cfg -g
/var/opt/ignite/recovery/2004-07-29,12:05/flist -n 2004-07-29,12:05 -r
64 -d Recovery\ Archive -t -i 1 -m t
* Saving the information about archive to
/var/opt/ignite/recovery/previews
* Creating The Tape Archive
* Checking configuration file for Syntax
Adding /opt/ignite/Version file to LIF.
* Writing boot LIF to tape
85681+0 records in
85681+0 records out
* Complete writing boot LIF onto tape.
* /opt/ignite/data/scripts/make_sys_image -c n -d /dev/rmt/1mn -t n -s
local -n 2004-07-29,12:05 -m t -w
/var/opt/ignite/recovery/2004-07-29,12:05/recovery.log -u -R -g
/var/opt/ignite/recovery/2004-07-29,12:05/flist -a 4513060

* Preparing to create a system archive

* Archiving contents of rp3440.exeter.edu via tar image to local device/dev/rmt/1mn.
* Creation of system archive complete
NOTE: The following files are in the list of files that were on the
system, but they are no longer present. These files are not
included in the back-up:
/var/tmp/ign_configure/make_sys_image.log

* Cleaning up old configuration file directories

======= 07/29/04 12:22:21 EDT make_tape_recovery completed successfully!

Sincerely,
Dennis Faucher.

[Steven E. Protter]

Dennis,

There were some pretty big problems in Ignite 5.3, which caused HP to (paraphrase) recall the release and put out 5.5.x

These problems seemed to affect more Itanium based systems, but one never knows about these things.

The log looks absolute clean.

You have the -I on your command line, which I believe(i never use it, you can intervene with a keystroke without this option) that should take you to the Ignite Interface, not the shell recovery.

Based on your results, I would look into the following problems:

Do you have a pax patch installed? Does it support files bigger than 2 GB. There may be a problem with pax_iux unpacking those files. That problem hit me in the Ignite 3.x 4.x days but I've been told it was solved.

Finally, I'd say if possible, make sure there are not inconsistencies at the Ignite Shell, if you can get to it. If a disk dropped off the box, there might simply not be enough space to unpack the system.

There are rudimentary hardware/disk check feataures built into the Ignite Interface. Plug those fiber cables back in. That issue appears to only affect D/R/K class boxes.

Also, do all expected disks show up on the sea display at the console before you boot off the tape. I've also run into a scenario where I could create an Ignite tape on the external tape array but booting off of it caused a kernel panic. In that scenario HP eventually told me the drive array wasn't supported for Ignite recovery.

This is why we test, I'm sure we can at least discover the problem if not recover the system.

SEP

[Dennis Faucher]

Stephen,

Thank you for the imformation. I have the latest pax patch installed and the two internal drives do show up in SEA. The Response Center is supposed to have a response from WTEC on the issue now, so I'll see what they say.

Sincerely,
Dennis Faucher.

[Joe Short]

Dennis,

I know this is a reach, but what about you SCSI, and tape drivers. Have you tried patching them up? Perhaps there is some issue there? I just thought of a client I have that is running a similar configuration, rp3440, and DDS4 drives. I'll inquire and see if they are running into any issues there too.

[Dennis Faucher]

Joe,

Thanks for the ideas. Today, I disconnected the Tape Array 5300 and connected a standalone HP DLT80 with a new cable and terminator and received the same error. The error seems to be either in the rp3440 hardware or the software installed on the server.

Sincerely,
Dennis Faucher.

[Dennis Faucher]

Problem solved!

It was the terminal emulator I was using to log the restore process. HyperTerminal was sending an R key when it shouldn't and telling Ignite/UX to drop to a [R]ecovery shell.

Here is what I found:

Does not work
==========
o Hyperterminal v5.1, Serial, COM1, 9600 8N1, no flow control
o Hyperterminal v5.1, Serial, COM1, 9600 8N1, Xon/Xoff flow control

Does Work
========
o Physical HP console terminal
o Reflection for UNIX and Digital v10, Serial, COM1, 9600 8N1, Pacing Transmit None, Pacing Transmit Receive Xon/Xoff
o Java Web Console

Sincerely,
Dennis Faucher.