On 11/19/10 17:10, Dave Miner wrote:
60+ successful updates on this U24 says I'm just a really lucky guy :-)
Quite! Actually, AFAIK there are 3 scenarios 1) rpool/ROOT/be-name/opt mounted on /opt 2) Some other dataset mounted on /opt 3) /opt as a directory under /. It turned out that somehow we got to scenario 3 - somewhere in the last 172 days /opt got dismounted. I didn't know you could mount a dataset on a directory with stuff in it, but evidently you can... Anyway, after renaming /opt, mounting rpool/ROOT/be-name/opt on /opt and mv'ing the files, the image-update worked. If I have time I'll retry scenario 2, but my guess is that it would work since it seems to have worked so often for both of us in the past. On 11/19/10 16:59, Shawn Walker wrote:
As a result, I would strongly discourage against any setup that involves packages being split across multiple filesystems instead of a single '/' filesystem.
Hmm. That's the scenario that didn't work. AFAIT it seems that /opt /must/ be a dataset of its own - /opt seems to be a special case. On 11/19/10 15:00, Shawn Walker wrote:
If you import a second ZFS formatted disk with an existing rpool libbe gets very confused.
That's not good. IIRC there wasn't one imported, although there is a dataset containing a zfs recv'd x86 rpool that gets trashed whenever reboot does an update archive. I submitted a bug about that a long time ago and I don't think it was ever closed. Having that pool around doesn't seem to have prevented the image-update from completing, though. Anyway, b134b is installed! Thanks again for your help -- Frank [1] following the instructions to make a brand new root pool at http://docs.sun.com/app/docs/doc/819-5461/ghzvz?l=en&a=view _______________________________________________ pkg-discuss mailing list pkg-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
