Need Help Live Upgrade and ZFS Issues

[Paul Vanderhoof]

Need Help: Reverted to old BE with older version of ZFS cannot mount
rpool root or get back to new BE

Solaris 10 u9 on sparc v490. 3 non-global zones. I did the
following: I used Live Upgrade method to install latest 10_recommended
which worked

with no errors. Rebooted into the new BE with no apparent problems.
ZFS tools reported that my disk format was now outdated ZFS version,
so I

ran zpool upgrade rpool; zpool upgrade dpool. No errors. Now my ZFS
disk format is ZFS version 29.

In the porcess of troubleshooting a strange error that surfaced with
regard to zones -- zoneadm and zlogin both fail with <segmentatin
fault> core -- I

decided to revert back to the original BE with the luactivate
command. Rebooted and mout reboot fails with panic as the system
cannot mount root --

rpool -- because the original BE is still at an earlier ZFS version
and not comapatible with the newer ZFS version 29 on disk format.

NOTICE: zfs_parse_bootfs: error 48
Cannot mount root on rpool/51 fstype zfs
panic[cpu2]/thread=180e000: vfs_mountroot: cannot mount root

Obtained the latest Sol10-u10 iso and burned DVD and rebooted cdrom
which works then tried to implement the Solaris instructions for
reverting

back to the previous BE in the advent that your patched BE fails or
has serious problems. Did a zpool import rpool and basically the
following:

**********************************************************************

The target boot environment has been activated. It will be used when
you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands.
You
MUST USE either the init or the shutdown command when you reboot. If
you
do not use either init or shutdown, the system will not boot using the
target BE.

**********************************************************************

In case of a failure while booting to the target BE, the following
process
needs to be followed to fallback to the currently working boot
environment:

1. Enter the PROM monitor (ok prompt).

2. Boot the machine to Single User mode using a different boot device
(like the Solaris Install CD or Network). Examples:

At the PROM monitor (ok prompt):
For boot to Solaris CD: boot cdrom -s
For boot to network: boot net -s

3. Mount the Current boot environment root slice to some directory
(like
/mnt). You can use the following commands in sequence to mount the BE:

zpool import rpool
zfs inherit -r mountpoint rpool/ROOT/sol25Q10u9-patch-May12
zfs set mountpoint=<mountpointName> rpool/ROOT/sol25Q10u9-patch-
May12
zfs mount rpool/ROOT/sol25Q10u9-patch-May12

4. Run <luactivate> utility with out any arguments from the Parent
boot
environment root slice, as shown below:

<mountpointName>/sbin/luactivate

5. luactivate, activates the previous working boot environment and
indicates the result.

6. Exit Single User mode and reboot the machine.

**********************************************************************

Modifying boot archive service
Activation of boot environment <sol25Q10u9-baseline> successful.

*********************************************************************************

So one issue here is that in fact I do not want to activate the boot
environment <sol25Q10u9-baseline> but the NEW BE sol25Q10u9-patch-
May12

and then proceed to work out my zone issues. Alternatively I need to
figure out how to upgrade the original BE to the new ZFS version
without being

able to boot it.

When I did the zpool import and tried to run luactivate or lustatus:

# /mnt/sbin/luactivate
luactivate: ERROR: Live Upgrade not installed properly (/etc/default/
lu not found).
# cd /
# /mnt/sbin/luactivate
luactivate: ERROR: Live Upgrade not installed properly (/etc/default/
lu not found).
# lustatus
lustatus: not found
# /mnt/sbin/lustatus
/mnt/sbin/lustatus: not found

Also tried:


# chroot /mnt /sbin/luactivate sol25Q10u9-patch-May12
df: Could not find mount point for /
ERROR: Unable to determine major and minor device numbers for boot
device </dev/dsk/c3t0d0s0>.
ERROR: Unable to determine the configuration of the current boot
environment <sol25Q10u9-patch-May12>.

[Casper H.S. Dik]

Paul Vanderhoof <swing...@gmail.com> writes:

>ran zpool upgrade rpool; zpool upgrade dpool. No errors. Now my ZFS
>disk format is ZFS version 29.

