/stand/vmunix not found!

[ckchoi]

Dear,

When I tried to list the file in the /stand directory, the following appears:

/stand/system not found
/stand/build not found
/stand/vmunix not found
/stand/vmunix.prev not found
total 30
-rw-r--r-- 1 root sys 191 Jun 10 1996 bootconf
-rw-r--r-- 1 root root 2868 Apr 13 15:46 ioconfig
-r--r--r-- 1 root sys 82 Jun 10 1996 kernrel
drwxr-xr-x 2 root root 8192 Jun 10 1996 lost+found
-rw------- 1 root root 12 Apr 18 12:19 rootconf
-rw-r--r-- 1 root sys 726 Oct 23 2002 system.prev

Are there any ways to solve the problem?

Thanks.

[A. Clay Stephenson]

If you have a backup of /stand, now would be an extremely good time to restore --- and whatever you do, don't reboot before you get a /stand/vmunix on the box.

[ckchoi]

Thanks for your reply.

In fact, I can boot the machine without problem (why?). But alter the config using SAM is disallowed because /stand/vmunix is not found.

[yunardi]

Hi ckchoi,

I have same problem a few weeks ago, files on /stand is missing dna when using SAM there is error that says /stand is missing.

Fortunately i have ignite of the machine and thend restore /stand from ignite.

The machine runs normally.

You should try this if you have ignite.

Thanks,

[ckchoi]

Thanks for your reply.

Could you find out the reason why the files were disappered?

[hunter29]

As far as how the files disappeared, may be due to some bad kernel build, can you check your syslog files whether its generating some DLKM errors or not? If yes then you have to rebuild the kernel from scratch

[Raj D.]

ckchoi ,

Can you try if you have another copy , of vmunix somewhere else that the system is booting up from.

# find / -name vmunix -print


Cheers,
Raj.

[ckchoi]

Thanks for your reply.

I can't find any DLKM error in syslog. Everything seems normal during reboot. Also, I have tried to issue the "find / -name vmunix -print" command. The output is only as follows:

find: cannot stat /stand/system
find: cannot stat /stand/build
find: cannot stat /stand/vmunix
find: cannot stat /stand/vmunix.prev

It seems that I can't find a copy of vmunix. That's why I wonder how can I reboot the machine successfully.

[Devender Khatana]

Hi,

This seems a very strange problem. And as the output from find and ls in /stand states that the files are there but are in some sort of corruption.

Booting of the system normally means that the file is visible during boot and is not visible through ls and find. You can also try "ls -b" in /stand directory.

Do umount /stand and try to run full fsck and see if it recovers some files.

I would try to take a ignite first and then do a fsck on /stand to see if it gives some errors.

Caution - As the inconsistency is there in /stand doing all this can make your system unbootable and you may be required to recover OS from the scratch.

HTH,
Devender

[hunter29]

Check the AUTO file to know where the kernel is located. For that you have to do the following steps:
1) Check the boot disk with lvlnboot -l
2) After that, lifls -l /dev/rdsk/ eg: /dev/rdsk/c0t6d0
3) Check whether there's a AUTO file there.
4) If present, then lifcp /dev/rdsk/c0t6d0:AUTO /tmp/auto
5) Then check the content of /tmp/auto file, this will show you the kernel path from where its booting.

[Devender Khatana]

Hi,

The following link describes the "can not stat" problems in find fixed by fsck. You can give it a try.

http://www.sunmanagers.org/archives/1996/0126.html

HTH,
Devender

[ckchoi]

I found that the boot path is "hpux". Does it mean default path?

[Bill Hassell]

The first listing provides the best explanation. An ll command fails with the erroro message:

/stand/system not found

Now that's curious. If the file is not there, how would ll know to report it missing? The find command also provides insight: cannot stat which means that the directory does have an entry but when probing for information from the inode, there is a problem. That's why the system will boot -- /stamd/vmunix does exist but the inode has some corruption. Use fsck on the filesystem. Note that fsck has very different options for HFS versus VxFS. Do this:

umount /stand
fsck -p /dev/vg00/rlvol1

(I am assuming that /stand is /dev/vg00/rlvol1) That should either fix the problem or report errors. Now if the rest of the system seems to be OK, I wouldn't worry about using Ignite since this is apparently simple corruption of the /stand filesystem. If it can't be fixed with fsck, then you can backuup what is left on /stand, umount the filesystem, use newfs to erase the corrupt data and create an empty filesystem. NOTE: Use the -F hfs option because /stand cannot be VxFS, it must be HFS. Then restore just /stand from your latest backup. And if there are any changes since the last backup, restore the /stand backup that you made.

You should now have a visible vmunix file.

[ckchoi]

Thanks for your reply in detail.

I typed "fsck -p /dev/vg00/rlvol1" after umount /stand and the following messages appeared:

/dev/vg00/rlvol1: CANNOT READ: BLK 2520
/dev/vg00/rlvol1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

So, I tried "fsck -F hfs /dev/vg00/rlvol1", the following messages appeared:

** /dev/vg00/rlvol1
** Last Mounted on /stand
** Phase 1 - Check Blocks and Sizes

CANNOT READ: BLK 2520
CONTINUE? y


CANNOT READ: BLK 2520
CONTINUE? y


CANNOT READ: BLK 2520
CONTINUE? y

FAILED READ OF BLOCK #2520, RETRIED 2 TIMES
** Phase 2 - Check Pathnames
UNALLOCATED I=387
Could not getinode(387) in pinode.
NAME=/system

REMOVE? n

UNALLOCATED I=384
Could not getinode(384) in pinode.
NAME=/build

REMOVE? n

UNALLOCATED I=426
Could not getinode(426) in pinode.
NAME=/vmunix

REMOVE? n

UNALLOCATED I=429
Could not getinode(429) in pinode.
NAME=/vmunix.prev

REMOVE? n

** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
LINK COUNT DIR I=2
OWNER=bin MODE=40555
SIZE=1024 MTIME=Oct 23 17:42 2002 COUNT 4 SHOULD BE 3
ADJUST? n

FREE INODE COUNT WRONG IN SUPERBLK
FIX? n

** Phase 5 - Check Cyl groups
13872 BLK(S) MISSING
BAD CYLINDER GROUPS
FIX? n

7 files, 0 icont, 16 used, 65813 free (21 frags, 8224 blocks)
DISK MEDIA PROBLEMS ENCOUNTERED!
BAD BLOCKS WERE FOUND ON THE DISK.
***** FILE SYSTEM IS NOT CLEAN -- DISK MEDIA PROBLEMS ENCOUNTERED *****

I suspected that the problem is caused by bad sectors of the disk. Am I right?

[Devender Khatana]

Hi,

Your assumption is correct and this indeed is a problem caused due to bad sectors. You can run a read test on the disk device belonging to root and it should report the same errors.

#dd if=/dev/rdsk/cxtydx of=/dev/null bs=1024k

Where /dev/rdsk/cxtydz is the disk device file.

HTH,
Devender