/dev/root mount prevents make_tape_recovery

[Ralph Grothe]

Hi,

a really silly catch.

When I tried to do a make_tape_recovery it aborted and wrote as cause this to the log:

# tail /var/opt/ignite/recovery/latest/recovery.log
* Checking Versions of Ignite-UX filesets
* Creating System Configuration.
* /opt/ignite/bin/save_config -f
/var/opt/ignite/recovery/2003-03-24,12:53/system_cfg /dev/root vg00
save_config: error - cannot determine actual root disk/volume referenced as /dev
/root
ERROR: /opt/ignite/bin/save_config failed


Oops, a bdf revealed that / indeed had been mounted via /dev/root.
Probably a leftover from an LVM maintenance run level?

Ok, I repeatedly tried the obvious

rm /etc/mnttab

mount -a

or

bdf

It always comes up again with /dev/root being mounted at /.

I even manually edited this very entry in mnttab by replacing the device by /dev/vg00/lvol3
(this being the LV which bears the Root FS according to "lvlnboot -v vg00")

Looks like the hen and egg paradoxon.

I need to do a make_tape_recovery before fixing this manually in LVM maintenance mode through a vgex- and import of vg00.
On the other hand make_tape_recovery won't let me because it cannot identify the actual root disk from /dev/root.

Any quick fix suggestions?

[Marco Santerre]

Hi, this might help

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000062947660

[Ralph Grothe]

Thanks Marco,

but I did move /etc/mnttab out of way (even did remove it), before issuing another "mount -a", several times.

As I said it keeps rebuilding /etc/mnttab with the hideous /dev/root entry :-(

[Francis_12]

Hi,

Your initial problem is not related to Ignite-UX but is this /dev/root problem.

The /dev/root moint point indicates that the system was booted in maintenance mode previously.

First, try :

# mv /etc/mnttab
# mount -a

May i suggest you having a look at this one :

http://bizforums1-qa2.mayfield.hp.com/cm/QuestionAnswer/0,,0x25337b8d1de3d5118ff40090279cd0f9,00.html

Hope this helps, Bye.

Francis.

[Ralph Grothe]

Thanks Francis,

please see my reply to Marco

[Michael Steele_2]

What does lvlnboot -v indicated? All boot disks responding OK? Stale extents? Pointing to the DVD ROM somewhere, lvmtab?

[T G Manikandan]

check for the root volume definition.

check

#lvlnboot -v


REvert

[Francis_12]

Hi again,

I've faced such issue some months ago and this solved :

1) reboot in single user mode (hpux -is)

2) rm /etc/mnttab

3) init 3

and retry after...

Hope this helps, Bye.

F.

[Pete Randall]

Hi Ralph,

I would try a simple reboot first to see if that straightens it out. If not, you could reboot in single user mode to mess with mnttab and see if that fixes it.


Pete

[Cheryl Griffin]

Does lvlnboot -v also fail?
Also verify everything in /dev/vg00 looks right (permissions, owner:group, major/minor number of group file, etc.)

[Robert-Jan Goossens]

Hi,

Q: I am trying to create a recovery tape for my system and I am using the make_recovery command to do so. I have updated to the latest revision of Ignite-UX, but I'm still having trouble getting the command to work. The error that I'm getting complains that the disk type is unknown. The exact error is this:

ERROR: save_config: error - unknown disk type for

/dev/vg00/lvol3, no scsi or HPFL.
A: The problem here can probably be found in the /etc/mnttab file. The make_recovery command is calling the save_config command to build the disk and file system layout. When save_config runs, it relies on the information in the /etc/mnttab file to determine what the root device is. It should be /dev/vg00/lvol3, but it's probably /dev/root instead. If you run /usr/bin/bdf it will probably show the / file system as /dev/root:

# /usr/bin/bdf /

Filesystem kbytes used avail %used Mounted on

/dev/root 86016 42359 40975 51% /
It should show /dev/vg00/lvol3:

# /usr/bin/bdf /

Filesystem kbytes used avail %used Mounted on

/dev/vg00/lvol3 86016 42359 40975 51% /
/dev/root can be caused by several things. Usually it happens because the system was booted into LVM maintenance mode at the ISL prompt ( ISL> hpux -lm ). It can also be that there is a problem with the LVM data structures on the root volume group.

To fix the problem, make sure that the boot definitions for vg00 are, indeed, correct. Use the lvlnboot -v command to do so:

# lvlnboot -v vg00