Unfortunately, zfs upgrade is a one way step. After doing so, you
cannot boot older BEs.

Casper

[John D Groenveld]

[cross-posted to comp.sys.sun.admin]
In article <b9ed635d-cc80-48da...@p1g2000vbv.googlegroups.com>,

Paul Vanderhoof <swing...@gmail.com> wrote:
># chroot /mnt /sbin/luactivate sol25Q10u9-patch-May12
>df: Could not find mount point for /
>ERROR: Unable to determine major and minor device numbers for boot
>device </dev/dsk/c3t0d0s0>.
>ERROR: Unable to determine the configuration of the current boot
>environment <sol25Q10u9-patch-May12>.

That looks like a potential RFE: S10's lu(1M) and friends should
be able to work against a client root path.

Let us know how Oracle Support helps you rescue your patched S10
BE from the latest installation media.

John
groe...@acm.org

[cindy]

I'm not sure how much progress you have made on unraveling this
problem, but
here are some ideas:

1. You need to find out the reason why your zones are unhappy. LU
supports a limited
set of zone configurations, that are described here.

http://docs.oracle.com/cd/E23823_01/html/819-5461/ggpdm.html#gigek

My concern is that if your zone config isn't supported by LU, you
usually know during
the LU phase, not by zone login core dumps post LU. I've never seen
this one so
I would make sure your zones are operational prior to LU.

An upcoming Solaris 10 release includes an LU pre-flight checker that
will help
determine whether your zones are supported. A workaround is to detach
your zones
before the LU and then reattach them after the LU. I haven't tried
this myself.

2. The on-screen LU recovery steps don't work based on a discussion on
this group
and I filed a CR that is fixed in an upcoming Solaris 10 release.

3. I hope you can start over at a good known state. If that's not an
option, then
you could recreate a root pool at the version you need by using the
version option when
the new root pool is created. Then, point LU at the new pool.

These steps are documented in the above pointer.

4. You should be able to import your existing root pool from the
matching media version
and mount the root BE. You can't run the LU suite of commands in an
alternate boot mode.

Thanks,

Cindy

[Paul Vanderhoof]

Thanks for your help and reply. I will read the link you posted.
Here is what I have managed since posting.

From tip from another list, I was able to use boot -L (and
subsequently boot -Z) from >ok to see and choose the BE I wanted to
boot into. Chose the newest patched BE with kernel support for the
correct version of ZFS. This worked and I was able to boot the system
and mount my ZFS file systems. Zones auto started and were running but
I still had the segmentation fault / core dump from the zoneadm and
zlogin commands. Other weirdness was apparent, and also very
surprising, found LU had moved my zone dirs from /export/zones to /
zoneds and changed the zone config.to match the new path. Old zone
path / dirs still there, but renamed to something_oldBE_name. I
checked lustatus and it tells me that me old original, un patched BE
is the active BE. I ran luactivate and set the active BE to the new
patched BE and that succeeded with no errors and lustatus confirmed.
When I tried to shutdown init 6 reboot I was right back to were I
started with error 48 and impossible to mount file systems. Used boot
-Z new_BE again and booted back into my new_BE with all ZFS file
systems mounted. Decided to try to lucreate a new BE named new_BE_cpy
which succeeded and then luativate to that, which succeeded. The
logic of this was that if successful this process might fix / rewrite
the boot config / information that was screwed up and kept giving me
the same error 48 (bad ZFS version). Again rebooted and this time
booted successfully without error into the newly created BE. zoneadm
list works, now segmentation fault / core dump, but revealed no non-
global (sparse) zones running. Attempted zoneadm -z my_zone1 boot and
this fails with errors. I rechecked the zone config to verify the
path and then checked to see that the path was valid, existed, and
that my zones were actually there. Found that /zoneds was still
there, but no zone dirs or files / data, etc was there (it was there
under the new_BE). Now perplexed as to the next step. Researching if
I can A) copy zone dirs / data / files from the original BE location /
export/zones (which still exists or B) use a some kind of zone export
command (but current working BE shows no zone dirs / data / files or
running zones C) some other method (tape restore) to get my zones dir /
data /files into /zoneds location and then D) patch separately the
zones using the patchadd or the 10_recommended install script in some
manner that I am not presently sure of the correct syntax or E)
somehow patch the original, old BE (lumake? run 10_recommended install
script or PCA to alternate root after lumounting old BE?) and patch
the zones under the old_BE and attempt to luactivate that and if all
is normal then delete the other new_BE (keep my new_BE_cpy just in
case)

