You are here

Luminis 4.2 upgrade path?

Submitted by Christine on Tue, 10/04/2011 - 08:02

It's been a long time since I installed 4.2 from scratch. Do I really need to install 4.0, 4.1, and 4.1.1 before I can get to 4.2? I know 5 is out already so complaining about this is probably a moot point, but what a nightmare.

Everyone like's to talk smack about Blackboard, but at least I don't need to install every historical version of the system to get to what's current.

Someone please tell me I'm wrong about this :)


Luminis Version:


When I upgraded our development system from baseline (4.0) to the latest (at the time 4.3.0) the installer checks to see what items are installed and will install the necessary pieces. Hopefully that helps.


That's what the support person originally told me, but when I went to install 4.2 I got an error saying that I needed to install 4.1.1 first. I assume you didn't have this problem? Maybe with 4.3 its all built in.



It's been a little while since I've done it but I'm pretty sure you have to run through the installer for each major version as you upgrade.



It could be 4.3 specific I'm not sure, I never tested it with a lower patch installer. I know it was nice not having to go through installing each one at a time.


Hi All,

For versions lower than 4.2, you have to install each successive upgrade version. BUT then you can go from LP 4.2 to 4.3 without installing 4.2.2. I found this out by talking ot SunGard support folks when I was having problems with my 4.3 upgrade. (I thought I was having problems because I didn't install 4.2.2 first, but my problem was that I had symbolic links in my logs directory and the upgrade backup was following the sym links and eating up disk space.)

Hope this helps.... Now on to upgrading the OS...

Colorado School of Mines

We are trying to work out our "crib sheet/script" for consistently going from 4.2 to 4.3

Do you know whether the patching automatically does backup? One thing we have
noticed (on the few tries we have made) is that a symlink (from \$CP_DOC_ROOT) is
meaning that all the files in our /site (i.e. we have an NFS share between all our web
tiers and resource tier) were changed to be owned by root.

Unfortunately we have several things that are modified to be University of Leeds
specific, such as altering the .properties files to have the correct "language bundles"
and several of these modifications need to be re-jarred into things like cp.jar or

The upgrade also overwrites areas such as the custom skin
( \$CP_ROOT/custom/classic ) which means that potentially all of our modifications
within the customisable part need reworking.

It also does not seem to fix the features that we are upgrading for.

University of Leeds, UK


The upgrade process does create backup files... the files are created in $CP_ROOT/install. In order to properly run the upgrade I had to remove my symlinks in $CP_ROOT/logs. The real backup files were relatively small (233MB for LP 4.2.3 and 1.0G for LP 4.3.0)... where as when I had the symlinks present the backup file grew to 44G before I ran out of disk space.

BUT, I didn't look in the backup files that were created. I think that you have to make your own backups for your customizations. As to the /custom/ directory, we have our customizations in our own subdirectory of /custom/... After the upgrade, I had to reapply/rework our customizations and re-deploy the template (via the deployskintemplate command).

It wasn't fun, but I survived. I definitely recommend a crib sheet and lots of testing... I had a crib sheet, but still made mistakes as it got later and later into the day.

Colorado School of Mines

would it be possible to have a copy of your crib sheet?

(and yes, remove the sym links is on my list)

University of Leeds, UK

You might have some/all of this covered already but in case it's at all helpful here's a list of files and directories that I noted when working on our upgrade from 4.2.3 to 4.3.0 :

Back up key system files that will be overwritten. These include, but are not limited to :











Hope it helps!


I was hoping to put the list of things that we changed here, and was also
hoping that things had gone successfully.

However we might have found our first Gotcha -
The process of Luminis calling GCF is no longer behaving as it ought to.

(so calling

when Luminis issues a 302 redirect to the browser, the end of the destination URL has been chopped off.


I will try and see who wins the race in UDC vs lumdev

University of Leeds, UK

It turns out that a change to fix some other errors has broken Luminis slightly (so that my issue with GCF occurs).

Sungard HE supply a jar file to overwrite the bad behaviour, which goes in $CP_WEBINF/lib

This has fixed things as far as I can tell.

Now all I have on my "POST Upgrade Fix List" is editing the
and pushing this into cp.jar

University of Leeds, UK
p.s. Hope to post the list of what we did in the New Year.