[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

289.0. "Any methods to trace the boot block invalid?" by HGOSPS::KENNETH () Thu Mar 06 1997 05:07

Hi,

One of my customer's system cannot boot up due to bootstrap failure.
The message is :

"Block 0 of dua34 is not a valid boot block Bootstrap failure"

My questions are:

1) Is there any ways to trace what causes the boot block invalid?  
   
2) If not, are there any possible causes that will make the block invalid?

The customer request us to send him a report, that's why I need to inestigate
it.

Thanks for your help in advance.

Kenneth Leung

T.R	Title	User	Personal Name	Date	Lines
289.1	Vax or Alpha?	CSC32::M_DIFABIO	MOVL #OPINION,EXE$GL_BLAKHOLE	`Thu Mar 06 1997 10:19`	7
	Kenneth, Is this an Alpha or Vax? We have ways's of 'patching' Vax code to trap writes to a given device and a given block. For alpha it would be easier to relink a new driver. What DO you have in the bootblock? Sometimes that info is helpful. Mark d.
289.2	Use-Of-Privilege Auditing for LOG_IO, PHY_IO	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu Mar 06 1997 10:30`	8
	You don't indicate the version or platform. If running OpenVMS V6.0 or later on VAX or Alpha, enable security auditing of the use of the LOG_IO and PHY_IO privileges. The problem mentioned in .0 can be a miscoded sys$qio[w] call -- one that has been miscoded to use IO$_WRITELBLK or IO$_WRITEPBLK rather than IO$_WRITEVBLK, and then run with LOG_IO or PHY_IO privilege enabled -- on a file access...
289.3		AUSS::GARSON	DECcharity Program Office	`Thu Mar 06 1997 17:26`	23
	re .0 >"Block 0 of dua34 is not a valid boot block Bootstrap failure" I assume that DUA34 did in the past have a valid boot block and that they have previously booted from that device. The customer needs to boot from an alternative device (e.g. CD) and dump the boot block. That may illuminate the reason. >1) Is there any ways to trace what causes the boot block invalid? It depends on how it becomes invalid. >2) If not, are there any possible causes that will make the block invalid? Rogue program run with LOG_IO or PHY_IO is one way (that I have actually seen - yes, I did rap the programmer over the knuckles). Priv auditting can trace this. Dead or dying disk is another. Has someone INITed the disk? I imagine that that can be priv auditted.