- 论坛徽章:
- 0
|
吃惊：无法进入PROM模式
一部分问题的解决办法
Unmounting /vol error
This problem is caused by an error in one of the Solaris .rc files.
Jan 21 20:32:18 /usr/sbin/vold[418]: problem
unmounting /vol; Interrupted system call
The system attempts to unmount the /vol file system before shutting down the vold daemon which is using /vol. By trying to unmount a used file system, an error is created. The solution is to kill the daemon before unmounting the file system.
Killing the vold daemon first will fix the problem. You will have to become root first. Then create a link to an existing shutdown script before entering run level 0.
Become root and enter the following:
# ln -s /etc/init.d/volmgt /etc/rc0.d/K68volmgt
The /etc/rc0.d directory contains scripts that are executed when Solaris enters run level 0 (Shut Down). Solaris runs all scripts starting with K and passes them "stop" as a parameter. The volmgt script found in the /etc/init.d directory already uses this protocol and the above procedure will cause vold to shutdown properly.
--------------------------------------------------------------------------------
INIT: failed write of utmpx...
The error messages that is most frustrating, however, are this pair of messages. On some installations, We get these errors, and on other installations, We don’t.
INIT: f a i l e d o n w r i t e o f u t m p x entry:“sO”
INIT: f a i l e d o n w r i t e o f u t m p x entry:“fw”
For a long time, We’ve just been putting up with these error messages. It turns out that these messages occur for a similar reason as the previous error.
Here, the init command is trying to update the utmpx log file, which contains information about system run-level transitions, as well as user login and logout information. On some Solaris installations, the /var file system was on a separate partition!
When Solaris goes to run level 0, it un-mounts all the expendable file systems, such as /var. However, init then tries to enter this information in the log file, which is no longer accessible. That certainly clears things up!
Thus, all you do is provide a place for init to write your log file entries. If you really don’t care about the run-level transition messages, you can just write the information to/dev/null, and it’ll be thrown away without a trace. To do this, shut down your system and restart it. However, when you restart it, make sure you issue a boot -s command to boot it initially in single-user mode. Once you’ve booted up in single-user mode, enter these commands:
# umount /var
# mkdir /var/adm
# ln -s /dev/null /var/adm/utmpx
# ln -s /dev/null /var/adm/utmp
(If you try to bypass the boot -s step by executing the init S command to go to single-user mode, umount will tell you that the /var file system is busy. Don’t even try to circumvent the shutdown/boot -s procedure, it won’t work.)
Now we simply have a fake file system at the /var mount point. So when Solaris unmounts /var, the files /var/adm/utmpx and /var/adm/utmp will still exist. (They just won’t be the same ones.) Now, init won’t fail when it writes the log entries. You might wonder why we created both utmpx and utmp, when init was complaining only about utmpx. It turns out that if you create the utmpx file, init then complains about the utmp file. It writes log entries to both files, but writes to utmpx (and fails) first.
If you’d really rather keep all the log in-formation, you can try a similar trick. Instead of throwing away all the data, move your utmpx and utmp files to another location. Then create links to these new files at both their real locations and at the fake locations at the mount point. Then you can get rid of the messages and keep all your logging information. |
|
免费注册
发表于 2005-01-17 16:09
发表于 2005-01-17 16:14
