- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Kernel stack not valid - after updates
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2011 01:32 PM
тАО02-21-2011 01:32 PM
I installed OpenVMS 8.4 which runs. Applied patches UPDATE 1, SYS and UPDATE 4, reboot in between, without a problem. Next all that were superseded (accoring ITRC) in UPDATE 4, inclusing Decnet and TCPIP ECO 2 - in one go.
That may have been a mistake, because now startup ends with:
halt code = 2
Kernel stack not valid halt
PC = 0
My guess is that it happens when loading the bootsrtap loader - because it's the first next thing shown after "jumping to bootstrtap code". Even booting conversationally, or any flag for that matter, fails.
It's just my test box and re-installing the OS is always possible. But I would like to know what causes the problem.
(Because the system doens't boot, I cannot tell the patch history in detail...)
OpenVMS Developer & System Manager
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2011 01:50 PM
тАО02-21-2011 01:50 PM
Re: Kernel stack not valid - after updates
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2011 02:54 PM
тАО02-21-2011 02:54 PM
Re: Kernel stack not valid - after updates
John is correct, you should log a case with us here at HP support. The issue you ran into recently was noted in a customer advisory concerning the Update V4 patch. In a nutshell, the patch replaced the VMB.EXE image, but a write boot command was not issued to point to the correct VMB.EXE on disk. When you added other patches and the "undo" data was over written, the old VMB.EXE that was moved to the PCSI$UNDO directory was removed causing the boot failure.
There is an UPDATE V5 kit for Alpha V8.4 being release in the very near future that will correct that issue. In the mean time, if you can boot another drive (even the install CD for 8.4) you can run writeboot to fix the issue.
Best regards,
Walt McGaw
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-21-2011 04:05 PM
тАО02-21-2011 04:05 PM
SolutionBoot the CD distro or a spare disk, get to DCL, and issue
SET BOOTBLOCK ddcu:
or
RUN SYS$SYSTEM:SYS$SETBOOT
...answer the questions...
or
RUN SYS$SYSTEM:WRITEBOOT
...answer the questions...
with the device targeting your system disk.
The first command is usually the easiest.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2011 03:48 AM
тАО02-22-2011 03:48 AM
Re: Kernel stack not valid - after updates
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2011 04:19 AM
тАО02-22-2011 04:19 AM
Re: Kernel stack not valid - after updates
I'l try and recover like Hoff stated, and try to gain some evidence, and log a message to programs@hp.com (I cannot issue a call since I don't have a support contract....)
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2011 04:36 AM
тАО02-22-2011 04:36 AM
Re: Kernel stack not valid - after updates
>> and log a message to programs@hp.com
The email id of Office of OpenVMS programs is - OpenVMS.Programs@hp.com.
Please route your query to HP via this email id.
Regards,
Murali
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2011 06:07 AM
тАО02-22-2011 06:07 AM
Re: Kernel stack not valid - after updates
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2011 06:31 AM
тАО02-22-2011 06:31 AM
Re: Kernel stack not valid - after updates
Expected.
When this update happens, APB.EXE gets archived or gets deleted, but the contents of the disk blocks (unless you have erase on delete enabled) aren't immediately overwritten.
But the BTBDEF boot block pointers are aimed at what will eventually be overwritten storage.
Until the blocks containing the old APB.EXE contents are overwritten, it'll still work. (Well, delta whatever was fixed in the newer APB.EXE image, given it's the older version that's still running. For now.)
One path toward long-term remediation would be the implementation of a flag in PCSI to spawn a WRITEBOOT or (as BACKUP does) via calling the sys$setbootshr API when the boot file gets replaced. That automates the process of updating the boot block, and avoids a kitting-level mistake that has arisen occasionally over the years.
> It was after I next installed the patches that were superseded, according the master ECO list.
Which then overwrite some or all of the storage from the deleted APB.EXE, and which triggered what amounts to the bootstrap leaping into hyperspace.
Here concludes the lesson in Alpha bootstrap blocks. If you're interested in more detail:
http://labs.hoffmanlabs.com/node/343
http://labs.hoffmanlabs.com/node/28
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-22-2011 06:34 AM
тАО02-22-2011 06:34 AM