One of the problems I encountered during my SLES10 to SLES10-SP1 upgrade was that SLES10-SP1 downloaded many packages that were already mirrored to my local YUM server. It also took a bit of time to download SP1 itself. This severely increased the upgrade time and it took over 8 hours and used much more space. While the upgrade eventually completed successfully, I ended up restoring everything back to SLES10. An 8-hour outage window for my production Linux guests is hard to come by.
Here are the steps that I used to reduce this outage time. I started with my local YUM server. I applied the switch-update-server patch to switch and register the new update server from update.novell.com to nu.novell.com. I upgraded my YUP package. I was running yup-47-0.10 and upgraded to yup-222-26.1. You can get the latest YUP at http://software.opensuse.org/download/home:/mge1512/SLE_10/noarch/ . I made the following changes to my YUP configuration. I chose directory /var/cache/yup. YUP_DEST_DIR="/var/cache/yup" YUP_ID="<device ID>" YUP_PASS="<secret>" YUP_SERVER="nu.novell.com" YUP_ARCH="s390x" YUP_SUBVERSIONS="GA SP1" My existing YUM server was storing its updates in /var/cache/yum/SLES10/s390x/. I rename this to /var/cache/yum/SLES10-Updates/sles-10-s390x/. I also copied the contents to /var/cache/yup/SLES10-SP1-Online/sles-10-s390x/rpm/s390x to avoid re-downloading duplicate packages. My YUP directories are really logical volumes within their own volume group that I be-bop back and forth using NFS. I exec YUP using: /usr/sbin/yup > /tmp/yup.`date +\%b\%d-\%Y-\%H\%M\%S` And reviewed the messages. After YUP completed, I have the following: /var/cache/yup/SLES10-SP1-Online /var/cache/yup/SLES10-SP1-Updates /var/cache/yup/SLES10-Updates SLES10-Updates contain my former SLES10 update RPMs. There should not be much syncing anymore in this directory. SLES10-SP1-Online contains SP1 RPMs. SLES10-SP1-Updates is empty and remained empty even after upgrading my YUM to SLES10-SP1. I was told that this might simply be due to no post SLES10-SP1 updates having been released yet. I added SLES10-Updates and SLES10-SP1-Online to the installation sources under YaST2. These were local directories for my YUM server and NFS directories for my various SLES10 guests. I backed up my YUM server and installed move-to-sles10-sp1 using YaST2 Online Updates which were pointing to my local YUM repositories. Patch move-to-sles10-sp1 brought in some other patches and a YaST2 update that required restarting YaST2. Windows containing instructions were popped as appropriate by YaST and I simply followed these directions. Additional instructions are also available at http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3509359&sliceId=&dialogID=39225710&stateId=0%200%2039235512 . During the update process, I received CHOWN errors on my automounted NFS file systems. This occurred whether the file systems were mounted or not. I traced the patch to filesystem-10-1.12.s390x.rpm. To get around it, I had to unmount them (if there were mounted), terminate the autofs daemon, and click retry where the update successfully recovered and continued. The upgrade also requested and used my original SuSE SLES10 installation CD4. Since this was available on a NFS server, I almost did not notice it. I do not know why. Since the updates were stored locally, the download time was significantly reduced but the application of the SP1 patches still took about 1 hour. The SP1 update will request a reboot which went off without a hitch. I did notice that my local mods were lost from the following: /etc/shells /etc/bash.bashrc I keep good records for local mods so this was not a problem. However, others should be aware of it. Also, while rebooting SLES10-SP1, it looks like it tries to crank the spinning slash during the Reiser file systems check, which just ends up looking like crap on our 3270 consoles. If anyone knows how to prevent this, please let me know. YaST2 looks completely different and functions seem slower but everything is there. What is really frustrating is that there is no way of closing the YaST2 window. Prior to SP1, you could simply click file/quit but that option is no longer available. Of course you can always kill the yastcontrolcenter daemon. My root file systems did increase 5-10 percent depending on the Linux guest I was upgrading. Other then the obvious kernel change from 2.6.16.27-0.9-default #1 SMP Tue Feb 13 09:35:18 UTC 2007 to 2.6.16.46-0.12-default #1 SMP Thu May 17 14:00:09 UTC 2007 a quick comparison of RPMs showed the following additional products were installed: audit-libs-32bit dbus kdebase3-32bit libgssapi-32bit libiniparser libmudflap libnscd-32bit libssui limal-nfs-server limal-nfs-server-perl mono-winforms net-snmp-32bit pciutils-ids switch-update-server yast2-control-center-gnome yast2-registration zypper kdebase3-32bit was the largest of these products. I ended up deleting all the KDE packages and bought back some more space in my root file systems. After I finish upgrading all my SLES10 to SLES10-SP1, I will go back to my YUM server and delete /usr/cache/yup/SLES10-Updates as the old SLES10 updates will no longer be required. I will also change YUP_SUBVERSIONS="GA SP1" to YUP_SUBVERSIONS="SP1". Directory /usr/cache/yup/SLES10-Updates will also be removed from the various guests YaST2 installation sources. I suspect that this will apply to everyone that clones their LPARs and Guests. The whole updating process is so radically different then SLES9 that I hope this helps anyone else making the jump to SLES10-SP1 from SLES10. User mileage might vary. Enjoy and good luck. Peter This Email message and any attachment may contain information that is proprietary, legally privileged, confidential and/or subject to copyright belonging to Pepco Holdings, Inc. or its affiliates ("PHI"). This Email is intended solely for the use of the person(s) to which it is addressed. If you are not an intended recipient, or the employee or agent responsible for delivery of this Email to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this message in error, please immediately notify the sender and permanently delete this Email and any copies. PHI policies expressly prohibit employees from making defamatory or offensive statements and infringing any copyright or any other legal right by Email communication. PHI will not accept any liability in respect of such communications. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
