Error message from adb

[Pete Randall]

Recent invocations of adb (as in echo "physmem/D" | adb $/stand/vmunix /dev/kmem) are producing an error message:

"Warning, the kernel and core release versions don't match.

This may also be due to crashfile corruption.
Proceeding anyway."

I interpret this as telling me that the versions of /stand/vmunix and /dev/kmem don't match.

First, how would these versions get un-matched? Second, is this cause for concern and, if so, how do I get things back in sync?


Pete

[Deoncia Grayson_1]

I'm not sure how helpful this link will be but looks like someone else had the same problem..

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=212005

[Bill Hassell]

Usually it is because the kernel was recompiled (vmunix was changed) but the system was not rebooted. Another symptom is that ipcs will report a namelist error as it uses both in-core and vmunix data for computations.

[Pete Randall]

No errors from ipcs and, as far as I know, there have been no new kernels built. We did have a bit of trouble while I was on vacation the first week in November, but that was just getting the machine to power up. I can't imagine what else my backup might have done that could cause this.


Pete

[John Poff]

Hi Pete!

You probably saw this, but here is a thread where someone had the same error. Their problem was that the system was configured to mount /stand from vg00/lvol1 (lvlnboot -v), but it actually had /stand mounted as vg00/lvol5. It's worth a check, especially if you had boot problems.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=212005

JP

[Pete Randall]

Hi JP,

Thanks - that's the same thread that Deoncia pointed out. I looked and things seem to be mounted properly.

I'm concerned because we're having some electrical work done this weekend and I'm going to have to shutdown. It sure would put a damper on my weekend if I couldn't get the machine back up.


Pete

[Scot Bean]

See if there is a /stand/vmunix.prev file.

Try running your command against that instead.

If it runs clean, the kernel WAS rebuild and machine was not rebooted.

[Pete Randall]

Good idea, Scot, but same result.


Pete

[Steven E. Protter]

Shot in the dark Pete.

During your problems in November, was the machine booted off an alternate mirror?

Maybe the mirror went out of date prior to that and there was a kernel compile or software installation pending.

the lvdisplay report should show the primary mirrors as stale in this case. Of course you know that and I'm just trying to help.

Is it possible to make this problem go away by merely compiling another kernel and booting the box?

I know I like to know why something happens but sometimes(rarely) time demands force me to just fix and forget.

SEP

[Sanjay_6]

Hi Pete,

Could be a VPar release issue,

http://www1.itrc.hp.com/service/cki/search.do?category=c0&mode=id&searchString=8606299037&searchCrit=allwords&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty

The itrc doc id is 8606299037.

Hope this helps.

regds

[Fred Ruffet]

Just to be sure...

Has /stand/vmunix a timestamp prior to last boot ? just compare ll /stand/vmunix and uptime.

Other point : is there a timestamp diff between /stand/vmunix and /dev/kmem ?

You talk about a backup. Did you restore anything since last reboot ? Did your restore /stand ?

Anyway, knowing why is one thing, but it will probably not save your week-end. As suggested by SEP, can't you compile a kernel and boot ?

Regards,

Fred