Upgrade of DU4.0D(patch6) -> Tru64 5.1

Upgrade of DU4.0D(patch6) -> Tru64 5.1

Post by Matt Butle » Wed, 13 Jun 2001 09:19:44



We are using an Alphaserver 4100 5/466 with a Storageworks 450 RAID Array.
This machine is used for development and testing purposes in order to
support a bespoke application. This application is used by two of our
clients. We (the two clients and ourselves) will need to upgrade the OS very
soon. I am interested to get an understanding of the best (and safest) way
to do this, given that we must be able to support both clients throughout
the upgrade process. I had considered the following;

1) Schedule (only) the upgrade on site - to be managed by the clients.
2) Lease a machine and configuring it so that could be used to support both
clients.
3) Perform the OS upgrade on the original machine.
4) Test the OS.
5) Test the application
6) Fix any problems
7) Deliver the application fixes
8) Give the OK to both clients to perform the OS upgrade and apply any
application patches.
9) Allow a week or so in case there are any major upgrade issues
10) Return the leased machine.

Having never performed an OS upgrade I am obviously concerned about the
implications of the upgrade. Can anyone advise me on the following;

1) What kind of problems might I encounter?
2) Are there any automated scripts for testing the OS after the upgrade?
3) Is the above a gold plated solution?
4) What is the recommended approach?

Any help or advise is much appreciated.

Regards,

Mat.

 
 
 

Upgrade of DU4.0D(patch6) -> Tru64 5.1

Post by Eric Bennet » Wed, 13 Jun 2001 14:22:07




> We are using an Alphaserver 4100 5/466 with a Storageworks 450 RAID
> Array.
> This machine is used for development and testing purposes in order to
> support a bespoke application. This application is used by two of our
> clients. We (the two clients and ourselves) will need to upgrade the OS
> very
> soon. I am interested to get an understanding of the best (and safest)
> way
> to do this, given that we must be able to support both clients throughout
> the upgrade process. I had considered the following;

> 1) Schedule (only) the upgrade on site - to be managed by the clients.
> 2) Lease a machine and configuring it so that could be used to support
> both
> clients.
> 3) Perform the OS upgrade on the original machine.
> 4) Test the OS.
> 5) Test the application
> 6) Fix any problems
> 7) Deliver the application fixes
> 8) Give the OK to both clients to perform the OS upgrade and apply any
> application patches.
> 9) Allow a week or so in case there are any major upgrade issues
> 10) Return the leased machine.

> Having never performed an OS upgrade I am obviously concerned about the
> implications of the upgrade. Can anyone advise me on the following;

> 1) What kind of problems might I encounter?
> 2) Are there any automated scripts for testing the OS after the upgrade?
> 3) Is the above a gold plated solution?
> 4) What is the recommended approach?

> Any help or advise is much appreciated.

> Regards,

> Mat.

If you only need to have access to both versions of the OS if a problem
should arise and you need to do testing or debugging, but don't actually
need to *run* them both simultaneously, you could duplicate your
original installation onto a second disk and then upgrade the OS on that
disk, leaving the original untouched.  Then you'd have a dual-boot
capable machine.  I have a machine that has 5.1 and 4.0F installed, one
on an internal disk and the other on an external.  I haven't encountered
any problems switching between the two OS versions.

--
Eric Bennett ( http://www.pobox.com/~ericb/ )
Cornell University / Chemistry & Chemical Biology

Washington budget estimators are the only professionals whose forecasting skills
are more suspect than television weathermen.  -Daniel Gross

 
 
 

Upgrade of DU4.0D(patch6) -> Tru64 5.1

Post by Florian Wep » Sat, 16 Jun 2001 05:30:25



> We are using an Alphaserver 4100 5/466 with a Storageworks 450 RAID Array.
> This machine is used for development and testing purposes in order to
> support a bespoke application. This application is used by two of our
> clients. We (the two clients and ourselves) will need to upgrade the OS very
> soon. I am interested to get an understanding of the best (and safest) way
> to do this, given that we must be able to support both clients throughout
> the upgrade process. I had considered the following;

> 1) Schedule (only) the upgrade on site - to be managed by the clients.
> 2) Lease a machine and configuring it so that could be used to support both
> clients.
> 3) Perform the OS upgrade on the original machine.
> 4) Test the OS.
> 5) Test the application
> 6) Fix any problems
> 7) Deliver the application fixes
> 8) Give the OK to both clients to perform the OS upgrade and apply any
> application patches.
> 9) Allow a week or so in case there are any major upgrade issues
> 10) Return the leased machine.

> Having never performed an OS upgrade I am obviously concerned about the
> implications of the upgrade. Can anyone advise me on the following;

> 1) What kind of problems might I encounter?

No real trouble to be expected; read the instructions in the install
guide.  I think you'll have to go in two steps here: first to 4.0F,
and then to 5.1. At least, that is what I had to do last year when
going from 4.0D to 5.0A. In any case, the install guide will contain a
list of upgrade paths.

Note that there are certain Layered Products that can act up here -
DCE once gave me trouble, as did the X.400 stuff. You usually have to
uninstall them prior to the upgrade, and re-install afterwards. The
"installupdate" script will complain if you need to do this, but it
never hurts to be prepared (find the appropriate CD-ROM).

Compaq introduced abominable "WEB-enabled agents" with 4.0F; after the
upgrade, you will have complaints from your firewall crew with respect
to broadcasts from port 2301. This is the Insight Manager. You might
like it, but it made me look stupid in front of a security auditor
once, so I hate Compaq for automatically installing it with an
upgrade.

You'll have to get used to the new device names for disks.

Another issue is ADVFS, if you are using it. V5 brought us a new ADVFS
Version as well (4, I think). The old File Domains are upward
compatible. I had trouble once with a fairly large (120 gig) Old-Style
File Domain panicking on me during a rmvol operation under
5.0A. Nothing serious, though. ADVFS is admirably robust.

Quote:> 2) Are there any automated scripts for testing the OS after the upgrade?

What do you want to test? If you have a regression test suite for your
application, then applying that would make sense.

Quote:> 3) Is the above a gold plated solution?

Sounds good to me.

Quote:> 4) What is the recommended approach?

> Any help or advise is much appreciated.

> Regards,

> Mat.

Florian

--
This thing, that hath a code and not a core,
Hath set acquaintance where might be affections,
And nothing now
                Disturbeth his reflections.          -- Ezra Pound, "An Object"

 
 
 

1. Migration Tru64 4.0D to Tru64 5.1

I have twenty Alpha servers (some 1000A, some 4100, some 8200 ...) with
Tru64 4.0D.
I must migrate to Tru64 5.1.

I have 2 choises :
    - install the 5.1 and restore the conf files
    - migrate 4.0D to 4.0F first, and migrate 4.0F to 5.1

I prefer make a new install to make the new servers more "clean".

Your opinions ?

2. Dump for 386ix

3. tru64 upgrade (5.1->5.1b) - need advice

4. Man Pages Problem

5. Upgrading 4.0D to 5.1 on a 4100

6. How do I make my X-server secure?

7. Upgrading from Digital Unix 4.0d to 5.1 and Sybase ASE 11.9.2

8. corrupt filesystem during install

9. C++ Compiler version and issues on TRU64 5.1A (upgrading from V4.0D)

10. KZPAC support under Tru64 5.1>

11. KZPAC support on Tru64 5.1>

12. Modem hangs machine after upgrade from Solaris x86 2.4 du4 -> du7

13. Patching tru64 5.1/trucluster 5.1