Ok -- so this is where I am at. Current BE seems normal and working
but my zones are broken. It looks like I can live comfortably with
the new_BE_cpy if I can get my zones back / running without any errors
or errors from zoneadm and zlogin, etc commands -- but how exactly.

Thanks

Paul

[cindy]

Hi Paul,

I can't follow everything in description above, but a couple of
comments:

1. LU inserts the zone zoneds file system names when needed so it
can support your zones. If you remove them, they will break LU.

2. The boot -L allows you to select the BE to from but it does not
activate
the BE for you. You would still need to luactivate the working BE.

3. I think you would benefit from reviewing the doc pointer I
provided.
My opinion is that stuff should work without having to read the docs
and I write
docs for a living, but for LU + zones, its a must.

4. I see we are offering a zones pre-flight checker for migration
purposes.
I'm hoping you can download this script and it will tell you what's
wrong with your
zones.

https://blogs.oracle.com/listey/entry/oracle_solaris_zones_preflight_system

Thanks,

Cindy

[John D Groenveld]

In article <4066b68e-4017-4dd6...@3g2000vbx.googlegroups.com>,

Paul Vanderhoof <swing...@gmail.com> wrote:
>Ok -- so this is where I am at. Current BE seems normal and working
>but my zones are broken. It looks like I can live comfortably with
>the new_BE_cpy if I can get my zones back / running without any errors
>or errors from zoneadm and zlogin, etc commands -- but how exactly.

What does Martin Paul's PCA report as missing patches in your current
working BE?

John
groe...@acm.org

[John D Groenveld]

In article <4066b68e-4017-4dd6...@3g2000vbx.googlegroups.com>,
Paul Vanderhoof <swing...@gmail.com> wrote:

>boot into. Chose the newest patched BE with kernel support for the
>correct version of ZFS. This worked and I was able to boot the system
>and mount my ZFS file systems. Zones auto started and were running but
>I still had the segmentation fault / core dump from the zoneadm and
>zlogin commands. Other weirdness was apparent, and also very
>surprising, found LU had moved my zone dirs from /export/zones to /
>zoneds and changed the zone config.to match the new path. Old zone

What is your ZFS and zone configurations?
# zpool list
# zfs list
# mount
# zoneadm list -cv
# for zone in `zoneadm list -p | awk -F: '{print $2}' | grep -v global`
> do
> echo "# $zone"
> zonecfg -z $zone export
> done


John
groe...@acm.org

[Paul Vanderhoof]

On May 22, 12:20 pm, groen...@cse.psu.edu (John D Groenveld) wrote:
> In article <4066b68e-4017-4dd6-a2e7-8f0f537d5...@3g2000vbx.googlegroups.com>,

> Paul Vanderhoof  <swingbo...@gmail.com> wrote:
>
> >Ok -- so this is where I am at.  Current BE seems normal and working
> >but my zones are broken.  It looks like I can live comfortably with
> >the new_BE_cpy if I can get my zones back / running without any errors
> >or errors from zoneadm and zlogin, etc commands -- but how exactly.
>
> What does Martin Paul's PCA report as missing patches in your current
> working BE?
>
> John

> groenv...@acm.org

Haven't use PCA much as management decided not to
renew Oracle support contract and cannot connect PCA with
Oracle to check. We have some kind of corp deal with Oracle
to get patches, but as corp seems to want to migrate away from
Solaris to Linux (probably a 5 year project at best) they do not
want to pay for T-support.

Other suggestions?

Thanks for you help.

Paul

[Paul Vanderhoof]

On May 22, 12:07 pm, cindy <cindy.swearin...@oracle.com> wrote:

>
> Hi Paul,
>
> I can't follow everything in description above, but a couple of
> comments:
>
> 1. LU inserts the zone zoneds file system names when needed so it
> can support your zones. If you remove them, they will break LU.

