On 8/31/06, Sarah Jelinek <Sarah.Jelinek at sun.com> wrote:
> Adrian Florea wrote:
> > I think is doing this because the / filesystem is
> > built on top of a metadevice (that is a mirror)
> > consisting of a single submirror (i.e. built on a
> > single slice).
> >
> Actually, the 1 way mirror shouldn't matter. A 1 way mirror is legal and
> should mount ok. My suggestion would be to try this using the
> underlying slice name, not the SVM metadevice name. Could be a problem
> with SVM for some reason. If it works when you specify the underlying
> slice name then we can start to debug this with the SVM folks.
However, if you create boot environments using underlying slices then
mirror you can get into ugly situations as you use luactivate to move
between boot environments. That is, if luactivate and the reboot
processing only mount and modify one side of the mirror, SVM doesn't
pick up on this (no sync after boot). I am almost 100% sure that the
modification of one half of the mirror has been the source of several
panics in my (sparc) environment. (These improper updates could be
happening from maintenance activities performed while booted from the
network or via luactivate.)
I have fought similar problems with live upgrade's handling of
metadevices when I really want to do the following
# lucreate -s - -n newbe -m /:d30:ufs,preserve
# luupgrade -f -n newbe -s $osmedia -J 'archive_location nfs://somewhere'
# luactivate newbe
# init 6
However, that always errors out because the profile that is passed to
pfinstall is created improperly. To work around this, I have done the
following:
# cp $osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall \
/var/tmp/pfinstall.orig
# mount -F lofs -O /dir/pfinstall-wrapper \
$osmedia/Solaris_10/Tools/Boot/usr/sbin/install.d/pfinstall
My custom pfinstall-wrapper transforms the profile properly to create
proper lines for metadevices.
This improper handling of metadevices has caused the following in my
environment (V240's - 25k's).
1) Do not use live upgrade
2) Use live upgrade with the unsupported workaround I suggest above.
3) Use live upgrade referring to slices which subsequently get
mirrored and lead to FS corruption that causes instability.
4) Use live upgrade referring to slices then perform the unsupported
step of modifying /etc/lutab and/or /etc/lu/ICF.*.
Notice that options 1 (don't use the feature) and 3 (introduce
corruption and/or instability) are the supported routes.
I *so* wish that live upgrade was a candidate for being open sourced.
Raising this problem through support channels and complaining on
public mailing lists has so far gotten nowhere.
Mike
--
Mike Gerdts
http://mgerdts.blogspot.com/