Boot Definitions for Volume Group /dev/vg00:

Physical Volumes belonging in Root Volume Group:

/dev/dsk/c0t5d0 (10/0.5.0) -- Boot Disk

Boot: lvol1 on: /dev/dsk/c0t5d0

Root: lvol3 on: /dev/dsk/c0t5d0

Swap: lvol2 on: /dev/dsk/c0t5d0

Dump: lvol2 on: /dev/dsk/c0t5d0, 0
This output is correct because Boot, Root, Swap, and Dump logical volumes are properly defined. If they are not correct, use the lvlnboot -b, -r, -s, -d options to fix them. If they are correct, it's simply a matter of fixing the /etc/mnttab file to show the correct info. This can be done with the mount -a command:

# rm /etc/mnttab

# mount -a

mount: /dev/vg00/lvol8 is already mounted on /usr

mount: /dev/vg00/lvol7 is already mounted on /opt

mount: /dev/vg00/lvol6 is already mounted on /home

mount: /dev/vg00/lvol5 is already mounted on /var

mount: /dev/vg00/lvol4 is already mounted on /tmp

mount: /dev/vg00/lvol1 is already mounted on /stand
Now bdf will show /dev/vg00/lvol3 and make_recovery should work.


Hope it helps,

Robert-Jan.

[T G Manikandan]

Also
revert with the output of

vgdisplay -v /dev/vg00 and also the contents of /etc/lvmtab


Thanks

[Marco Santerre]

I hate being the stupid guy here, but I assume you did check the entry in /etc/fstab for your / filesystem?

[Ralph Grothe]

Many thanks for your vivid interest,

here are some sanity dumps some of you had asked for

# grep ' / ' /etc/fstab
/dev/vg00/lvol3 / vxfs delaylog 0 1

# lvlnboot -v vg00
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c1t6d0 (8/12.6.0) -- Boot Disk
/dev/dsk/c2t6d0 (10/0.6.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Root: lvol3 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Swap: lvol2 on: /dev/dsk/c1t6d0
/dev/dsk/c2t6d0
Dump: lvol2 on: /dev/dsk/c1t6d0, 0

[Ralph Grothe]

forgot, regarding the stale PEs concern voiced

# vgdisplay -v|grep -i stale || echo nothing stale

# pvdisplay -v /dev/dsk/c[12]t6d0|grep stale || echo nothing stale
nothing stale

for i in 1 2; do dd if=/dev/rdsk/c${i}t6d0 of=/dev/null bs=256k count=1000;done
1000+0 records in
1000+0 records out
1000+0 records in
1000+0 records out

[Michael Steele_2]

Please increase your count parameter to 1000000 as you're likely to be only hitting the cache when count=1000.

control c to break after a count to ten or something.

[Sridhar Bhaskarla]

Hi Ralph,

vgdisplay alone will not give you stale entries. It's the lvdisplay. Run the following and see if there are any stale entries.

for i in $(vgdisplay -v vg00|grep "LV Name"|awk '{print $3}')
do
lvdisplay -v $i |grep stale > /dev/null 2>&1
if [ $? = 0 ]
then
echo $i is stale
fi
done



-Sri

[Ralph Grothe]

Sri,

even traversing all LVs shows everything in sync.
Albeit, I thought the LV Status entry in the "vgdisplay -v" would change from syncd to stale (or other) if any VGs weren't in sync

# lvdisplay -v $(vgdisplay -v|awk '/LV Name/{print $NF}')|grep stale||echo all in sync
all in sync

[Sridhar Bhaskarla]

Hi,

You are right, the LV status would become "stale" in vgdisplay. It's that I am used to lvdisplay to check stale entries.

Did you try refreshing lvlnboot 'lvlnboot -R' or running lvlnboot -b, lvlnboot -r etc commands, move /etc/mnttab and then do a mount -a?.

I am only trying to throw stones in the dark here as looks like you already tried all the known issues.

-Sri

[Michael Steele_2]

Go over to LOGTOOL and see how many I/O errors are collecting on the HW addresses associated to these boot disks. Sounds to me like you're on the verge.


STM > TOOLS > UTILITY > RUN > LOGTOOL > FILE > VIEW > RAW SUMMARY.

Note the first and last dates of transactions and calculate the difference. If the difference is short, like 4 hours, then this is important to note. Now read down the report of hardware addresses and observe the integer numbers in parenthesis. Anything over 150 in this 4 hour period should be called into HP for replacement.