Did not remove them: when I created another BE from the patched
new_BE, then activated it with luactivate, then rebooted
into the newly created BE, I found the zone dirs had disappeared.
Basically I have 3 BE old_BE (u09 not patched), new_BE (patched with
latest 10_Recommended and shows as u10), and new_BE_cpy, a BE created
after I had successfully boot -Z booted into my patched new_BE.

I have not tried to revert back to new_BE to see if the zone dirs
reappear in the /zoneds path.

>
> 2. The boot -L allows you to select the BE to from but it does not
> activate
> the BE for you. You would still need to luactivate the working BE.

Per my description above I have done exactly that -- and it really did
not work. On reboot
I was back into the non bootable situation from which I had started
with an error 48 (wrong ZFS version) and
un mountalbe file systems. My next step was to once again use boot -Z
to get back to a booted running state
with new_BE and then I created a new BE called new_BE_cpy, then
activated that with luactivate and rebooted.
At this point I had a system that was successfully booting into a
patched u10 system with all ZFS volumes and file systems
mounted. This is where I am now. How can I get my zones back?
There are populated zone dirs under the old zone
path "/export/zones" related to the original, un-patched old_BE.

>
> 3. I think you would benefit from reviewing the doc pointer I
> provided.
> My opinion is that stuff should work without having to read the docs
> and I write
> docs for a living, but for LU + zones, its a must.

I have read tons already, and have googled tons more and will try to
read everything I can get my hands on -- but would be super nice
if someone recognized the situation I face and had a ready answer.

>
> 4. I see we are offering a zones pre-flight checker for migration
> purposes.
> I'm hoping you can download this script and it will tell you what's
> wrong with your
> zones.
>

> https://blogs.oracle.com/listey/entry/oracle_solaris_zones_preflight_...
>
I did know about the preflight and downloaded it but have not had
time to study it. From what I have read so far, and what is
indicated
on the link you post, the purpose of this tool is to evaluate
migrating an
environment to a zone -- no a check to see / fix what is wrong with
an
existing zone.

> Thanks,
>
> Cindy
Appreciate your help and comments.

Paul

[John D Groenveld]

In article <4d8d25fd-9f2c-4a23...@v24g2000vbx.googlegroups.com>,

Paul Vanderhoof <swing...@gmail.com> wrote:
>Haven't use PCA much as management decided not to
>renew Oracle support contract and cannot connect PCA with
>Oracle to check. We have some kind of corp deal with Oracle
>to get patches, but as corp seems to want to migrate away from
>Solaris to Linux (probably a 5 year project at best) they do not
>want to pay for T-support.
>
>Other suggestions?

What are these outputs:
# uname -a
# pkginfo -l
# showrev -p

John
groe...@acm.org

[cindy]

> > Cindyhttp://docs.oracle.com/cd/E23824_01/html/821-1448/gbchy.html#scrolltoc

>
> Appreciate your help and comments.
>
> Paul

A few comments. I'm the one who needs to improve my reading...

I. I think you are saying that you recovered by using boot -L and
attempted to
activate your good know BE, but after the activation, the system
booted from
the bad BE any way? Is this right?

The original system is s10u9, right? I see some older CRs about having
ZFS
file systems mounted inside your NGZ with legacy mount option causes
the activation of the BE to fail but they are fixed in s10u8.

2. I think your assessment of the zones flight checker is correct and
mine was
wrong. I apologize.

3. Troubleshooting your zone config is harder. I think you will need
to describe your zones using the
supported zones config info I sent you, such as my zoneroot is /rpool/
abc and I do not have
any nested zone paths and so son.

Thanks,

Cindy

[Paul Vanderhoof]

> A few comments. I'm the one who needs to improve my reading...
>
> I. I think you are saying that you recovered by using boot -L and
> attempted to
> activate your good know BE, but after the activation, the system
> booted from
> the bad BE any way? Is this right?

Yes -- correct.

>
> The original system is s10u9, right? I see some older CRs about having
> ZFS
> file systems mounted inside your NGZ with legacy mount option causes
> the activation of the BE to fail but they are fixed in s10u8.
>

Yes -- my initial install was s10u9.

