boot problems: Not a LIF volume

[Runar Jørgensen]

Greetings

An alternate boot disk doesn't boot. I think I need help to
recreate the boot sector.

A boot disk has been running for years on a 700-series.
Alas, I don't have any info about events that led the disk
not to boot anymore. The disk was disconnected. The faulty
boot disk is now connected to a system that does boot. Both
are HPUX 10.20. 700-series. No mirroring involved. Single
boot disks.

Here's a summary so far:
* ioscan sees the disk (HW path: 2/0/1.1)
* lifls /dev/rdsk/c0t1d0 returns "Not a LIF volume"
* ISL> hpux ll disk(2/0/1.1;0) shows a present vmunix,
vmunix.prev and other files
* ISL> hpux show autofile disk (2/0/1.1;0) returns
"no such file or directory".
* ISL> lsa returns
Auto-execute file contains:
hpux
(Think that is for the working kernel, not the
alternate one.)

How do I proceed from here?

I've seen the case by Gary Cooper, "Ignite-UX has hijacked
my server"
(http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=978221).

Can I get away with just doing

ISL> hpux set autofile hpux

What more should I do?

Regards,
Runar Jørgensen

[Steven E. Protter]

Shalom,

Check your build against this guide.

pvcreate -B /dev/rdsk/c1t0d0 #use real disk

mkboot -l /dev/rdsk/c1t0d0
mkboot -a "hpux -lq (;0)/stand/vmunix" /dev/rdsk/c1t0d0 # use real disk


# mkboot -b /usr/sbin/diag/lif/updatediaglif -p ISL -p AUTO -p HPUX -p PAD -p LABEL /dev/rdsk/c?t?d?

If you are running 64-bit OS:

# mkboot -b /usr/sbin/diag/lif/updatediaglif2 -p ISL -p AUTO -p HPUX -p PAD -p LABEL /dev/rdsk/c?t?d?


vgextend /dev/vg00 /dev/dsk/c1t0d0 # same thing
lvextend -m 1 /dev/vg00/lvol1 /dev/dsk/c1t0d0

# real disk. repeat for other lvols

lvlnboot -r /dev/vg00/lvol3 # root fs /
lvlnboot -s /dev/vg00/lvol2 #swap
lvlnboot -d /dev/vg00/lvol2 #swap/dump
lvlnboot -b /dev/vg00/lvol1
lvlnboot -R
lvlnboot -v
setboot
setboot -a 52.1.0 # second disk

SEP

[Runar Jørgensen]

Hi

Thanks for the recipe. I've seen it before in the forum,
but hesitated to use it. Here's why:

Start with pvcreate. Using pvcreate will result in the loss
of any existing data currently on the physical volume, and
that was not my intention. Also I can only assume there is
LVM on this disk, thus pvcreate will be denied. Only
physical volumes not belonging to other volume groups can be
created.

The "l" and "lq" options to hpux bootstrap assumes LVM. I
don't know if this is a showstopper, but I can only assume
there is LVM on this disk.

Why would I want to use the -p AUTO option when installing
the boot programs ("b"-option). Isn't the autoexecute file
my problem since it's not present.

For the rest of the recipe, I think the disk will do fine as
long as the boot sector and LIF volume are restored.

As far I can tell there is a valid kernel on the LIF
volume, I very much would like to restore the LIF volume if
possible.

Regards,
Runar Jørgensen

[Matti_Kurkela]

Your ISL command

ISL> hpux ll disk(2/0/1.1;0)

is reading the HPUX loader from your good boot disk, then reading the /stand filesystem of your bad boot disk. It shows your /stand is probably OK. /stand is a hfs filesystem: the ISL loader does not understand hfs, but the HPUX loader does.

(The PA-RISC boot sequence: PDC firmware -> ISL -> HPUX -> vmunix HP-UX kernel)

Your idea of running

ISL> hpux set autofile hpux

would just make changes to the good boot disk, not the bad one. If you add the device path, it will probably produce an error message, since there is no boot LIF to edit.

