On Tue, Nov 18, 2008 at 07:44:56PM -0800, Ed Clark wrote: Hi Ed, > 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 - thanks for making that clear. > > 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 Yes, considering it for a temp. change, only. However pkgtools are usually robust enough (as long as the dir is not empty) to handle such relocations properly - that's why I really like pkgtools (giving me the freedom I need ;-)). > 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 Oops - that's a big bummer [OT: and probably the result of the bad packaging strategy of solaris (i.e. not software oriented aka merging different sw into one sol package ...)]. Good to know, that this already happend... > 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 Yes, I understand your point of view. However, I didn't mean, silently ignore the "unable to update boot archive" but giving the user a simple way to fix the problem. So I would prefer the "keep the old archive as long as it can not be updated, but issue big warnings on reboot/activation to get informed, that a fix is needed". At least in my case the system would have been "offline" for at most 30min, but because of the bug it was several days offline and without your help probably several weeks/months (i.e. my experience wrt. german sun support) ... Anyway, thanks a lot again, 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
