Chris's Wiki :: blog/solaris/OmniOSOptCaution Commentshttps://utcc.utoronto.ca/~cks/space/blog/solaris/OmniOSOptCaution?atomcommentsDWiki2015-04-23T05:09:39ZRecent comments in Chris's Wiki :: blog/solaris/OmniOSOptCaution.By Chris Siebenmann on /blog/solaris/OmniOSOptCautiontag:CSpace:blog/solaris/OmniOSOptCaution:b2c9c51677ba0bfba809b76537326cdec4d6b9b6Chris Siebenmann<div class="wikitext"><p>I wasn't clear in my brief description. The problem is not that the new BE
has <code>/opt</code> mounted but that it doesn't, and the BE needs <code>/opt</code> mounted
in order to successfully update package with files in <code>/opt</code>. If you
'fix' the now-missing package files in a BE that lacks a mounted <code>/opt</code>,
the upgrade will work but ZFS will refuse to mount your real <code>/opt</code> when
you boot into the BE because the <code>/opt</code> directory on the root filesystem
has contents (namely those packages that got repaired in it).</p>
</div>2015-04-23T05:09:39ZBy lotheac on /blog/solaris/OmniOSOptCautiontag:CSpace:blog/solaris/OmniOSOptCaution:3d507311474092dbb3d1a38b8b5db0cbdab72e82lotheac<div class="wikitext"><blockquote><p>(Our solution is to abandon plans to upgrade machines from r151010 to r151014. We'll reinstall from scratch and this time we'll make the largest single piece of /opt into a filesystem instead.)</p>
</blockquote>
<p>I don't think you need to reinstall for this if your problem is having packages installed in /opt. I would use beadm to create and mount a new BE, making sure not to mount the /opt fs under it, and then run 'pkg -R $mntpnt fix' to create the missing files and 'pkg -R $mntpnt update' to upgrade afterwards.</p>
</div>2015-04-22T07:06:16Z