| SuSE Linux provides the option of updating an existing system without completely reinstalling it. There are two types of updates: updating individual software packages and updating the entire system. Packages can also be installed by hand using the package manager RPM. |
Software tends to ``grow'' from version to version. Therefore, we recommend first taking a look at the available partition space with df before updating. If you suspect you are running short of disk space, secure your data before updating and repartition your system. There is no general rule of thumb regarding how much space each partition should have. Space requirements depend on your particular partitioning profile, the software selected, and the version numbers of SuSE Linux.
| Note |
It is recommended to read the README and, in DOS and Windows, README.DOS file on your CD. Find notes there regarding any additional changes made after this manual went to print. |
Before you begin your update, copy the old configuration files to a separate medium just to be on the safe side. Such media can include streamers, removable disks, floppy drives, or ZIP drives. This primarily applies to files stored in /etc. Also, review the configuration files in /var/lib. Furthermore, it you may want to write the user data in /home (the HOME directories) to a backup medium. Back up this data as SuSE @nohyphen root. Only SuSE @nohyphen root has read permission for all local files.
Before starting your update, make note of the root partition.
The command df /
lists the device name of the root partition. In the example shown in
Output 2, the root partition to write down is
/dev/hda7.
aus:update.dfList with df -h
Filesystem Size Used Avail Use% Mounted on
/dev/hda1 1.9G 189M 1.7G 10% /dos
/dev/hda7 3.0G 1.1G 1.7G 38% /
/dev/hda5 15M 2.4M 12M 17% /boot
shmfs 141M 0 141M 0% /dev/shm
The root partition can be recognized as the one
mounted as /.
For some updates, hard disks on the Promise controller may be detected before disks on the standard IDE controller. If so, the system will no longer boot following a kernel update and usually exit with Kernel panic: VFS: unable to mount root fs. In this case, the kernel parameter ide=reverse must be passed when booting to reverse this disk detection process. See 1. To apply this parameter universally when using YaST, enter it in the boot configuration. See (), chapter User-Defined Installation, Booting (Boot Loader Installation).
| Caution |
Only the controllers activated in the BIOS are detectable. In particular, subsequently activating or deactivating the controllers in the BIOS has a direct effect on the device names. Use caution or risk being unable to boot the system. |
Technical Explanation
The controller sequence depends on the motherboard. Each manufacturer wires
its supplementary controllers differently. The
lspci shows this sequence. If the Promise controller is listed
before the standard IDE controller, the kernel parameter
ide=reverse is required after updating. With the previous
kernel (without direct Promise support), the controller was ignored
so the standard IDE controller was detected first. The first disk was then
/dev/hda. With the new kernel, the Promise controller is detected
immediately and its (up to four) disks are registered as /dev/hda,
/dev/hdb, /dev/hdc, and /dev/hdd. The previous
/dev/hda disk becomes /dev/hde so is no
longer detectable in the boot process.
Following the preparation procedure outlined in 2, you can now boot:
YaST reads the ``old'' fstab on this partition to analyze and mount the file systems listed there.
Because basic system components, such as libraries, must be exchanged when updating a base system, an update cannot be run from within a currently running Linux system. First, set up the update environment. This is normally done using the CD or DVD or with a custom boot disk. If you are carrying out manual modifications during the update or prefer to perform the entire update with YaST in text mode, follow the steps already described in detail in 1. Below is a summary of this procedure.
Following the selection of a language and the hardware detection by YaST, select ` Update existing system' in the YaST opening screen.
Next, YaST attempts to determine the root partition and displays the result for selection or confirmation. Select your root partition from the list (for example, /dev/sda3). In this way, prompt YaST to read the ``old'' fstab from this partition. YaST will analyze and mount the file systems listed there.
Then you have the possibility to make a backup copy of the system files during the update. In the following dialog, either choose to update only the software already installed or to add important new software components to the system (``upgrade mode''). It is advisable to accept the suggested composition (e.g., ` Standard system'). Adjustments can be made later with YaST.
In the warning dialog, select ` Yes' to start the installation of the new software from the source medium to the system hard disk.
First, the RPM database is checked, then the main system components are updated. YaST automatically creates backups of files modified in the running system since the last installation. In addition, old configuration files are backed up with the endings .rpmorig and .rpmsave (see 2). The installation or update procedure is logged in /var/adm/inst-log/installation-* and can be viewed later at any time.
After the base system is updated, you will be switched to YaST's update mode. This mode allows you to tailor the rest of the system update to your needs.
Complete the procedure as you would a new installation. Among other things, select a new kernel. The available options are presented by YaST.
| Tip |
If you boot with loadlin, save the new kernel and, possibly, the initrd into the loadlin directory of your DOS partition. |
Regardless of your overall updated environment, you can always update individual packages. From this point on, however, it is your responsibility to ensure that your system remains consistent. Update advice can be found at http://www.suse.de/en/support/download/updates/.
Select components from the YaST package selection list according to your needs. If you select a package essential for the overall operation of the system, YaST issues a warning. Such packages should be updated only in the update mode. For instance, numerous packages contain ``shared libraries''. If you update these programs and applications in the running system, things might malfunction.
The individual aspects changed from version to version are outlined in the following sections in detail. This summary indicates, for example, whether basic settings have been completely reconfigured, whether configuration files have been moved to other places, or whether common applications have been significantly changed. Only the modifications that would affect the daily use of the system at either the user or the administrator level are mentioned below. The list is by no means complete. The following also makes references to SDB (Support Database) articles. These articles are in the package sdb_en, series doc ().
Problems and bugs for each version have been published on the web server as soon as they were recognized. See the links listed below. Important updates of individual packages can be accessed at http://www.suse.de/en/support/download/.
Problems and Special Issues:
http://sdb.suse.de/sdb/en/html/bugs80.html.
Problems and Special Issues:
http://sdb.suse.de/sdb/de/html/bugs81.html.
yast2-trans-* is now split by languages: yast2-trans-cs (Czech), yast2-trans-de(German), yast2-trans-es (Spanish), etc. Not all languages are installed to save hard disk space. Install the required packages for the YaST language support as needed.
Problems and Special Issues:
http://sdb.suse.de/sdb/en/html/bugs82.html.
The generated configuration file will be printed to the default output, enabling the use of these specifications for generating a permanent configuration file.
If you own applications depend on the directory jade_dsl and the files previously installed there, you have to adapt your own applications to the new directory /usr/share/sgml/openjade or create a link as SuSE @nohyphen root:
cd /usr/share/sgml rm jade_dsl ln -s openjade jade_dsl
To avoid a conflict with package rzsz, the command-line tool sx continues to be called s2x/sgml2xml or osx.
Problems and Special Issues:
http://sdb.suse.de/sdb/en/html/bugs90.html.
(Der neue Wert ist 200112 und wird als Vorgabe für _POSIX2_VERSION angenommen.)
Den SUS-Standard kann man hier nachlesen (frei, aber eine Registrierung ist erforderlich):
Hier eine kurze Gegenüberstellung:
| POSIX 1992 | POSIX 2001 |
|---|---|
| chown tux.users | chown tux:users |
| tail +3 | tail -n +3 |
| head -1 | head -n 1 |
| sort +3 | sort -k +3 |
| nice -10 | nice -n 10 |
| split -10 | split -l 10 |
Tip
Software von Drittanbietern folgt möglicherweise noch nicht
dem neuen Standard; in einem solchen Fall ist es ratsam, die
Umgebungsvariable wie oben beschrieben zu setzen:
_POSIX2_VERSION=199209.
In SuSE Linux, RPM (Red Hat Package Manager) is used for managing the software packages. Its main programs are rpm and rpmbuild. Thus, the powerful RPM database can be queried by the users, the system administrators, and package builders for detailed information on the installed software.
Essentially, rpm has five modes: installing, uninstalling or updating software packages, rebuilding the RPM database, querying RPM bases or individual RPM archives, integrity checks of packages, and signing packages. rpmbuild can be used to build installable packages from pristine sources.
Installable RPM archives are packed in a special binary format. These archives consist of the program files to install and certain meta information used during the installation by rpm to configure the software package or stored in the RPM database for documentation purposes. RPM archives normally have the extension .rpm.
rpm can be used to administer LSB-compliant packages. Refer to 11 for more information on LSB.
Tip
For a number of packages, the components needed for software
development (libraries, headers, include files, etc.) have been put into
separate packages. These development packages are only needed if you want to
compile software yourself, for example, the most recent GNOME
packages. They can be
identified by the name extension -devel, such as the packages
package alsa-devel, package gimp-devel, and package kdelibs-devel.
SuSE Linux RPM packages have a GnuPG signature:
The command
can be used to verify the signature of an RPM package to determine whether it really originates from SuSE or from another trustworthy facility. This is especially recommended for update packages from the Internet. Our public package signature key normally resides in /root/.gnupg/. Since version 8.1, the key is additionally located in the directory /usr/lib/rpm/gnupg/ to enable normal users to verify the signature of RPM packages.
Normally, the installation of an RPM archive is quite simple:
With this command, the package will be installed -- but only if its dependencies are fulfilled and there are no conflicts with other packages. With an error message, rpm requests those packages that need to be installed to meet dependency requirements. In the background, the RPM database ensures that no conflicts arise -- a specific file can only belong to one package. By choosing different options, you can force rpm to ignore these defaults, but this is only for experts. Otherwise, risk compromising the integrity of the system and possibly jeopardize the ability to update the system.
The options -U or -upgrade and -F or -freshen can be used to update a package.
This option will remove the files of the old version and immediately install the new files. The difference between the two versions is that -U installs packages that previously did not exist in the system, but -F merely updates previously installed packages. When updating, rpm updates configuration files carefully using the following strategy:
Following an update, .rpmsave and .rpmnew files should be removed after comparing them, so they do not obstruct future updates. The .rpmorig extension is assigned if the file has not previously been recognized by the RPM database.
Otherwise, .rpmsave is used. In other words, .rpmorig results from updating from a foreign format to RPM. .rpmsave results from updating from an older RPM to a newer RPM. .rpmnew does not disclose any information as to whether the system administrator has made any changes to the configuration file. A list of these files is available in /var/adm/rpmconfigcheck. Some configuration files (like /etc/httpd/httpd.conf) purposely are not overwritten to enable a seamless takeover of the running operations using the personal settings.
The -U switch is not just an equivalent to uninstalling with the (-e) option and installing with the (-i) option. Use -U whenever possible.
To remove a package, enter the following command:
rpm will only delete the package if there are no unresolved dependencies. It is theoretically impossible to delete Tcl/Tk, for example, as long as another application requires it. Even in this case, RPM calls for assistance from the database. If such a deletion is -- for whatever reason and under unusual circumstances -- impossible, even if no additional dependencies exist, it may be helpful to rebuild the RPM database using the option -rebuilddb. See 2 for more information about the RPM database.
To guarantee the operational security of a system, update packages must be installed in the system from time to time. Previously, a bug in a package could only be eliminated by replacing the entire package. Large packages with small bugs could easily result in large amounts of data. However, since SuSE 8.1, the SuSE RPM offers a new feature enabling the installation of patches in packages.
The most important considerations are demonstrated using pine as an example:
To check this, first query the installed version of the package. For pine, this can be done with the following command:
Then check if the patch RPM is suitable for this version of pine:
This patch is suitable for three different versions of pine. The installed version in our example is also listed, so the patch can be installed.
The files affected by a patch can easily be seen in the patch RPM. The rpm parameter -P serves the selection of special patch features. The list of files is displayed with the following command:
or, if the patch is already installed, with the following command:
Patch RPMs are used just like normal RPMs. The only difference is that a suitable RPM must already be installed.
A list of all patches installed in the system can be displayed with the command rpm -qPa. If only one patch is installed in a new system (like in our example), the list appear as follows:
If, at a later date, you want to know which package version was originally installed, this information is also available in the RPM database. For pine, this information can be displayed with the following command:
More information, including information on the patch feature of RPM, is available in [1]rpm and in [1]rpmbuild.
With the -q option, rpm initiates queries, making it possible to inspect an RPM archive (by adding the option -p) and also to query the RPM database of installed packages. Several switches are available to specify the type of information required (see Table 2.1).
For example, the command rpm -q -i wget displays the information shown in Output 3.
aus:update.rpm-i
rpm -q -i wget
Name : wget Relocations: (not relocateable)
Version : 1.8.1 Vendor: SuSE AG, Nuernberg, Germany
Release : 142 Build Date: Fri Apr 5 16:08:13 2002
Install date: Mon Apr 8 13:54:08 2002 Build Host: knox.suse.de
Group : Productivity/Networking/Web/Utilities Source RPM: wget-1.8.1-142.src.rpm
Size : 2166418 License: GPL
Packager : http://www.suse.de/feedback
Summary : A tool for mirroring FTP and HTTP servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This might be done in script files or via command line.
[...]
Option -f only works if you specify the complete file name with its full path. You can name as many file names as you want. For example, rpm -q -f /bin/rpm /usr/bin/wget results in:
rpm-3.0.3-3 wget-1.5.3-55
If only part of the file name is known, a shell script must be implemented, shown in File 1. Pass the partial file name to the script shown as a parameter when running it.
Script to Search for Packages
#! /bin/sh
for i in $(rpm -q -a -l | grep $1); do
echo "\"$i\" is in package:"
rpm -q -f $i
echo ""
done
The command rpm -q -changelog rpm displays a detailed list of information (updates, configuration, modifications, etc.) about a specific package.This example shows information on the package rpm. However, only the last five change entries in the RPM database are listed. All entries (dating back the last two years) are included in the package itself. This query only works if CD 1 is mounted at /cdrom:
With the help of the installed RPM database, verification checks can be made. These checks are initiated with the option -V, -y, or -verify. With this option, rpm will show all files in a package that have been changed since installation. rpm uses eight character symbols to give some hints about the following changes:
| RPM Verify Options | |
| 5 | MD5 check sum |
| S | File size |
| L | Symbolic link |
| T | Modification time |
| D | Major and minor device numbers |
| U | Owner |
| G | Group |
| M | Mode (permissions and file type) |
In the case of configuration files, the letter c will be printed. Example for changes to /etc/wgetrc (package wget):
The files of the RPM database are placed in /var/lib/rpm. If the partition /usr has a size of 1 GB, this database can occupy nearly 30 MB, especially after a complete update. If the database is much larger than expected, it is useful to rebuild the database with the option -rebuilddb. Before doing this, make a backup of the old database. The cron script cron.daily makes daily copies of the database (packed with gzip) and stores them in /var/adm/backup/rpmdb. The number of copies is controlled by the variable <MAX_RPMDB_BACKUPS> (default: 5) in /etc/sysconfig/backup. The size of a single backup is approximately 3 MB for 1 GB in /usr.
All source packages of SuSE Linux carry an .src.rpm extension (source RPM).
Tip
These packages can be handled in the same way as all other
packages. The packages, however, will not be found in the RPM
database (and are not marked with an [i] in YaST), as only
``installed'' software is listed.
This is because the source packages are not incorporated in the RPM
database. Only installed operating system software is listed in the
RPM database.
The following directories must be available for rpm and rpmbuild in /usr/src/packages (unless you specified custom settings in a file such as /etc/rpmrc):
When you install a source package with YaST, all the necessary components will be installed in /usr/src/packages: the sources and the adjustments in SOURCES and the relevant .spec file in SPECS.
Note
Do not experiment with
system components ( package glibc, package rpm, package sysvinit, etc.),
as this endangers the operability of your system.
The following example uses the wget.src.rpm package. After you have installed the package with YaST, you should have the following files:
rpmbuild -b <X> /usr/src/packages/SPECS/wget.spec starts the compilation. <X> is a wild card for various stages of the build process (see the output of -help or the RPM documentation for details). The following is merely a brief explanation:
-short-circuit lets you skip specific steps. This binary RPM can now be installed with rpm -i or, preferably, with rpm -U. Installation with rpm makes it appear in the RPM database.
The danger with many packages is that during the build process, unwanted files are added to the running system. To prevent this, use the package build, which creates a defined environment in which the package is built. To establish this ``chroot'' environment, the build script must be provided with a complete package tree. This tree can be made available on the hard disk, via NFS, or from DVD. The respective position is specified with build -rpms <path>. In contrast to rpm, the build command looks for the SPEC file in the source directory. To build wget anew (like in the above example) and the DVD is mounted in the system under /media/dvd, use the following commands as SuSE @nohyphen root:
Subsequently, a minimum environment will be established at /var/tmp/build-root. The package will be built in this environment. Upon completion, the resulting packages are located in /var/tmp/build-root/usr/src/packages/RPMS
The build script offers a number of additional options. For example, you can cause the script to prefer your own RPMs, omit the initialization of the build environment, or limit the rpm command to one of the above-mentioned stages. Additional information can be accessed with the command build -help and in [1]build.
KDE offers the kpackage tool. GNOME offers gnorpm.
Using the [alien]Alien Perl script, it is possible to convert or install an ``alien'' binary package. This tries to convert ``old'' TGZ archives to RPM before installing. This way, the RPM database can keep track of such a package after it has been installed. Beware: alien is still ``alpha'' software, according to its author -- even if it already has a high version number.
![\includegraphics[width=.8\linewidth]{u_y2_software}](img12.png)