> 2. I think your assessment of the zones flight checker is correct and
> mine was
> wrong. I apologize.
>
> 3. Troubleshooting your zone config is harder. I think you will need
> to describe your zones using the
> supported zones config info I sent you, such as my zoneroot is /rpool/
> abc and I do not have
> any nested zone paths and so son.
>

I am working some other ideas on how to resolve this as well as ideas
contributed here.
My corp policy severely limits how much identifiable information from
our IT systems
that can be made public. I will try to provide a "the names have been
changed to
protect the innocent" version of all relevant config info and same
with regard to poster
John's info requests. At this point I am looking to try a zone
detach / reattach "update on attach"
method of getting the zones starightened out. More details later.

Paul
> Thanks,
>
> Cindy

[Paul Vanderhoof]

> A few comments. I'm the one who needs to improve my reading...
>
> I. I think you are saying that you recovered by using boot -L and
> attempted to
> activate your good know BE, but after the activation, the system
> booted from
> the bad BE any way? Is this right?
>
> The original system is s10u9, right? I see some older CRs about having
> ZFS
> file systems mounted inside your NGZ with legacy mount option causes
> the activation of the BE to fail but they are fixed in s10u8.
>
> 2. I think your assessment of the zones flight checker is correct and
> mine was
> wrong. I apologize.
>
> 3. Troubleshooting your zone config is harder. I think you will need
> to describe your zones using the
> supported zones config info I sent you, such as my zoneroot is /rpool/
> abc and I do not have
> any nested zone paths and so son.
>
> Thanks,
>
> Cindy

A few more points to that above:

-- after boot -L to boot into the patched new_BE i had running zones,
but the zone path had been changed to /zoneds.
My zoneadm, zlogin commands, etc, still resulted in <segmentation
fault> core dumped. However, I was able to ssh
into the zones normally from outside and everything seemed to function
normally within the zone.

-- after again using boot -L to boot into the patched new_BE, I tried
to
create another new BE and activate it -- lets call it new_BE_cpy --
on the premise that doing so would "fix" and "straighten
out" the weird scenario where I kept booting into the "bad" BE. This
has actually worked and my system now boots cleanly
into the 3rd, new_BE_cpy BE without any errors. However, at this
point, I have no zone dirs, files, data, etc under /zoneds,
but all my original zone dirs, files, data, etc, still existed under /
export/zones, which is where I created them initially with the
first, unpatched, s10u9 install.

-- I plan to try to copy those zone dirs from /export/zones, check
that my relevant /etc/zones config xml stuff is still there in
the new_BE_cpy BE, and then try a zoneadm -z xxx attach -U option.
This is talked about in the Zone Migration link and I
will be reading over this carefully tonight.

-- before patching my s10u9 system with the latest 10_Recommended I
did have any issues with the zones or the zoneadm
commands and I did not have any <sementation fault> core dumped. This
appeared only after my apparently successful
patch install and reboot into the (patched) new_BE.

Thanks

Paul

[cindy swearingen]

Sounds like you are making good progress. Yesterday morning. I talked
to the s10 install support
manager about your zone login core dumping after the LU and he had not
heard of this
either so we're really stumped. I'll try again with one of the LU guys
who did a lot of zones
work.

Just to recap:

1. A system running 10u9 with zones that are completely functional.
The zone configs
verify and halt and reboot without error.

2. During the LU to s10u10 migration process, no zone-related error
messages occur.

3. After the LU and the system reboots successfully, the zone login
core dumps.

Thanks,

Cindy

[Martin Paul]

Paul Vanderhoof wrote:
> On May 22, 12:20 pm, groen...@cse.psu.edu (John D Groenveld) wrote:
>> What does Martin Paul's PCA report as missing patches in your current
>> working BE?
>

> Haven't use PCA much as management decided not to
> renew Oracle support contract and cannot connect PCA with
> Oracle to check.

You don't need a support contract (or a "My Oracle Support" account) if you want
to use PCA just to check for missing patches ...

hth,
Martin.
--
SysAdmin | Research Group Scientific Computing - University of Vienna
PCA | Analyze, download and install patches for Solaris
| http://www.par.univie.ac.at/solaris/pca/

