Missing '/foreign' labels on image backups

[Hoff]

Call HP support.

Kirby's VMS RMS internals book is almost certainly outdated here. That reference lacks ODS-5 support and particularly lacks the GPT stuff, but there's also a good chance it's not going to reflect the updates made to the alternate boot block algorithms. MOUNT changed a couple of times here, and changed again for the GPT support.

Make certain the console EFI firmware is current. The older EFI stuff had a very helpful feature or a very nasty bug here, and that could cause corruptions within the structures of ODS-2 and ODS-5 disks. (I'd not expect that bug to zero out LBN 1, however.)

Make sure the p400 firmware is current.

In general, I'd use the sys$setboot tool here; there's an option in that tool to dump the boot block structures. The following will show the boot block for the device ddcu:

$ sb:==$sys$setboot
$ sb -f ddcu: -s

Why -f for the device, I hear? The -f was the file path to the boot file structures, but the tool can (now) usually default everything past the device name and (depending on what you're doing) the target architecture.

If there's a GPT around and referenced by the MBR, the -s command will attempt to decode the GPT structures, or it'll squawk.

And -? will get you help.

The command can recognize and decode the boot structures for VAX and Alpha, and the Itanium MBR-GPT and MBR boot structures.

On a GPT disk, LBN 0 is the Master Boot Record MBR.

On a non-GPT disk, the MBR can be (is) present, and it is (was?) possible for the disk to be bootable via the MBR (only), though that was (is?) unsupported.

MOUNT /FOREIGN might be looking at LBN 1 as part of its compatibility, but it should be looking at other blocks as part of the home block search.

LBN 1 on a GPT disk is the GPT header; the partition table header.

If this quest is simply looking for the label, I'd probably skip this whole sequence and use something like the following:

$ MOUNT /OVER=ID ddcu:
$ volnam = f$getdvi("ddcu:","VOLNAM")

Regardless, getting LBN 1 entirely zeroed out is, um, troubling. (The GPT structures are pretty empty, but I'd not expect to see a whole block of zeros at LBN 1 on a GPT disk.)

BACKUP should restore the GPT from the source BACKUP saveset, if there was one. A "true" foreign disk may or may not have a GPT, at the option of whatever created the disk. If it's a classic VAX or Alpha VMS disk structure being restored via BACKUP (or a /NOGPT disk), it won't have one.

Best to open a support case with HP.

Worst case, this could well be a P400 RAID bug, too.

I'd also enable privilege auditing for use of the physical I/O PHY_IO privilege. This would not be the first time I've seen a $qio go wrong somewhere; a rogue $qio call from some application.