> When saying something like that, it helps quite a lot of you can cite
> the actual CR number so that others can help either rescue the CR (if
> it's in need of rescue) or provide a more comprehensive explanation.
The CR is 681661
http://bugs.opensolaris.org/view_bug.do?bug_id=6811661
> In this case, though, I'll hazard a guess: everything related to the
> old 'vold' is gone. Just plain gone. Removed by PSARC/2005/672. It
> is no more. It is an ex-daemon. ;-}
>
> RFEs to it are moot. The Tamarack project is the replacement for it.
Fair enough. However, I do not administer the bug tracking system, but
would you not agree with me that whoever did administer it, should have
moved the CR into the appropriate category, or simply kept the CR open
until "Tamarack" was finished and then close the CR?
Instead, the proposed workaround is really, really lame.
It matters but little. Why should I (even though I do), as a consumer of
Solaris, care about internal processes over which I have no control?
I just want my removable ZFS pool to be automatically imported; whether
vold(1M) is not vold(1M) any more, and is now called "Tamarack" is in
reality all the same to me.
In this particular case, I needed to do some Oracle engineering, and was
stopped dead in my tracks by having to svcadm disable -t volfs; zpool import -a.
Is my time completely worthless? Should I have to worry about such details, or
should I be able to use Solaris to get work done, and get it done fast and
efficiently?
_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/
_______________________________________________
opensolaris-discuss mailing list
[email protected]
