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

[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.