Summary attached.
many thanks - Tony
On the 17/2/99 I sent out the posting (listed at the end of this
message) regarding problems installing jumbo-3:
Many thanks to the following who replied so quickly - as always:
Alan Davis
Arrigo Triulzi
John Francini
eatoni_at_hotmail.com
randy.cable
Robert Mulley
bryan_at_compgen.com
Just to clarify - I was not trying to regress to jumbo-2 from jumbo-3.
The intention was to upgrade to a system with jumbo-3 installed from
(the same system) with jumbo-2 already on it.
The moment the mailings started coming in I realised why the warnings
were being displayed. We edit the lsm script so that lsm errors (failed
plex's and the like) are mailed to the 'volwatch' user and not to root.
The patch was detecting this change.
The simple answer was to baseline the system. It worked just fine.
Many thanks for your help.
Tony
+-----------------------------------------------------------------+
| TONY MILLER - Systems Projects - VODAFONE LTD, Derby House, |
| Newbury Business Park, Newbury, Berkshire. |
+-------------+---------------------------------------------------+
| Phone | 01635-507687(local) |
| Work email | ANTHONY.MILLER_at_VF.VODAFONE.CO.UK |
| X.400 | G=ANTHONY; S=MILLER; C=GB; A=GOLD 400; P=VODAFONE |
| FAX | 01635-506709(local) |
+-------------+---------------------------------------------------+
Disclaimer: Opinions expressed in this mail are my own and do not
reflect the company view unless explicitly stated. The information
is provided on an 'as is' basis and no responsibility is accepted for
any system damage howsoever caused.
=======================================================================
===bryan_at_compgen.com===================================================
=======================================================================
Look at your /etc/passwd file. We had a similar problem when using
a hashed /etc/passwd. You will know that you are using a hashed
db if you have a file called /etc/passwd.<some_lame_extension>. It
is save to move the passwd file with the extension out of the way as
long as you still have a plain /etc/passwd file there. The root of the
problem (no pun intended) I believe is because root is getting a uid
other
than 0.
My .02,
=======================================================================
===Robert Mulley=======================================================
=======================================================================
Hi,
It looks as if someone or something has made some modifications to the
/sbin/init.d/lsm program. I'm not 100% on this but I believe there is
two ways
to rectify this situation.
1) Restore the original /sbin/init.d/lsm file from a backup taken just
after
install. This is probably not the ideal solution if you have made some
modifications to this program that you need to keep.
2) I believe using the dupatch program there is an option to set a
baseline.
This should be used with caution but it basically says "I'm comfortable
with any
changes that I've made to the system, therefore apply your changes on
top of
what I've done". That probably isn't the best way to describe it but...
Robert Mulley
Unix Administrator
GNS Consulting
=======================================================================
===randy.cable_at_mci.com=================================================
=======================================================================
At 01:13 PM 2/17/99 +0000, you wrote:
Tony, don't apologize that is what the list is for... At least it's
supposed to be, I am beginning to wonder these days... :-(
I have been working this same issue for the past few days, upto and
including the latest patched version of BL11 aka Jumbo 3.
We had to deinstall the BL10 and TruCluster patches prior to loading
BL11
in order toget it to load successfully.
Would have been nice if they had included this in the release notes...
rrc
=======================================================================
===eatoni_at_hotmail.com==================================================
=======================================================================
Hi Antony,
It could be because:
(1) You haven't got LSM functionality in your system because you didn't
install the subset.
Solution:Install the subset and try again.
(2) Someone has altered the files in this subset and this was not
registered in the .inv file (for this subset) at that time, so 'dupatch'
sees a mismatch between registered and the visible file system,
complains and then nose dives.
Solution: Check the subset functionality is OK; this could be because a
patch was applied in the past and some files changed. Whatever you do,
make sure you a copy of these files because 'dupatch' will not "backup"
the existing files if it cannot determine what is there. So if you
change your mind and want to return to this LSM version later you may
not be able to.
After you are sure there should be no problem, run the dupatch utility
"Baseline" (available from the dupatch menu) to override the dupatch
moaning about "fail to find origin..."; this overrides the checks, so
now when you rerun the installation of patch 175 is will not moan and
fully install. The danger of skipping patches that do not install is
that many of them are interdependant so the whole thing doesn't work.
(3) The path doesn't exist or has changed.
Solution: Recreate the path, so dupatch can find the files. Then run
Baseline (see .2)
I hope this helps you as these are problems I have also had.
Ian.
=======================================================================
===John Francini=======================================================
=======================================================================
Did you or any other sysadmin there edit that file? /sbin/init.d/lsm is
a
script. I suspect that the checksum no longer matches what the
installer
expected to find. This implies that it was edited or is corrupted.
One possibility would be to replace it with the one on the 4.0D
installation
CD.
(It may be in the /sbin/init.d directory of the limited system libraries
that
they supply for the installation/disk maintenance environment, or you
may have
to pull it out of the appropriate LSM setld subset.)
Another would be to back out any LSM patches from Patch Kit 2 that
affected
that file to get back to the original version.
John Francini
=======================================================================
===Arrigo Triulzi =====================================================
=======================================================================
Don't apologies, we only take turns here :-) This week it's your turn!
|I have the NEW Feb '99 jumbo 3 for dunix v4.0d. Am trying to install
|this on a jumbo-2 based system. I am doing the pre-install checks and
|they partially fail. The log is listed below.
Let me get this straight - you are trying to patch a jumbo 2 with
patched jumbo 3 (i.e. not the old one, the One Which Works(tm))?
In this case I would backout jumbo 2 and the patch to jumbo 3. I am
always very edgy about patching a patched machine, you are never sure
that they got the dependencies right.
Ciao,
Arrigo
--
Arrigo Triulzi <arrigo_at_albourne.com> - Peripatetic Wizard
Albourne Partners Ltd. - London, UK
APL Financial Services (Overseas) Ltd. - Nicosia, Cyprus
=======================================================================
===Alan Davis==========================================================
=======================================================================
Tony,
Use the baseline feature of dupatch to tell it
to ignore the change that was made to the lsm startup
script. You probably want to check that file and make
sure that if there are changes there that you need that
you save a copy to re-install later.
The message means that something about that file has
changed, size or checksum, that tells dupatch that
it's not the original file from the distribution. Since
it doesn't know where the file came from or what changes
were made, it won't replace it unless you run the baseline
first.
Alan Davis
Tru64 Unix Consultant
=======================================================================
===Original posting====================================================
=======================================================================
Hi all...
Apologies - I seem to be using this list a lot recently.
I have the NEW Feb '99 jumbo 3 for dunix v4.0d. Am trying to install
this on a jumbo-2 based system. I am doing the pre-install checks and
they partially fail. The log is listed below.
What do I do to resolve the 175 patch problem - this seems to be the
root of the problem? I am in single user mode with lsm started.
Any ideas??
Thanks - Tony
Problem installing:
- DIGITAL_UNIX_V4.0D / Filesystem Patches:
Patch 0175.00 - bcheckrc Runs With Invalid Root Entry
./sbin/init.d/lsm:
its origin can not be identified.
This patch will not be installed.
------------------------------------------------------------------------
-
* Following patch(es) failed in prerequisite/file applicability
check:
- DIGITAL_UNIX_V4.0D / Filesystem Patches:
Patch 0175.00 - bcheckrc Runs With Invalid Root Entry
1) proceed with the patches that passed the check
2) select patches again
3) go back to the previous menu
Enter your choice: 1
Checking patch prerequisites once more...
(depending upon the number of patches you select, this may take a
while)
------------------------------------------------------------------------
-
Problem installing:
- DIGITAL_UNIX_V4.0D / Filesystem Patches:
Patch 0016.01 - System Run Level Correction
requires the existence of the following un-installed/un-selected
subset(s):
- DIGITAL_UNIX_V4.0D / Filesystem Patches:
Patch 0175.00 - bcheckrc Runs With Invalid Root Entry
This patch will not be installed.
------------------------------------------------------------------------
-
* Following patch(es) failed in prerequisite check:
- DIGITAL_UNIX_V4.0D / Filesystem Patches:
Patch 0016.01 - System Run Level Correction
Select the action you'd like to take:
1) proceed with the patches that passed the check
2) select patches again
3) go back to the previous menu
Enter your choice:
Received on Tue Feb 23 1999 - 09:47:18 NZDT