ioscan -m dsf, vgdisplay, and syslog.log not consistent re boot device

[dgangemi]

Hi

First I hope this is the right forum let me know if I have it wrong.

I've just installed my first Itanium/11.31 OS - an rx3600. The syslog.log has the following entry:
vmunix: Boot device's HP-UX HW path is: 0.4.1.0.500000e015501382.0

This corresponds with c0t0d0 as shown in ioscan -funC disk:
disk 4 0/4/1/0.0.0.0.0 sdisk CLAIMED DEVICE HP DG072A9BB7
/dev/dsk/c0t0d0 /dev/dsk/c0t0d0s2 /dev/rdsk/c0t0d0 /dev/rdsk/c0t0d0s2
/dev/dsk/c0t0d0s1 /dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s1 /dev/rdsk/c0t0d0s3
disk 2 0/4/1/0.0.0.1.0 sdisk CLAIMED DEVICE HP DG072A9BB7
/dev/dsk/c0t1d0 /dev/rdsk/c0t1d0

vgdisplay -v vg00 gives me the DSF pvname of disk5_p2:
vgdisplay -v vg00
.
.
.
--- Physical volumes ---
PV Name /dev/disk/disk5_p2
PV Status available

but ioscan -m dsf shows me this:
Persistent DSF Legacy DSF(s)
========================================
/dev/rdisk/disk5 /dev/rdsk/c0t1d0
/dev/rdisk/disk6 /dev/rdsk/c0t0d0
/dev/rdisk/disk6_p1 /dev/rdsk/c0t0d0s1
/dev/rdisk/disk6_p2 /dev/rdsk/c0t0d0s2
/dev/rdisk/disk6_p3 /dev/rdsk/c0t0d0s3

Well obviosly something is wrong disk 5 cant be the boot device - it doesn't have the partitioning. Furthermore, I *know* that c0t1d0 is in vg01:
vgdisplay -v vg01
.
.
.
--- Physical volumes ---
PV Name /dev/dsk/c0t1d0
PV Status available
Total PE 17501
Free PE 0
Autoswitch On

PV Name /dev/dsk/c0t2d0
PV Status available
Total PE 17501
Free PE 0
Autoswitch On

PV Name /dev/dsk/c0t3d0s2
PV Status available
Total PE 17276
Free PE 0
Autoswitch On

PV Name /dev/dsk/c0t4d0
PV Status available
Total PE 17501
Free PE 0
Autoswitch On

PV Name /dev/dsk/c0t5d0s2
PV Status available
Total PE 17276
Free PE 5331
Autoswitch On

ioscan -fenC disk shows that the device reported as the boot device in syslog.log is c0t0d0s2 as you would expect:
disk 4 0/4/1/0.0.0.0.0 sdisk CLAIMED DEVICE HP DG072A9BB7
/dev/dsk/c0t0d0 /dev/dsk/c0t0d0s2 /dev/rdsk/c0t0d0 /dev/rdsk/c0t0d0s2
/dev/dsk/c0t0d0s1 /dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s1 /dev/rdsk/c0t0d0s3
Acpi(HWP0002,PNP0A03,400)/Pci(1|0)/Sas(Addr500000E015501382, Lun0)/HD(Part1,SigF9558A84-1545-11DC-8000-D6217B60E588)/\EFI\HPUX\HPUX.EFI

But vgdisplay is implying that it is disk5 (c0t1d0) not c0t0d0.

So either I've got a LVM problem, or ioscan -m dsf is mis-mapping the DSF's.

Any thoughts?

[Steven E. Protter]

Shalom,

strings /etc/lvmtab

Lets see what the system thinks the score is.

SEP

[dgangemi]

Pretty much what you would expect given the vgdisplay output:

#strings /etc/lvmtab
/dev/vg00
/dev/disk/disk5_p2
/dev/vg01
/dev/dsk/c0t1d0
/dev/dsk/c0t2d0
/dev/dsk/c0t3d0s2
/dev/dsk/c0t4d0
/dev/dsk/c0t5d0s2

[marie-noelle jeanson]

Hi,

To verify the boot device associated with hw path 0.4.1.0.500000e015501382.0 , you can also use the ioscan command with new -N option:
ioscan -kfnNC lunpath will show LUNs with their lunpath hardware path. Description field shows "lunpath for disk#".
To see the associated dsf name, run ioscan -kfnNC disk -I # (# being in disk# above).

Marie.

[marie-noelle jeanson]

Hi,

Did you resolve your problem? If not, a console messages or syslog file may help identify the problem if you want to post the info (if still available).

Marie.

[dgangemi]

No - sorry got temporarily pulled off to another project - you know how it is. I ran ioscan -kfnNC disk and what came back seems to be implying that I'm getting two DSFs per disk:

Class I H/W Path Driver S/W State H/W Type Description
===========================================================================
disk 15 0/0/2/1.0x0.0x10 UsbScsiAdaptor CLAIMED LUN_PATH USB SCSI Stack Adaptor
disk 5 64000/0xfa00/0x0 esdisk CLAIMED DEVICE HP DG072A9BB7
/dev/disk/disk4 /dev/disk/disk5 /dev/rdisk/disk5
disk 6 64000/0xfa00/0x1 esdisk CLAIMED DEVICE HP DG072A9BB7
/dev/disk/disk5_p1 /dev/disk/disk6 /dev/disk/disk6_p3 /dev/rdisk/disk6_p2
/dev/disk/disk5_p2 /dev/disk/disk6_p1 /dev/rdisk/disk6 /dev/rdisk/disk6_p3
/dev/disk/disk5_p3 /dev/disk/disk6_p2 /dev/rdisk/disk6_p1




