12-06-2004 01:04 AM
I've tried putting the kernel in the LIF on the front of the tape. I've tried dd'ing the kernel after the LIF.
12-06-2004 01:09 AM
The easiest way to do this is to download and install Ignite and then run make_tape_recovery. This will give you a bootable tape that you can use to restore your root VG - very handy for disaster recovery.
12-06-2004 01:18 AM
12-06-2004 04:44 AM
7.2.4 Creating a Bootable System Backup
HP-UX doesn't have the mksysb command nor a command that all by itself does the same thing, but you can create a bootable image of a disk using DDS. The following is an example of backing up an internal SCSI disk drive at target number 6.
Shut down to single user mode to minimize system activity:
# shutdown 0
Clear any remaining data in the buffers:
Use dd to copy the LIF boot area:
dd if=/usr/lib/uxbootlf of=/dev/rmt/0mn bs=2k
Again, sync the disk:
Use dd to append to append the disk data:
# dd if=/dev/rdsk/c0t6d0 of=/dev/rmt/0m bs=64
The first dd puts a boot area on the tape, making it a bootable image. Once the boot image is on tape, the tape is not rewound. The next dd appends an image of the SCSI disk at address 6 to the tape. Be sure to use the appropriate disk device file.
Once created, the tape can be used to completely restore the disk:
Insert the tape into the DDS tape drive.
Go into the Boot Administration utility and boot to ISL from the tape. If your tape drive is at target 3, then your command would look like:
BOOT_ADMIN> b scsi.3.0 isl
Enter the following in response to the ISL prompt in order to restore to the internal drive at target 6:
ISL> hpux restore disc(scsi.6;0)
This command restores the disk image from the tape to the actual disk at scsi.6, destroying any existing data on the disk. There is a 2GB limit on the amount of data that can be restored. The tape and disk must be on the boot device interface.
Under HP-UX a bootable tape can be created. For HP-UX 9.X, the mkrs utility is used to do this. Under 10.X the copyutil is used.
Hope this helps
12-06-2004 04:44 AM
Here is the contents from my make_tape_recovery
$dd if=/dev/rmt/0m of=/extra/tapeLif bs=10k
0+48217 records in
0+48217 records out
$lifls -l /extra/tapeLif
volume ISL10 data size 960926 directory size 3 04/12/06 01:08:16
filename type start size implement created
ISL -12800 16 242 0 04/12/06 01:08:16
AUTO -12289 264 1 0 04/12/06 01:08:16
INDEX BIN 272 1 0 04/12/06 01:08:16
CONFIG BIN 280 68 0 04/12/06 01:08:16
HPUX -12928 352 1024 0 04/12/06 01:08:16
FWWKAR6 BIN 1376 1 0 04/12/06 01:08:16
FWWKAR7 BIN 1384 1 0 04/12/06 01:08:16
FWWKAR8 BIN 1392 1 0 04/12/06 01:08:16
INSTALL -12290 1400 68184 0 04/12/06 01:08:22
INSTALLFS -12290 69584 49152 0 04/12/06 01:08:26
VINSTALLFS -12290 69584 49152 0 04/12/06 01:08:26
WINSTALLFS -12290 69584 49152 0 04/12/06 01:08:26
VINSTALL -12290 118736 73806 0 04/12/06 01:08:31
WINSTALL -12290 192544 83837 0 04/12/06 01:08:35
INSTCMDS BIN 276384 30244 0 04/12/06 01:08:36
RECCMDS BIN 306632 988 0 04/12/06 01:08:36
SYSCMDS BIN 307624 77795 0 04/12/06 01:08:39
SCRIPTS BIN 385424 45 0 04/12/06 01:08:39
VERSION BIN 385472 1 0 04/12/06 01:08:39
PAD BIN 385480 256 0 04/12/06 01:08:39
The kernel names ending in "INSTALL" causes the ram disk to be built, and the matching "INSTALLFS" to be loaded on to it. At that point the kernel just runs 'init' like usual, but in this case 'init' is Ignite code.
The boot syntax to instruct 'hpux' to load the kernel from the lif instead of from network or disk:
Note the ':' colon.
Loading software from the tape is the next step, and it is all in the Ignite code, not delivered anywhere else in the OS.
12-06-2004 09:01 PM
hpux boot (;0):FRED
But I get
Exec failed: Exec format error
FRED is simply created by using
lifcp -Knnn -b /stand/vmunix fredlif:FRED
(where nnn is calculated to put kernel on a 2k boundary)
I've tried creating fredlif:FRED as BIN, RAW, -12800, -12289, -12928 and BINARY, but none of them seem to work. Is the problem the lack of a RAM disk, or the format of the kernel itself?
12-09-2004 04:17 AM
12-09-2004 06:20 AM
If the kernel name _does_ end in INSTALL and has the ramfs driver in it:
nm INSTALL |grep -i ramfs
krs_free_ramfs_funcp| 11286848|extern|data |$BSS$
ramfs_init | 4095956|extern|entry |$CODE$
ramfs_return_pfds | 4096312|extern|entry |$CODE$
ramfsbegin_real | 11051588|extern|data |$SHORTDATA$
ramfsbegin_vir | 11051584|extern|data |$SHORTDATA$
ramfssize | 11051580|extern|data |$SHORTDATA$
reserve_ramfs_memory| 4096076|extern|entry |$CODE$
return_ramfs_memory | 4096448|extern|entry |$CODE$
Then the kernel will look for a ram filesystem image in the same location it was loaded from with the name ending in INSTALLFS
that matches the kernels name:
WINSTALL - kernel
WINSTALLFS - RAMFS image
So if the kernel is loaded from LIF, it will look in the LIF for the ramfs image.
12-12-2004 08:48 PM
12-12-2004 09:21 PM