Remote Upgrade to SLES 11 SP1 Using Zypper

Jeremy Pavlov July 5, 2010 5 Comments

As you might have noted in my previous posts, I do not like to visit server consoles for upgrades.  So I want to thank Novell for having outlined a handy little instruction sheet here:  How to upgrade to SLES/SLED 11 SP1 (TID 7005410) on how to do various remote upgrades from SLES 11 to SLES 11 sp1, including remotely via shell session.  I’ve used these steps outlined in the section called “Update to SP1 via patches” –> “2) Update by using zypper” with great success so far.  However, I’d like to toss one or two little tips back to the community…

In these steps outlined by Novell, you are required to manually retrieve the values from /etc/products.d/*.prod and individually install the special upgrade/migration packages for each listed product definition.  And that’s fine in a lab, but with a farm of servers and potentially more than one upgrade/migration type each (in my situation they were cluster/HA servers, so each had two items), this can be a bit of a bother.  So for added convenience, I wrote a little “for” loop tweak to take care of those manual steps.

Without further ado, here are the modified steps for the upgrade to SLES11 sp1 using zypper with my tweak (thanks again Novell, and please see the caveats below):

zypper ref -s
zypper up -t patch
zypper up -t patch
for item in `cat /etc/products.d/*.prod|grep '<product>'|sed s/\<*.product\>//g |sed s/" "//g`; do zypper in -t product $item;done
suse_register -d 2 -L /root/.suse_register.log
zypper ref -s
zypper lr
zypper dup

…and there are a few very important points to be made about the above steps:

• Do not run those steps as a continuous script;  step through it line-by-line, watching the results at each step.
• Make sure your registration keys are all up to date and your repositories are in good shape before starting!  This is especially important and complex if you are using the HA extension or other custom add-on products that require registrations and repositories.
• In my experience, I sometimes needed to re-check and repair my repositories after the first or second “patch” statement, and sometimes before the “dup” statement; I do not know why.  Even Novell’s doc suggests that there may be complications.
• Afterward, you might want to go in and run the yast customer center registration tool, and allow it to clean itself up.

I hope that helps!

🙂