- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Missing '/foreign' labels on image backups
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
тАО11-22-2010 10:02 AM
тАО11-22-2010 10:02 AM
Missing '/foreign' labels on image backups
Upon rare occasion I will have a condition where a disk seems to lose its 'mounted/foreign' label. By this I mean, I can mount the disk (physical or logical unit as part of a raid set) with the usual mount/over=id commands, but a mount/foreign will return a 'null' label as if the disk were empty. Otherwise, the drive looks perfectly normal with no missing information. ANA/DISK doesn't show any problems.
If I take an image backup of disk in this condition and restore it to another drive, the 'null' label moves with it.
All drives were originally created with the usual INIT command and a non-image restore (i.e., I restore a directory tree to a disk).
I have never seen this on ALPHA; I am using ODS-5 drives in all cases. As mentioned, I have seen this on 18gb and 72gb drives as well as logical units carved up from a p400 raid controller.
The only fix I know of is to INIT the disk again, and do a non-image restore of the drive using various backup qualifiers such as /owner=original, etc. SET VOLUME/LABEL=xxxx doesn't fix this.
The only reason this matters is that there's a command procedure in play at boot time that wants to check the volume label to make sure the right drive is in the right place. I realize I could remove this check, but it still seems kind of bizarre that this is happening...
ENGZZD $ mount/over=id dkb0:
%MOUNT-I-MOUNTED, DSPS mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ dism dkb0:
ENGZZD $ mount/for dkb0:
%MOUNT-I-MOUNTED, mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ dism dkb0
ENGZZD $ mount/over=id dkb0:
%MOUNT-I-MOUNTED, DSPS mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ set volume/label=dsps dkb0:
ENGZZD $ dism dkb0
ENGZZD $ mount/for dkb0:
%MOUNT-I-MOUNTED, mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ mount/over=id dkb0:
%MOUNT-I-MOUNTED, DSPS mounted on _$1$DKB0: (ENGZZD)
ENGZZD $ ana/disk dkb0:
Analyze/Disk_Structure for _$1$DKB0: started on 18-NOV-2010 11:10:31.89
%ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
-SYSTEM-W-NOSUCHFILE, no such file
ENGZZD $ dump /block=count=1 dkb0:
Dump of device DKB0: on 18-NOV-2010 11:17:26.64
Logical block number 0 (00000000), 512 (0200) bytes
03039401 001E65C0 11C00200 15C600A0 ..F...@.@e...... 000000
8BDFFF76 905F0000 000501FB 000609F7 w...{....._.v._. 000010
20202020 20205350 53440087 80FDFF74 t.}...DSPS 000020
73206120 746F6E20 73692020 20202020 is not a s 000030
0000000A 0A0D6B73 6964206D 65747379 ystem disk...... 000040
00000000 00000000 00000000 00000000 ................ 000050
00000000 00000000 00000000 00000000 ................ 000060
etc.
Any ideas/hints/suggestions gratefully accepted. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 01:00 PM
тАО11-22-2010 01:00 PM
Re: Missing '/foreign' labels on image backups
What does DUMP show when a disk is in the odd state? In particular, the field that normally contains the label.
Perhaps a reasonable workaround in your check would be to accept a null label, or look elsewhere on the disk.
For example, there are lots of alternate home blocks in the first few clusters of INDEXF.SYS - you should be able to find numerous copies of the volume label.
See DUMP/BLOCK=COUNT:10 dev:[000000]INDEXF.SYS
Surely they can't all have gone bad? Even if the device is mounted /FOREIGN, finding INDEXF.SYS isn't too difficult.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 01:02 PM
тАО11-22-2010 01:02 PM
Re: Missing '/foreign' labels on image backups
When/if you can get some documented information about the (mis)state of the disk, and the sequence of events leading up to it, please log a case with HP. They can't fix what they don't know about (there are only a few HP engineers who read ITRC - and responding to issues raised here is not in anyone's metrics).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 01:14 PM
тАО11-22-2010 01:14 PM
Re: Missing '/foreign' labels on image backups
A DUMP/ASCII/HEX of the primary and spare copies of the home block would be helpful.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 01:52 PM
тАО11-22-2010 01:52 PM
Re: Missing '/foreign' labels on image backups
From the DCL manual, under the MOUNT command...
"The volume-label parameter [2nd parameter] is not required when you mount a volume with the /FOREIGN or /NOLABEL qualifier or when you specify /OVERRIDE=IDENTIFICATION."
(Note that it doesn't say why it's not required.)
and later ...
"/FOREIGN
Indicates that the volume is not in the standard format used by the OpenVMS
operating system. Use the /FOREIGN qualifier when a magnetic tape volume is not in the standard ANSI format, or when a disk volume is not in Files-11 format. If you mount a volume with the /FOREIGN qualifier, the program you use to read the volume must be able to process the labels on the volume, if any."
(i.e. volume labels are not processed)
MOUNT/FOREIGN is used with BACKUP/IMAGE because you want the volume label to copied from the disk that you are backing up.
The fact that when you do a MOUNT/OVER=IDENT and the disk appears with the correct volume label looks to me as if it was saved on the disk but not accessed with the MOUNT/FOREIGN command.
Now I expect that someone will tell me that I'm wrong ...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 02:25 PM
тАО11-22-2010 02:25 PM
Re: Missing '/foreign' labels on image backups
>Now I expect that someone will tell me
>that I'm wrong ...
What you say is correct - you are not required to specify a volume label when mounting a volume /FOREIGN, or with /OVERRIDE=ID.
However, when you mount such a volume, I would expect the system to display the volume label it finds - see the example %MOUNT-I-MOUNTED messages in Ken's post. Indeed, mounting /FOREIGN is one way to determine an unknown volume label (which is what I believe Ken is depending on)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 04:12 PM
тАО11-22-2010 04:12 PM
Re: Missing '/foreign' labels on image backups
One thing I would try is to use
$ set volume/label=DSPSNEW $1$DKB0:
$ set volume/label=DSPS $1$DKB0:
It is possible that there is some "optimization" being done and the volume label isn't rewritten if it is the same as the present label. This seems to be the case on Alpha OpenVMS 8.3 with an ODS2 disk, it reads the home block but does not update it if the previous label was the same.
This still doesn't address the underlying problem, but it may be a work around that is less work than restoring a disk (if it works).
If you have LDDRIVER loaded, it would be interesting to see what LBNs are being accessed when the disk is mounted.. If you are going to try this, do it before attempting to change the volume label. This can be done by using the
$ set proc/priv=all
$ LD connect /replace $1$DKB0: LDA100:
$ LD trace LDA100:
$ mou/ov=id LDA100:
$ dism LDA100:
$ mou/for LDA100:
$ dism LDA100:
$ LD show/trace LDA100:
and see what blocks are being read.
Then to revert to normal access:
$ ! assumes already dismounted
$ LD notrace LDA100:
$ LD disconnect LDA100:
$ mou/ov=id $1$DKB0:
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 07:13 PM
тАО11-22-2010 07:13 PM
Re: Missing '/foreign' labels on image backups
I can reproduce on an Alpha with a disk initialized /GPT (and use of DISKBLOCK). Sorry, the following is a running commentary in chronological order, and I didn't discover the reproducer until near the end...
I don't have an IA64, but I am wondering if this behavior could be related to /GPT (which is the default on IA64, but not on other architectures). If you have a [000000]GPT.SYS file, your disks are initialized with the GPT overlays, and these are in the blocks normally occupied by the boot and primary home blocks.
With /GPT, there is no longer a primary homeblock. Perhaps the mount/foreign code doesn't use the same checks for the home block as the normal mount code does. I don't know what checks are made by the mount/foreign code for valid home blocks, but it may be finding what it considers to be a home block that really isn't one, and then the volume label wouldn't be correct. For example, if the mount/foreign code only check for valid checksums, a block of 0x00 bytes would pass the test. Perhaps the mount/foreign code is not using the same search sequence for home blocks as the normal mount code, or perhaps its checks are not as strict.
Here is a good way to get a formatted dump of the HOMEBLOCK of the disk.
ftp://ftp.hp.com/pub/openvms/freeware/diskblock/diskblock.zip
This is DISKBLOCK 6.2, and the kit will install on IA64.
Whoever created the zip file must not have preserved the vms file attributes, because the contents need to be
repaired.
You will need to do the following to "reconstitue" the vmsintal kit.
$ unzip diskblock
$ backup/list/repair diskblock062.a
$ backup/list/repair diskblock062.b
$ backup/list/repair diskblock062.c
$ backup/list/repair diskblock062.d
$ backup/list/repair diskblock062.e
Install diskblock, then do the following:
$ mount/for $1$dkb0:
$ mcr diskblock
DISKBLOCK> select $1$dkb0:
DISKBLOCK> read 1 ! primary homeblock (but will be bogus with /GPT)
DISKBLOCK> dump/home
See if the checksum if valid
DISKBLOCK> read 2 ! or what the Alternate Home LBN:
DISKBLOCK> dump/home
Well, it isn't too hard to reproduce the problem on an Alpha (as long as we are able to use DISKBLOCK to write to the disk).
My guess is that the EFI console is either writing to some block in the GPT and then mou/for is seeing this as a home block, or there may be left overs as described in Hoff's writup on OpenVMS Tips: EFI GPT Structures on ODS-2 and ODS-5 Disks
http://labs.hoffmanlabs.com/node/112
Here's what I did to reproduce the "effect" of having mou/ov find a label that mou/for does not. Note that this can be a serious problem if you are using shadowing, because the normal bladeguards in the SCB are bypassed (because the SCB can't be found if a valid homeblock is not found). For example if the disk is a member of a shadow set, and then the shadow set is dismounted or a member is dismounted, normally VMS will writelock this device when it is mounted without /shadow or /over=shadow. But that is not the case if a valid homeblock is not found.
$ init lda100: itrc01 /sys /own=[1,1] /cluster=1 /limit=10000 /gpt
At this point mount/for will find the label ITRC01.
However if we overwrite LBN 2 with all zeros (using DISKBLOCK), the volume will still mount correctly with mount/over=id, but will mount with no label displayed when mounted with mount/for. Also, if this volume is converted to a shadowset, it will not be protected against accidental write by mou/for.
See attachment for more details.
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 07:32 PM
тАО11-22-2010 07:32 PM
Re: Missing '/foreign' labels on image backups
By the way, changing the volume label won't help the problem, since the set volume/label updates the valid homeblocks, not the block that is being interpreted as a homeblock by mount/foreign.
Two possible work arounds that I can think of. If /GPT isn't needed the next time you got through the init, restore, do an init/nogpt.
The other is to try to determine what block is being interpreted incorrectly, and try to modify the block so the checksums are incorrect. But this may break something if the EFI is really using the block. The tool to modify the block is DISKBLOCK.
The real fix is for HP to make mount /foreign use the same search/checks for homeblocks as the normal mount code does, and issue a patch. Unfortunately they will probably only supply that patch to people with valid software contracts, even though it is not an enhancement, only a correct implementation of functionality.
Jon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-22-2010 07:51 PM
тАО11-22-2010 07:51 PM
Re: Missing '/foreign' labels on image backups
I just tried the following, but it does not work. So a non-image restore appears to be the only supported way to "cleanup"
$! following does not work!
$ init