The "Not a LIF volume" message from lifls sounds like the boot LIF does not exist or is corrupted. Maybe someone has run the "rmboot" command on it?

If the disk was pvcreate'd without the -B option, you have a problem: the boot area must be at the very beginning of the disk, before the LVM PV headers - and there are no tools for making that area free without losing data. Fortunately this problem is not likely, if the disk was working as a boot disk before.

If the pvcreate was done correctly, the problem is fixable by simply creating a valid boot LIF to the empty space in the beginning of the disk.

First, check whether or not there is enough space for the boot LIF:
mkboot -c -v /dev/rdsk/c0t1d0

If it says: "The requested boot programs will fit on the specified device", the fix is simple: just run the above command without th e "-c" option. It will generate the boot LIF and populate it with the necessary boot files.

If it says: "There appear to be non-boot logical volumes on this device. Overwriting them could destroy all the data on this device", you have the above-mentioned problem. Using mkboot to write the boot LIF would overwrite the beginning of your /stand filesystem. The boot could then proceed one step further, but would then fail in a new way.

MK

[Runar Jørgensen]

Greetings

Matti, excellent overview you provided. Thank you. I needed
to get stuff sorted out.

Unfortunately, the "boot area free space test" failed. I got
the second answer, i.e. " "There appear to be non-boot
logical volumes on this device. Overwriting them could
destroy all the data on this device".

The disk was bootable before this. I know for a fact (to 99%
certainty :-) ) that the disk was preinstalled when
purchased. So, I'm assuming that pvcreate -B was used in the
build. Also, I should assume (from mkboot man page) that LVM
layout was used. Thus, there should be a boot area large
enough to overwrite with mkboot, like this?.

# mkboot -a "hpux (;0)/stand/vmunix" /dev/rdsk/c0t1d0
# mkboot -b /dev/rdsk/c0t1d0

Will my vmunix be overwritten?
Do I then need to do pvcreate -B first? Even if it was a
prior boot disk?

You say I can use mkboot to write boot LIF, but it will fail
in a new way? Could you elaborate on that.

Regards,
Runar Jørgensen

[Matti_Kurkela]

If there is not enough space for the boot area, writing the boot LIF will overwrite the beginning of the LVM PV and maybe the beginning of the /stand filesystem too.

If only the LVM PV header gets overwritten, the HPUX loader will still be able to read and execute /stand/vmunix, but after that there will be problems in activating the vg00 volume group. You may find out that the system will boot only in LVM maintenance mode. Recovery will be difficult, since fixing the PV header (if that's even possible) will again overwrite the boot area, and you will be back where you started from.

If the beginning of /stand filesystem is overwritten too, the metadata of the /stand filesystem gets corrupted. The HPUX loader will not be able to find /stand/vmunix and your system will not boot at all.

If there is any important information on the disk, you could vgimport the vg00 of the bad disk using some other name. I strongly recommend you do this before any experiments with mkboot.

The required commands would be something like this:

mkdir /dev/vgbroken
mknod /dev/vgbroken/group c 64 0x010000
(remember to choose a minor device number that does not conflict with existing volume groups!)

vgimport -v vgbroken /dev/dsk/c0t1d0

This will report the names of the LVs on the bad disk.

Now you can mount the LVs of the bad disk. If a standard vg00 layout was used, you could do something like this:

mkdir /
mount /dev/vgbroken/lvol3 /broken
(root filesystem of the bad disk)

mount /dev/vgbroken/lvol1 /broken/stand

...and continue until you have the entire system VG mounted under /broken. You can use /broken/etc/fstab to identify the correct LVs.

Then you can back up everything you find necessary from the bad disk.

MK

[Runar Jørgensen]

Greetings

Matti, I followed your recommendation and tried to vgimport
the volume on the broken isk. No errors in the import process. No
LVs was reported on the broken disk.

# ls -l /dev/vgbroken/* returned the group file otherwise zilch

Regards,
Runar Jørgensen