We recently re-imaged a fileserver (Solaris 9). For every slice of our old /vicep data, we are getting the following error at boot time. Here's one example:
# /usr/lib/fs/afs/fsck -o b=512272 /dev/dsk/c3t6006016012341600D86B14C 7E294DA11d0s0 ----Open AFS (R) openafs 1.4.6 fsck---- Alternate super block location: 0 ** /dev/dsk/c3t6006016012341600D86B14C7E294DA11d0s0 BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE USE AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; eg. fsck [-F ufs] -o b=# [special ...] where # is the alternate super block. SEE fsck_ufs(1M).
No matter what superblock alternate is specified... same error. The /usr/afs portion was selectively copied from another fileserver of the same architecture after the host in question was reimaged (no sysid, no logs, no fssync.sock, no salvage.lock). The fun part is, the partitions get mounted just fine and everything is peachy. Lucky for us. Has anyone seen anything like this before? We'd certainly like to get it straightened out sooner than later.
bash-2.05# cd /usr/lib/fs/afs bash-2.05# ls clri@ fsck.transarc* lockfs@ quot@ tunefs@ df@ fsdb@ mkfs@ quota@ ufsdump@ edquota@ fsirand@ mount@ quotaoff@ ufsrestore@ ff@ fstyp@ ncheck@ quotaon@ volcopy@ fsck* labelit@ newfs@ repquota@ bash-2.05# bash-2.05# grep afs /etc/dfs/fstypes afs AFS Utilities bash-2.05#
_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