When I run ioscan -kfnNC lunpath as you suggested, it confirms that the boot device (...1382...) is disk6, which corresponds with c0t0d0. So why does vgdisplay -v vg00 show me disk5 - which is c0t1d1 - and is par of vg01?
Class I H/W Path Driver S/W State H/W Type Description
==================================================================
lunpath 1 0/4/1/0.0x500000e0154fcb22.0x0 eslpt CLAIMED LUN_PATH LUN path for disk5
lunpath 3 0/4/1/0.0x500000e015501382.0x0 eslpt CLAIMED LUN_PATH LUN path for disk6
lunpath 4 0/4/1/0.0x500000e015512022.0x0 eslpt CLAIMED LUN_PATH LUN path for disk9
lunpath 0 0/4/1/0.0x500000e0155198e2.0x0 eslpt CLAIMED LUN_PATH LUN path for disk13
lunpath 5 0/4/1/0.0x500000e015528622.0x0 eslpt CLAIMED LUN_PATH LUN path for disk11
lunpath 2 0/4/1/0.0x500000e015528bf2.0x0 eslpt CLAIMED LUN_PATH LUN path for disk12

[marie-noelle jeanson]

Hi,

Looks like you have a real mapping problem here for some reason.
Under disk 5, you have dsfs for disk5 and disk4.
And under disk6, you have dsfs for disk5 partitions and disk6.

Does not look good. I am not sure how you can clear/clean up your dsf assignments. But that would help.

Marie.

[marie-noelle jeanson]

Hi,

Could you run the command:
escsi_diag > escsi_diag.out
and post the output?

Marie.

[dgangemi]

Thats a pretty healthy sized dump! See attached.

[dgangemi]

What would you say to my just renaming /etc/lvmtab and running vgscan -a? Do you think that would be any help, or would it put me in a worse situation?

[marie-noelle jeanson]

Hi,
According to the file attached, if you run lssf -s, you will see that you have stale dsfs (no longer in use):

/usr/sbin/lssf -s
2
3 Stale Character Device Files
4 ----------------------------
5 /dev/rdisk/disk4
6 /dev/rdisk/disk5_p1
7 /dev/rdisk/disk5_p2
8 /dev/rdisk/disk5_p3
9 /dev/rdisk/disk15
10 /dev/rdisk/disk15_p1
11 /dev/rdisk/disk15_p2
12 /dev/rdisk/disk15_p3

So it seems that the I/O config has changed at some point resulting in minor numbers and instances numbers to be reassigned to disks. Any idea what happened? Maybe there is info in syslog.

You may remove the stale dsfs using rmsf -x.
Then you may reconfigure LVM and that may fix it.

Marie.

[dgangemi]

Well it could be that after I initially installed the system, I had to add disks from two other systems that were not yet installed and those disks had boot partitions on them which could have cause problems with hardware paths. It could also be that I had to replace the DVD drive - which also may have caused changes to hardware paths and/or WWNs.

Your solution sounds interesting, what risks are involved? What impact to production? Could you expand on the process a little?

[marie-noelle jeanson]

OK, possible explanation:

Did you happen to run rmsf -k on some of the devices? This could have led to this situation as this command removes the corresponding i/O nodes and frees corresponding minor numbers from the kernel database without removing corresponding DSFs. If the system was rebooted, the minor numbers got re-assigned, resulting in a mismatch between LVM and the I/O config.

Marie.

[dgangemi]

No, that didn't happen. Actually I think it had to do with either adding those additional disks in the lower drive bays and/or swapping the DVD drive. I read somewhere that 3600s and 6600s have that issue.

The main concern I have now is what the impact will be when I rmsf -x on my VGs and whether I can reconfigure LVM in multiuser network mode or if I have to use maintenance mode.

[marie-noelle jeanson]

Hi,

Latest news: HP reproduced a similar problem (happens when SAS is present).

Do not run vgscan!

Better not touch your LVM config at the moment until the problem is better understood.

Could you provide these:
ls -l /dev/disk
ls -l /dev/rdisk
ls -l /dev/dsk
ls -l /dev/rdsk

Marie

[dgangemi]

Here you go! See attachment.

[dgangemi]

I was searching for related issues and I ran across this thread:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=929929&admit=-682735245+1182953166624+28353475

Text after "#" are my own comments:

1. Boot into maintenance mode. # By this I expect he means LVM maintenance mode.
# Wouldn't a vgchange -a be required here to deactivate vg00 first?
2. vgexport vg00

3. mkdir /dev/vg00

4. mknod /dev/vg00/group c 64 0x000000
5. vgimport /dev/vg00
# In my case I only have one drive in the volume group.

If you are using standard lvol names then a map file is not needed.

# Again, wouldn't a vgchange be required here to reactivate vg00?

6. vgscan

7. Do vgdisplay of vg00, it should now show the current and 4 active.

8. lvlnboot -v

9. Reboot the system.

The system should successfully display all active volume groups

Good Luck

vinod

[Jean-Marc Eurin]

Hi,

On HP-UX 11i v3, there are some LVM enhancements that would hopefully make your life easier.

You should be able to:
- Run 'vgscan -k -f vg00' to make the lvmtab part of vg00 match what is in memory
- Run 'vgscan -k -f vg01' to make the lvmtab part of vg01 match what is in memory
- Run 'lvlnboot -R' to update the boot information on your vg00 disk.

I hope this helps,

Jean-Marc

[marie-noelle jeanson]

Hi,

1.You can run rmsf -x, that is safe, it just cleans up stale devices.


2. we could ask also for the following:
1. /stand/ext_ioconfig output
2. lsdev
3. /var/adm/syslog & OLDsyslog.log

But maybe it is time for you to open a call with HP...

Marie-Noelle

[dgangemi]

OK

Thanks for your help.