Hi Jens, > > 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 ... >
messages from the underlying pkging commands are captured in the /var/sadm/patch/<PID>/log file messages from patchadd itself and patch level scripts (prepatch, postpatch, etc) go to stdout/stderr these are two distinct sets of messages -- not really optimal, just the way patchadd has always been > > 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. > nice trick, but unfortunately it won't do -- officially you must _never_ make such changes that alter the type of system files ; if you do, the changes are at your own risk and completely unsupported the basic reason for this patching can not be guaranteed behave in a deterministic manner when it encounters such changes -- this does cause real problems too, ie. a case where changing sendmail.cf to a symlink caused a kernel patch only half apply, leading to long term outages removing the old corrupt boot archive is a simple and safe way to free up some space, best part is on reboot the system will automatically rebuild it > > 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 ... hmm ... something of double edged sword, at least the way it works currently we know with certainty when there was a problem building the archive and can go about rectifying it ; the problem with keeping the old boot archive is that the system may have the appearance of booting and possibly even running ok, but there is absolutely no guarantee of nominal operation, could be very confusing > > 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 ... > yep - even better ! best, Ed -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
