在v880上安装sun patch引起的启动故障及解决
今天按客户需求给一台v880(Solaris8系统)打patch.直接使用EIS光盘中Solaris8的补丁集合包,打完patch后 系统重启. 问题来了重起时提示如下信息:
ebooting with command: boot
Boot device: /pci@8,600000/SUNW,qlc@2/fp@0,0/disk@w21000004cf7f200f,0:aFile and args:
|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/
SunOS Release 5.8 Version Generic_117350-47 64-bit
Copyright 1983-2003 Sun Microsystems, Inc.All rights reserved.
-\|/-\|/
panic/thread=10408000: mod_hold_stub: Couldn't load stub module sched/TS_DPTBL
0000000010406ed0 genunix:mod_hold_stub+1a8 (1, 2050, 10412780, 10412770, 300000cfd08, 60)
%l0-3: 0000000000105ab8 ffffffffffffe000 00000000104544e0 0000000000006000
%l4-7: 0000030ffffee498 0000000000000000 0000000000006000 0000000010454500
0000000010406f80 unix:stubs_common_code+30 (0, 1047b278, 2050, d, 149f40, 14c050)
%l0-3: 000003000016c000 0000000000000000 0000000000000000 000000001044bfd8
%l4-7: 00000000000000b0 0000000010412780 0000030000114e28 000003000010cf40
0000000010407030 TS:ts_init+4 (1, 8, 10410598, 10407244, 1047b278, 60)
%l0-3: 000000001047b400 fffffffffffffff8 0000030000114000 000000000000095f
%l4-7: 0000030fffff0888 0000000000000000 0000000000000016 0000000000000001
00000000104070e0 unix:disp_add+58 (10410588, 1041bb48, 1041d570, 63, 1046a1e8, 0)
当时一个汗啊.客户的应用系统在上面.....
后在sunsolve上查到该故障原因和解决方法.这该死的Sun的bug
After installing the Solaris 7 or Solaris 8 patch cluster, the system panics with a string similar to:
panic/thread 0x1048000: mod_hold_stub Couldn't load stub module sched/TS_L
or...
panic/thread=10404000: mod_hold_stub: Couldn't load stub module sched/TS_DPTBL
This error occurs because the work around for Sun alert 49131 was not undone before applying kernel patches. According to the alert, the work around must be reversed before applying the patch.
ResolutionTop
From Sun Alert 49131: If the CERT workaround (VU#683673) was used, the following should have been performed before any Kernel patch was installed:
# for dir in /kernel /usr/kernel
> do
> cd $dir
> rm sched # remove symlink
> mv a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/sched .
> rm -fr a
> done
The bug 4708822 (security exploit) was fixed in 108528-18 and does not need to be re-implemented. Now the system needs to be restored to a bootable state (if indeed the special instructions for the CERT advisory were not followed).
Insert Solaris 7 or 8 Software CD 1 of 2 into drive.
ok boot cdrom -s
# fsck /dev/rdsk/c0t0d0s0 (example root filesystem)
# mount /dev/dsk/c0t0d0s0 /a
# cd /a/kernel
# ls -al|grep sched
lrwxrwxrwx 1 root other 37 Apr 10 10:29 sched -> a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/sched
Here you can verify that sched is still linked, and the old sched needs to be moved back. This is similar to the steps above from the CERT advisory:
# for dir in /a/kernel /a/usr/kernel
> do
> cd $dir
> rm sched (remove symlink)
> mv a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/sched .
> rm -fr a
> done
Or you can just do it manually:
# rm /a/kernel/sched
# rm /a/usr/kernel/sched
# mv /a/kernel/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/sched /a/kernel
# mv /a/usr/kernel/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/sched /a/usr/kernel
Once this is done sched should look normal once again:
# cd /a/kernel
# ls -al|grep sched
drwxr-xr-x 3 root sys 512 Apr 17 08:14 sched
You should be able to boot the system again at this point.
# cd; umount /a
# init 6
------------
特此分享.希望大家小心啊 鼓励一下，希望经验多多发表。 好。多谢分享 好同志 谢谢楼主分享，请问楼主用的是哪个版本的EIS，最新的？
The bug 4708822 (security exploit) was fixed in 108528-18 ，，108528-18之后就修复这个bug啦？ xiexie,wo 我最近有饿 一样d的问题出现啦
页:
[1]