Since the root file system is a meagre 11GB, I figured I’d try and use my ZFS pool for installing Blastwave which is a system built on top of Solaris’ own packaging mechanism with access to lots of extra software that I can’t live without. Like
sudo for example, at least until I figure out how the Solaris native RBAC mechanism works! So, I did something along the lines of:
zfs create zpool1/software zfs create zpool1/software/blastwave zfs set mountpoint=/opt/csw zpool1/software/blastwave pkgadd -d http://www.blastwave.org/pkg_get.pkg
But I noticed that, at installation time, I was getting errors:
pkgadd: ERROR: unable to create package object </opt/csw/bin>. pathname does not exist pathname does not exist unable to fix attributes /opt/csw/bin
Looking at it now, in the cold light of morning, the answer might have been obvious. However, it took me a while last night to figure it out. Eventually, I compared the options the filesystems were mounted with, thinking that it might be missing a
exec flag and noticed that it was missing the
xattr flag. Hmm. “
xattr” and “unable to fix attribtues” sound like they might be a match, eh?
Digging around in the ZFS Administration Guide (I’ve got a PDF here, it’s page 19 if you’re following along at home), it appears that the
xattr property on ZFS filesystems – which enables extended attributes on a per-filesystem basis – was introduced in Nevada build 56 and doesn’t appear to be available in Solaris 10 U3. I am inferring from this information that ZFS in Solaris 10 U3 doesn’t actually support extended attributes.
Two questions I have at this stage:
Am I correct in my inference?
Does it matter, or can I just ignore those errors?
Update I’ve researched the matter more thoroughly and it turns out I’d jumped to completely the wrong conclusion. Read the next round of investigation at: Thumper: Debugging and not jumping to conclusions.