Hi, > > > > 1. a copy of the 137137-09 patchadd log if you have > one available > > cp it to > http://iws.cs.uni-magdeburg.de/~elkner/137137-09/ > Can't spot anything unusual. >
thanks for info - what you provided here is the patch pkg installation log, what i was actually after was patchadd log (ie. the messages output to terminal) -- both the patchadd log and the console log on reboot should have shown errors which would have provided hints as to what the problem was > 2. an indication of anything particular about the > system configuration, ie. mirrored root > > No mirrors/raid: > > # format > Searching for disks...done > > > AVAILABLE DISK SELECTIONS: > 0. c0t0d0 <FUJITSU-MAN3367MC-0109 cyl 24343 > alt 2 hd 4 sec 737> > /[EMAIL PROTECTED],600000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 > c0t1d0 <SEAGATE-ST336737LC-0102 cyl 29773 alt 2 hd 4 > sec 606> > /[EMAIL PROTECTED],600000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 > c0t2d0 <FUJITSU-MAT3073N SUN72G-0602-68.37GB> > /[EMAIL PROTECTED],600000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 > c0t3d0 <FUJITSU-MAT3073N SUN72G-0602-68.37GB> > /[EMAIL PROTECTED],600000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 > put from the following commands run against root fs > where 137137-09 was applied > > > > ls -l usr/platform/sun4u/lib/fs/*/bootblk > > ls -l platform/sun4u/lib/fs/*/bootblk > > sum usr/platform/sun4u/lib/fs/*/bootblk > > sum platform/sun4u/lib/fs/*/bootblk > > dd if=/dev/rdsk/<rootdsk> of=/tmp/bb bs=1b iseek=1 > count=15 > > cmp /tmp/bb usr/platform/sun4u/lib/fs/ufs/bootblk > > cmp /tmp/bb platform/sun4u/lib/fs/ufs/bootblk > > prtvtoc /dev/rdsk/<rootdsk> > > also cp to > http://iws.cs.uni-magdeburg.de/~elkner/137137-09/ > Seems to be ok, too. > now the df/prtvtoc output was most useful : 137137-09 delivers sparc newboot, and the problem here appears to be that a root fs slice of 256M falls well below the minimum required size required for sparc newboot to operate nominally -- due to the lack of space in /, i suspect that 137137-09 postpatch failed to copy the ~180MB failsafe archive (/platform/sun4u/failsafe) to your system, and that the ~80M boot archive (/platform/sun4u/boot_archive) was not created correctly on the reboot after applying 137137-09 the 'seek failed' error message you see on boot is coming from the ufs bootblk fcode, which i suspect is due to not being able load the corrupt boot_archive you should be able to get your system to boot by doing the following 1. net/CD/DVD boot the system using a recent update release, u5/u6 should work, not sure about u4 or earlier 2. mount the root fs slice, cd to <root-fs-mount-point> 3. ls -l platform/sun4u 4. rm -f platform/sun4u/boot_archive 5. sbin/bootadm -a update_all 6. ls -l platform/sun4u the boot_archive file should build successfully, and you should see something like the following # ls -la platform/sun4u total 168008 drwxr-xr-x 4 root sys 512 Nov 16 07:36 . drwxr-xr-x 40 root sys 1536 Nov 16 05:36 .. -rw-r--r-- 1 root root 84787200 Nov 16 07:36 boot_archive -rw-r--r-- 1 root sys 71808 Oct 3 14:28 bootlst drwxr-xr-x 9 root sys 512 Nov 16 05:10 kernel drwxr-xr-x 4 root bin 512 Nov 16 05:36 lib -rw-r--r-- 1 root sys 1084048 Oct 3 14:28 wanboot # boot_archive corruption will be a recurrent problem on your configuration, every time the system determines that boot_archive needs to be rebuilt on reboot -- a very inelegant workaround would be to 'rm -f /platform/sun4u/boot_archive' every time before rebooting the system better option would be to reinstall the system, choosing a disk layout adequate for newboot hth, Ed -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
