Red faces all round, but we are not quite sure why ...
Can anyone explain
a) how we got into this mess;
b) how we get out of (the last bit of) it?
Scenario:
Starting from - old E450, Solaris 2.6, some internal disks
Plan - wipe out, install Solaris 8, add D1000 discs, VxVM 3.2
But - D1000 and VxVM license hadn't arrived, time running out
So - installed Solaris 8, Oracle etc on internal disks (leaving
partitions and space free so that we can encapsulate
later, move volumes to D1000, grow filesystems)
Finally - D1000 arrived and attached
VxVM license arrived
So far, so good. Now things start to go pear-shaped.
Installed VxVM 3.2 packages. Ran vxinstall, several false starts for
various reasons, did not run to completion (but clean quit in all cases)
Pointed out that patch 111909-04 hadn't been installed :-(
Installed patch, did _not_ reboot ("there won't be any VxVM stuff running,
so no need." Hmmm...)
Ran vxinstall again, encapsulated root disk, left all others out.
Rebooted. All ok, except that volumes had usetype gen rather than fsgen.
The significance of this did not register. Hmmm....
Initialised second internal disk into rootdg, encapsulated remaining
internal disks into oradg, initialised new D1000 disks into oradg.
Rebooted. All ok, except that all the new Oracle volumes are also gen
rather than fsgen. Again, the significance of this did not register.
Moved/mirrored/striped/etc off the internal disks onto the D1000. No
problem.
Tried to grow one of the volumes (via vmsa). Various moans about not being
able to grow usetype=gen volumes. At which point we stopped to think ;-)
Now, the patch description for 111909-04 includes
(76498) USETYPE of var,usr,opt changed to gen in vxvm 3.1.1p2 after
using vxinstall to encapsulate the boot disk
I'm half-prepared to believe that some combination of half-running
vxinstall before applying the patch, and/or not reloading after applying
it, is responsible for those volumes being of type gen rather than fsgen.
Would I be right?
What I can't understand is why the disks encapsulated _after_ applying and
reloading should also be wrong. Any suggestions?
Having got this far, we have tried to go forward rather than back....
We have mirrored and re-mirrored the root disk using the "Trentham"
method, so it is no longer encapsulated.
To sort out the problematic volumes, we have been following the procedure
in TechNote 233251 "How to change a volume usage type from gen to fsgen".
We have successfully done all the volumes except var, which we haven't yet
tried, through sheer cowardice....
The procedure requires the filesystem to be unmounted and the volume to be
stopped. Is this possible with var? (boot -s results in /var being
mounted) If not, how can we fix it? Or can't we?
TIA,
Richard Hall
|