[Paul Vanderhoof]

Thanks you for that info. I have used PCA some in the past but not
for a while now.
I will revisit the PCA process and syntax and see what it tells me.

[Paul Vanderhoof]

On May 22, 8:26 pm, cindy swearingen <cindy.swearin...@gmail.com>
wrote:

All the above is correct except for one mistake on my part in that I
did not LU to s10u10, but did an LU to latest
10_Recommended. cat /etc/release still shows me at Oracle Solaris 10
9/10 s10s_u9wos_14a SPARC. I apologize
for mistakenly assuming that the 10_Recommended was taking my system
to the equivalent of s10u10. If I can
return this system to a stable reliable state I would like to do an LU
to s10u10 but Ihave never previosly attempted
a full version LU upgrade.

[cindy]

Could be I misunderstood. Diagnosis by email can be pretty painful,
particularly
if I have to read a lot of text.

I think there might some overlapping problems here:

1. If you new patched BE (the ABE) is in the same pool as the current
BE (PBE),
then the onscreen instructions fail. This is CR 6996301, fixed
recently.

2. I believe your BEs are ZFS file systems.

3. Are the zone roots also ZFS and are they in the root pool or a
separate pool?

4. Another long-time s10 install support engineer suggests the detach,
upgrade your
BE with the patch set, and re-attach and update your zones.

I haven't talked to the guys who have worked on LU/zones issues
recently, but
the answer to question #3 will help.

Thanks,

Cindy

[Paul Vanderhoof]

Yes new patched the BE in the sam pool as the current BE.

>
> 2. I believe your BEs are ZFS file systems.

Yes all BE live on ZFS file systems.

>
> 3. Are the zone roots also ZFS and are they in the root pool or a
> separate pool?

Zone roots are ZFS and on the root pool. File systems lofs mounted
from the root pool and the data pool.

>
> 4. Another long-time s10 install support engineer suggests the detach,
> upgrade your
> BE with the patch set, and re-attach and update your zones.

Trying this but so far any zoneadm or zonecfg command that references
the zones fails with <segmentation fault> core dumped.
I tried to copy the existing zone data from /export/zones/xxxx_name of
old BE (LU renamed the original zone dirs) to the
/zoneds/"zonename" dir and then run zoneadm -z zonename attach -U and
this fails with <segmentation fault> core dump.
Now going to try creating a new zone and the copy my data from the /
export/zones/xxx location.

I also brought the system to single user from >ok and ran the
10_recommended "installpatchset" script and the process show all
patches skipped -- so everyhting was up to date.

>
> I haven't talked to the guys who have worked on LU/zones issues
> recently, but
> the answer to question #3 will help.
>
> Thanks,
>
> Cindy

Thanks for your help.

[Paul Vanderhoof]

So all my attempts to attach a zone fails with <segmentation
fault>(coredump).
zoneadm -z my_zone attach -U fails and zonecfg -z my_zone create -a /
zoneds/xxxx fails.
Next I tried to configure and create an intirely new zone. zonecfg -z
my_new_zone result is

zone1: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone1> create
Segmentation Fault(coredump)

So I am now at a standstill. do I try ./installpatchset -R /zoneds/
my_zone and then try
to zoneadm -z my_zone attach -U ?

[John D Groenveld]

In article <50118950-ab50-43a8...@t2g2000pbl.googlegroups.com>,

Paul Vanderhoof <swing...@gmail.com> wrote:
>Next I tried to configure and create an intirely new zone. zonecfg -z
>my_new_zone result is
>
>zone1: No such zone configured
>Use 'create' to begin configuring a new zone.
>zonecfg:zone1> create
>Segmentation Fault(coredump)

You've proven that your current BE is broken.
What is the output of lustatus(1M)?

>So I am now at a standstill. do I try ./installpatchset -R /zoneds/
>my_zone and then try
>to zoneadm -z my_zone attach -U ?

No.
What is the checksum for your 10_Recommended.zip?
$ /usr/sfw/bin/openssl md5 10_Recommended.zip

John
groe...@acm.org

[cindy]

I'm checking with someone more knowledgeable about LU and zones.
It would be helpful to get some info from the zone-related core, such
as the stack info, like this:

