On Sun, Nov 16, 2008 at 09:27:32AM -0800, Ed Clark wrote: Hi Ed, > > > 1. a copy of the 137137-09 patchadd log if you have > > http://iws.cs.uni-magdeburg.de/~elkner/137137-09/ > thanks for info - what you provided here is the patch pkg installation log,
Yes, actually the only one, I have/could find. > what i was actually after was patchadd log (ie. the messages output to > terminal) Up to now I thought, that stderr and stdout are redirected from patchadd to the patchlog, but never checked in detail, since the log always had the info I needed ... > -- 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 Haven't seen anything unusaly. But may be I've overseen it :( > 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 Yes - that makes sense. > 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 Yepp - now I can see the problem: Creating boot_archive for /a updating /a/platform/sun4u/boot_archive 15+0 records in 15+0 records out cat: write error: No space left on device bootadm: write to file failed: /a/boot/solaris/filestat.ramdisk.tmp: No space left on device So moving /etc/gconf to /opt and /etc/mail/cf to /usr/lib/mail (inkl. creating the appropriate links) was sufficient to get it work. > 6. ls -l platform/sun4u total 136770 -rw-r--r-- 1 root root 68716544 Nov 18 03:22 boot_archive -rw-r--r-- 1 root sys 71808 Oct 3 23:28 bootlst -rw-r--r-- 1 root sys 79976 Oct 3 23:34 cprboot drwxr-xr-x 11 root sys 512 Mar 19 2007 kernel drwxr-xr-x 4 root bin 512 Nov 12 22:17 lib drwxr-xr-x 2 root bin 512 Mar 19 2007 sbin -rw-r--r-- 1 root sys 1084048 Oct 3 23:28 wanboot Filesystem 1024-blocks Used Available Capacity Mounted on /dev/dsk/c0t0d0s0 245947 205343 16010 93% / > 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 Hmmm - may be I'm wrong, but IMHO if there is not enough space for a new boot_archive the "bootadm" should not corrupt anything but leave the old one in place - I would guess, in 95% of al cases one comes away with it, since very often updates are not really required ... > better option would be to reinstall the system, choosing a disk layout > adequate for newboot Well, the 2nd exercise is to test zfs boot (all systems have at least a 2nd HDD). If this works, just converting to zfs is probably the better option ... Anyway, thanks a lot for your help! Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss