>>> boot dkf0 -> DKF0 is not a valid boot block -> bootstrap failure

[Thomas Schick]

Hello ALL

These are the err-msgs:
--------------------------------------------------------
(boot dkb0.0.0.8.1 -flags 0,0)
block 0 of dkb0.0.0.8.1 is not a valid boot block
bootstrap failure
-------------------------------------------------------
(the same for system-disk on adapter F)

First of all, the problem is fixed by using WRITEBOOT.EXE

http://h18000.www1.hp.com/support/asktima/operating_systems/00972A17-55372200-33028F.html!


Now, I am looking only for a rational explanation of that behaviour.


Here some facts, probably without any relation to the cause of the problem:

- OpenVMS Alpha V7.3 including all public patches
- the system was up since ~ 60 days
- DS20E with two MSA30/43xxy- enclosures on two KZPBC-AA
in hose 0 and 1 called B and F
- there is Host-based shadowing between B and F
- disk DKB0 was master member as the box booted for about 60 days
- disk B left the shadow- set for about 21 days by an unknown reason
(undetected by anyone, but visible through log-files-time entries on it)
- SYS$COMMON:[SYSEXE]APB.EXE has attribute ->MoveFile disabled<-
- ANALYZE/DISK/REPAIR DSA0: (=sys$sysdevice=only DKF0:) immediately
before the reboot shows some files but nothing unusual (my thin experience -> *sql*.com, *.*old*, ...)
- no ANALYZE/DISK on DKB0, because it was not a member of DSA0: since ~21 days

- DFU did not work on DSA0: (only DKF0:) ERR=> no ODS2 or 5 (no deeper analysis at this time)
- disk DKB300 had 136 errors on it (and IIRC PKB ~50) {sorry, my PuTTY has some trouble with 5000 scrollback lines and [copy all to clipboard]}


???->1.)
Does anyone has a suitable explanation for that?

???->2.)
What would be happen if I had restored a backup-save-set from yesterday- would be the disk bootable, INDEXF.SYS then be okay?



MTIA for any input
Thomas

[Thomas Schick]

Sorry, please excuse me - typo in the URL, here the right one:
http://h18000.www1.hp.com/support/asktima/operating_systems/00972A17-55372200-33028F.html

[Karl Rohwedder]

Thomas,

I have no clue what happened, but I once had a similiar problem (bootblock gone) and since then I had a little DCL procedure running by our nightjob (found on a COMPAQ website long ago), that checks if the bootblock is o.k. It runs on VAX/Alpha.
I added the definition of a logical name, so that the bootblock status can be easily checked by remote procedures.

regards Kalle

[Robert Atkinson]

Thomas, the only time I've seen this happen is either with a non-image backup/restore or Prefectdisk moving the bootblock (A problem with older versions).

The state of your shadow disk would give me definite cause for concern.

If the problem continues to show itself on a regular basis, I'd go for shutting down DFU to start off with.

Rob.

[Volker Halle]

Thomas,

the boot block and home block(s) are part of the first cluster of blocks on the disk. The disk structure level is not stored in the boot block, but in the home block. So the DFU error (reporting the disk not being ODS-2 or ODS-5) seems to indicate, that the home block was also somehow corrupted.

If you would have done a MOUNT/FOR DKF0: and a DUMP/BL=(START:0,COUNT:1) and saved the output before reparing the disk, details of the corruption could have been diagnosed.

ANAL/DISK or MOUNT should have reported an error, if the (primary) home block was bad, but could have used alternate home blocks to access the disk.

Regarding the source of the corruption: if you would have a program running doing logical IO to your system disk and it somehow got the LBN number wrong, something like this could happen. The corruption pattern could have told you...

Volker.

[Thomas Schick]

Robert,
DFU was installed short before the trouble but it could not have impact to the B disk which left the shadow-set several days before.

Prefectdisk, isn't running but DFO - helpful input (5 + 5pt)



Volker,
you are right I should have mentioned the output of MOUNT and ANALYZE/DISK:

$$$ mount/over=(id,shad) dkb0
%MOUNT-W-HOMBLKBAD, primary home block is bad; backup used
%MOUNT-I-MOUNTED, ALPHASYS mounted on _DKB0:
%MOUNT-I-REBUILD, volume was improperly dismounted; rebuild in progress

$$$ ana/disk/rep dkb0:
Analyze/Disk_Structure/Repair for _DKB0: started on 12-OCT-2005 06:37:28.06

%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 2, RVN 1
%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 3, RVN 1
%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 4, RVN 1
%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 5, RVN 1
%ANALDISK-W-CHKALTHOME, invalid alternate home block, VBN 6, RVN 1
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
%ANALDISK-W-DELHEADER, file (161,3,1) LES$LES_V30.EXE;1
marked for delete
%ANALDISK-W-DELHEADER, file (186,2,1) LOGICAL_NAMES.EXE_OLD;1
marked for delete
%ANALDISK-W-DELHEADER, file (212,2,1) SHELL8K.EXE_OLD;1
marked for delete
:
:
-o-o-o-o-o-o-o-

$ help /mess HOMBLKBAD
$ help /mess CHKALTHOME

[Volker Halle · Accepted solution]

Thomas,

the first cluster of blocks on the disk is filled (after the boot and the home block) with alternate home blocks.

With the ANAL/DISK output, you know that at least 6 blocks (starting at LBN 0) have been corrupted.

BACKUP will search for a good home block in the first 100 blocks of INDEXF.SYS and would not complain about bad homeblocks read, except if no valid home block is found at all. The bootblock is stored literally in a backup saveset record (see BACK/LIS/ANAL), the boot file LBN and checksum are re-written on restore, so it could have worked...

Volker.