# mdb core
Loading modules:
> ::stack
> <Control-d>

Thanks,

Cindy

[Ann Marie leahy]

Hi
So if I am reading this thread correctly you applied the recommended
patch cluster, if so can i see
/var/sadm/install_data/*verbose*.log

check in /var/tmp for any files realating to patching ( ie *??????-??
*.log )

pkginfo -p

run mdb on the core and give

:;status
$C

But you need to somehow upload an explorer and the log files from
patching ( the *verbose* mentioned above )

if this is not possible you need to closely examine the log file for
things like
egrep -i "error|fail|var/tmp|fatal" /var/sadm/install_data/
*verbose*.log

in /var/sadm/patch

grep "Re-installing Patch" */log
egrep -i "fail|fatal|pkgadd|pkginstall|postinstall|checkinstall|
preinstall|could not|test|mv|cp" */log

in above egrep output, be aware that an exit code of 2 from compress
is expected in some case ( just means that the compressed file would
be larger than uncompressed )

just so ignore errors from compress.

But a service contract would be good right about now, ie upload an
explorer etc
for explorer info and where to grab from MOS read doc id 1153444.1 on
supporthtml.oracle.com

Enda

[Paul Vanderhoof]

OK -- so after poking around with mdb and ldd and with all the help
provided here by all you great people I have resolved this issue -- at
least so it appears -- still testing everything.

The issue with the zone command problems turns out to be an issue with
conflicting Apache2 and PHP libraries. Just after the Live Upgrade
patching and before we saw any of the zone command problems (we
actually had not had any reason to use them at the time) we had
compiled new versions of Apache2 and PHP for this system and changed
the LD_LIBRARY_PATH and LD_RUN_PATH to include the libraries needed by
Apache2 and PHP. I added them after the original paths, but
apparently the zone commands are still getting confused over these.
Took them out of LD_LIBRARY_PATH and LD_RUN_PATH and the zone commands
began to behave properly and ldd against the zone commands are not
showing any more "=> (version not found)" issues. After that I made
backup copies of my /export/zones zone dirs and then used the zoneadm -
z zone_xxxx attach -U to upgrade them to the current patch level and
to bring them to installed and running state. That worked just fine
and I was back in business. Then I used the zoneadm -z zone_xxxx move
command to get them back to the original path names since they still
had the renamed paths that LU had created.

So now we have to work on how to get the compiled new versions of
Apache2 and PHP (which are required by our business application) to
have access to their libraries and play nice with the Solaris
libraries. I am not a developer nor an Apache admin, but will work
with the company software developers to see if we can get this
straightened out. A quick google on the net brings up some others
with similar issues and looks like we can use compiler directives to
hard code the library paths or something.

Again -- gigantic THANKS to everyone who wrote back to my plea for
help and for all they helpful suggestions.

Paul

[hume.sp...@bofh.ca]

Paul Vanderhoof <swing...@gmail.com> wrote:
[ TWO HUNDRED AND SIXTY lines clipped. My god man, learn to quote!]

> compiled new versions of Apache2 and PHP for this system and changed
> the LD_LIBRARY_PATH and LD_RUN_PATH to include the libraries needed by

Whenever LD_LIBRARY_PATH and LD_RUN_PATH enter the picture, you're asking
for pain... either immediately or down the line.

Tell your developer to investigate compiling with the '-R' flag where ever
he has the -L. For example, if you compile with -L/my/personal/libraries,
there should be a matching -R/my/personal/libraries.

Basically, it moves the contents of LD_LIBRARY_PATH from the environment,
where it poisons and breaks everything, into the binary itself.

--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/

[John D Groenveld]

In article <jq5jqv$alr$1...@Kil-nws-1.UCIS.Dal.Ca>,

<hume.sp...@bofh.ca> wrote:
>Whenever LD_LIBRARY_PATH and LD_RUN_PATH enter the picture, you're asking
>for pain... either immediately or down the line.

See Xah Lee's archive of Dave Barr's treatise,
"Why LD_LIBRARY_PATH is bad"
<URL:http://xahlee.org/UnixResource_dir/_/ldpath.html>

John
groe...@acm.org