]>
UNDER DEVELOPMENT -- RPM download and upgrade -- UNDER DEVELOPMENT 2002 Steven Sanfratello $Date$ $Name$ The GNU/Linux world asserts that the operating system can be downloaded from the Internet and installed for no money. It is easiest to install GNU/Linux on a fresh partition. But in my readings I was always left wondering if it is also possible to upgrade an existing distribution without destroying it. Here is a description of upgrading a GNU/Linux distribution to the next major release from the same distributor, using the downloaded binary rpm packages. Upgrading using downloaded, binary rpm packages has its advantages and disadvantages. It took me about a week and a half to download a little over 600 Megabytes, using a 56K modem. A few days after that I was done upgrading the packages. Things did not go smoothly for me. But I'll explain how to correct the pitfalls that I encountered, so that you will spend less time when you upgrade. THIS DOCUMENT IS STILL UNDER DEVELOPMENT. PLEASE, HOLD ANY CRITISISMS UNTIL I'M FINISHED WRITING IT. GNU Copyleft Copyright and Licensing Notice Copyright (c) Steven Sanfratello. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being Copyright and Licensing Notice and Warranty with no Front-Cover Texts and with no Back-Cover Text. A copy of the license is included in the section entitled " GNU Free Documentation License ". The author can be contacted at nevets72@a1isp.net and failing that, try the LDP discussion list at discuss@linuxdoc.org . If you are profiting, in any way, from use or distribution of this document please consider giving something back to the author or to the Linux community and then act on those considerations. Warranty Although every precaution has been taken in the preparation of this HOWTO, the publisher and author assume no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information contained herein. Introduction Introduction Where is the latest version? Get the latest version of this HOWTO from : HTML Version on my web page Docbook XML Linuxdoc CVS Docbook XML source on my web page Purpose of this document There are many reasons that you might want to read this. If you are considering taking advantage of the freely downloadable versions of Linux you should know that it takes some effort and know-how to accomplish. This HOWTO gives you real picture of the effort required before you start the process. In that way it will help you decide if the big download and upgrade is worth the trouble. Whether you decide to download or you obtain the rpm packages on disk, then this will explain what it takes to do the upgrade. Most commercial distributions are packaged as binary rpms, so I thought that a HOWTO on a major upgrade would be useful. The most important factor when upgrading the rpms is choosing the right order (hint: start with the libraries.) If you're having problems using your installation program because it isn't reducing the packages down to fit on your harddisk, this method gives you control over the packages to eliminate what you don't need. That control allows you to customize your install to almost any size that you want. While several installation programs give you this level of control, some do not. This is not a proceedural HOWTO. I'll give you a description of what I went through to set up and upgrade my system and the reasoning behind it. From that description you can get an idea of what's involved when doing similar upgrades to your system. There are many different programs that can be used for this process. I'll touch on many of them. This is not a HOWTO about upgrading a single program, with its dependancies. That knowledge can be obtained from the rpm documentation. But if you find that there are so many new dependancies that package requires, and you've worked the dependancies all the way down to the kernel, you may decide that it's time to upgrade the whole distribution. How long does it really take? Over all, it took about one and a half weeks to download the packages. The binary rpms total size was a little over 600 Megabytes. It took a few more days to do the upgrading. A more automated FTP proceedure would reduce the download time significantly. The FTP server dissconnected me often. I found that this was the biggest time waster in the whole process. The timeout before notifying me that the server wasn't responding, added to the time it took me to notice and check that message, added to the time it takes to reconnect, multiplied by a disconnect every 20 to 60 minutes totaled many wasted hours. Not to mention the time of waiting for the downloads. A program that reconnects to an FTP server automatically would be a big help in reducing the downloading time. ncftp has a feature to download files in the background: ncftp> bgget which would make the download easier and possibly faster too. Upgrading would go smoother and quicker for a person with more experience upgrading. For me, this was a discovery effort, so there were many pitfalls for me. I am writing this to help you avoid those pitfalls and so your experience should go quicker than mine. The benifits and costs of upgrading this way Benifits Costs Downloading the packages is free. But the big cost is the time it takes to download and the space it takes to store them. You don't have to buy the CD s. The purchase price of the CD could contribute towards future upgrades of the distribution. Upgrading each package by hand gives you control over your system. You'll have the opportunity to choose which components you want and which you don't want. Not all of the installation software available gives you that much control. That control requires some knowledge of what to do and what not to do. (Be careful that anything that you do can be undone, so that you can recover from your mistakes.) This control could be very helpful when you have to squeeze Linux into a small harddisk or if you just want to tailor Linux to your needs. If you don't need the control, it is much easier to get a commercial installer. Upgrading one package at a time also gives you a deeper understanding about the components of your system and how they fit together. What I'm assuming about you. You'll need to know what rpm (Red Hat Package Manager) is and have some basic experience using the packages. (See ) You have a working Linux with rpm installed. If you are going to do the download, I assume that you have more time on your hands than money (like me). Or that you have a high speed Internet connection. The upgrading will take some familiarity with Linux and some knowledge of the what each package does. This knowledge can be obtained from the package information, of course. (See for how to show the summary information.) You have to use that knowledge when choosing the right packages to satisfy rpm dependencies. Normally these will have similar names, which makes it simple to do. One solution probably won't work for everyone so you'll have to be aware of what your doing and understand why you're doing it. Some thoughts on distributions and upgrading Characteristics of a distribution which would be a good choice for upgrading Current packages (so that your efforts in upgrading are worth your while) Well structured dependencies Compatiblity with other distributions Well structured grouping Configured and tested packages Packages configured for versitility and security Includes useful packages but skips unnessesary ones Easy and flexible installation program A bootable CD with a Linux that can be used to do maintainence on your system Of course, there are lots of other factors, each of which will be important to different people. Many of the factors in choosing a distribution are subjective. You'll have to weigh them for yourself to decide which are important to you. I just think that these were some relavant factors in regards to this HOWTO. Switching distributions by upgrading to new one It's not impossible to upgrade from one distribution to another, but it's very difficult. You'll have to deal with missing files, unsatisfied dependencies, incompatable groupings and incompatable package names. It would be nice to be able to upgrade one disribution with another, allowing you to see the advantages of a other distributions. When building the rpms the builder has options to which files are added, how the packagea are grouped, the name of the package and the dependencies of the package. These are some of the works that distibuters do. These will vary from one distributor to another in quality and name. And so when you try to use a package from one distributor to upgrade a package of another distributor, you will find that it is not an exact fit. Download Licensing of rpm packages There are several different licenses that cover a complete Linux OS. The most famous one is the GNU GENERAL PUBLIC LICENSE ( GPL ) which allows the free distribution of derivative works of GPL programs. ( rpm itself is covered by this license. When used as a library it's covered under the LGPL.) According to the GPL a derivative work is, "a work containing the Program or a portion of it, either verbatim or with modifications." Binary rpm packages are derivative of the original program. If the original program was covered by the GPL then so is the rpm package of it. Also, "Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things." This permits the free distribution of GPL software. Not all Linux software in a distribution is licensed under the GPL , though. So, this HOWTO refers to downloading GPL software. Software that isn't covered under the GPL may require different steps to respect those licensing requirments and those differences will not be addressed at this time, for the sake of simplcity. The easiest way to tell if a package is under the GPL is to look for it being mentioned in the Copyright field of the rpm information. Can linux be downloaded? Yes, it can, if you have the disk space to keep all of the files. FTP is a good download method. HTTP can be used also but is more difficult because it limits you to downloading one file at a time. Here are some of the basics of ncftp and some pitfalls to avoid to make your downloading easier. A quick summary of some ncftp commands follows but see the info on ncftp(1) for all of the details of each command. ncftp features The ncftp program is a nice tool. It can get the binary files off the remote server and into the current working directory. It is also possible to download files as a background process using the bgget command allowing unattended downloads . You can write download commands into scripts allowing unattended downloads . But I won't elaborate on that. For files that weren't completely downloaded, ncftp is capable of resuming the download from where it left off rather than starting the file from the beginning. To abort a get command with two Ctrl-C keystrokes. This will stop your download and get you out of ncftp quickly. Use wild cards to get larger blocks of files. ncftp is also capable of getting directories, recursively. Time savers: Skip unnecessary files and tweak time-outs You probably will not want to spend the time getting all the files from the remote directory. For instance you can skip any of the X servers that aren't meant for your video card. If you want to save a big chunk of time and disk space you can skip the destop packages but most home users won't want to do that. Home users can skip many of the server packages, though. Base your choices on the packages of your current system, but understand that your distributor may have introduced some now and necessary packages that cannot be skipped. Generate a list of your current system's packages with one simple command: $ rpm -qa currentrpms There's a way you can get ncftp to skip over some files while getting files using a wild cards. Create an empty file in your local directory which has the same name as the file that you want to skip. Create a name for every file that you want to skip. If you have the auto-resume disabled, when ncftp comes to that file during ncftp> get it will ask how you want to handle it. You can choose to [ S ]kip it. To create the empty files in your local directory you can first list the remote filesystem to see their exact names. ncftp> ls To create an empty file with the same name: $ touch FILE X allows you to highlight the file name and copy it with the middle mouse button . You'll have to prevent ncftp from completing the download of these files by disabling the auto resume. ncftp> set auto-resume no Time saver trade off If ncftp is set to automatically resume downloading then it will defeat the purpose of creating the empty files. You will not save any downloading time. So disable the auto resume feature. ncftp> set auto-resume no The trade-off of setting ncftp in this way is that you'll have to tell ncftp to [ S ]kip each empty file, as they are encountered. It also means that you will have to attend to the download process yourself in order to answer these questions. It is up to you if you want use this to save download time, or not. I chose to use it because there were several dozen files that I wanted to skip. In the end, I'm not sure if saving the download time was worth the effort. Local timeouts and Server disconnects The FTP server might have a tendency to kick you off after every few files you download, even if there are only a few users logged onto it. Sometimes you might even get disconnected in the middle of a large (10-20 Megabyte) file. That is when the resume feature of ncftp really comes in handy. These disconnects get very frustrating and time consuming. When the server does kick you, ncftp will wait for a timeout before it informs you of the disconnection. The variable which controls that timeout is called control-timeout (isn't that clever of them?) I found that the default timeout was way too long and slowing me down. This setting delays how long ncftp will take before announcing that the server wasn't responding. You'll probably want to decrease both your connect-timeout and control-timeout in order to speed up the download process. The more reliable your connection with the server then the smaller you can make them. As you download each chunk of files, turn them down slowly and pay attention to see if decreasing your timeout makes your connection less reliable. If that happens then you have gone too low. See the ncftp man pages for descriptions of the timeout variables, there are 3 of them. My timeout variables are set as so: connect-timeout : 20 control-timeout : 10 xfer-timeout : 3600 Partitions You've got one partition but consider making more. You may find as you're upgrading that having a separate partition for backups can be very handy. You can choose to stick with just one partition for Linux but consider the possible flexibility that adding one or more spare partitions might give you when upgrading. A spare partition can perserve backups during an installation. Backup the /etc and /home directories for example. Or it can hold your downloaded rpm packages. mount it to a temporary point while restoring the backups. After restoring from the backups, that partition can be erased and remounted at a more permanent point, integrating it into the running system. If the partition is large enough to fit both the backups and the files that are normally installed in that mount point, then it can be mounted as normal during installation and won't need to be erased. This was my case. If you decide to create a spare partition for backups you have the choice of making one big partition or several smaller ones. Installing on one partition is simpler than multiple ones. If you only use one partition now, it will be possible to divide the partition into smaller partitions after the installation. But non-destructive repartitioning (programs like fips or Partition Magic ) will be necessary if that partition has data on it. Having one, large spare partition is convienient because it can fit all of the backup data in one place. But that can have the disadvantage of being wastefully large when trying to integrate it into your new installation. For instance with Linux fully installed on the other partition, where would you mount the spare partition? The big mount points like /usr and /home , are already be installed and mounted. What other directories need a large partition? On the other hand, multiple partitions can give some flexibility during the backup and installation that a large one dosen't have. It will be more complicated to break up your backup data across several spare partitions but when the partitions are remounted you'll have more options of where to mount them. Mount the spare partitions as extra swap space, /opt , /etc , or many other of the smaller directories. It will be easier to mount the spare partitions at these points since they're a little less crucial to a running system as directories like / or /usr . If you find that you didn't give some mount point a big enough partition and you'd like to give it some more space then a small spare partition can be mounted somewhere under that original mount point, in order to expand it. For instance, I had / mounted on too small a partition. It ran out of space a couple of times after the upgrade. But I had a spare partition which was mounted to a temporary point called /extra . When I saw that the /var directory was the cause of the / partition getting filled, I was able to mount the spare partition as /var on the seperate partition. That freed up some space on the / partition and gave the new /var partition more room to grow. It is up to you if you want to give Linux one partition for convienience or if you want to try multiple partitions for flexiblity. There isn't a single correct answer for all systems There is a detailed HOWTO ( ) on partitioning if you'd like to learn more about them and thier use. My situation wasn't ideal but it will be a good example to explain some ideas. While upgrading my Linux I made a mistake that completely prevented my kernel from booting. The mistake was improperly upgrading the glibc libraries. As a result of that I had to re-install my old version of Linux before being able to use the upgrade rpms. I was lucky to have a seperate partition (my Windows partition) to keep the downloaded rpms while I re-installed Linux. The spare partition saved me from having to destroy over 600 Mbytes of downloads. Because of that spare partition, I was able to re-partition, re-format and re-install Linux without loosing any of the downloaded rpms. When I installed, I was so pleased at the value of having an extra partition that I decided to make several partitions on the Linux side of my harddrive to give me the most flexibility for the next time that I re-installed. Partitioning tools I chose to create several partitions. I'll explain what partitions I made and my reasons for making them. Read on and decide for yourself if you think that my examples are are worth trying on your system. When you have multiple partitions in Linux the partitions should be appropriatly sized for the directory that they'll be mounted as. You can estimate those sizes based on my setup, but it would be better if you based those sizes on your existing installation. To check the size of a directory issue the command: $ du -sh [FILE] One possible approach is to use one (or more than one) partition for holding your backup data. Use the remaining ones to complete the Linux installation. This, of course, assumes that your harddrive is large enough to fit all of this. Check your installation requirements to get an idea of how much space you'll need to install Linux. Compare that to your harddrive space devoted to Linux and maybe you'll find that the difference leaves you enough room to backup on the same harddrive. This is a very convienent way to temporarily backup during an upgrade or install. Half of my 8 gigabyte drive is devoted to Windows and the other half to Linux. The first primary partition ( /dev/hda1 ) was used to backup the rpm packages, when first downloading them. While re-installing, I also used one of the Linux partitions for backup. The second primary partition ( /dev/hda2 ) reserves the physical space for the logical partitions. Those logical partitions are the ones that are mounted by Linux. This second primary partition is never mounted directly. Use fdisk or your distribution's installation program, to display and manipulate the partition information. # fdisk DISK Run fdisk as root and display the partition information. Command (m for help): p Quit the program without writing any changes. Command (m for help): q The mount point information can be obtained from the file /etc/fstab or with mount using no arguments. $ mount Check how much free space is on your partitions. $ df -h Whichever partition(s) hold your backups, make sure that you do not reformat or resize it during installation, those would destroy your backups. You can use top or kpm to monitor how much swap space your system uses. A partitioning example Here is how my logical partitions are mounted their sizes: Partition Mount point Size Used space Used percentage /dev/hda5 /home 963 Mbytes 596 Mbytes 65% /dev/hda6 /boot 15.9 Mbytes 3.32 Mbyes 22% /dev/hda7 /usr 1.97 Gbytes 1.18 Gbytes 63% /dev/hda8 swap (not mounted) 64.2 Mbytes 27.0 Kbytes 4.2% /dev/hda9 /var 64.4 Mbytes 44.8 Mbytes 74% /dev/hda10 /opt 884 Mbytes 352 Mbytes 42% /dev/hda11 / 135 Mbytes 59.8 Mbytes 47%
This table gives you an idea of how big Linux is with XFree86, KDE 2 and lots of other goodies. Check your distribution's size requirements to find out how much space it takes up. I'll quickly discuss each of these partitions so that you can understand them and you can come up with your own strategy. Why all of those partitions? My /home partition was used for backup during installation. During installation this can be mounted as the normal /home directory. This is the directory that holds all of the user accounts and the users' personal data. Make sure that none of the existing directories on that partition have the same names as any of the users that you will be adding during installation. If they have the same name then your data could get overwritten. Also don't name any of the directories as /home/httpd which belongs to apache . Once mounted, the upgrade process can start from these backups. Use temporary names for the backups of the user accounts and allow the installation to create new users. Restore the data to the new user directories after upgrading the rest of system. The /boot partition holds the kernel image and associated files and possibly the boot loader ( grub ). It tends to be small and can be useful for positioning the kernel below cylinder 1024 on large hard disks in order to avoid the well documented BIOS limition which impedes booting a kernel image located at or above that cylinder. This partition will be too small to be much use for backups. The /usr partition will be the largest because it holds the majority of your programs. It has the size to be useful for backup but since so much will be placed here during installation, it might be complicated to figure out how much space to leave for the programs. Of course, if this partition is larger than the total amount specified by the installation requirments than it should be fine to use the remaining space for backup since this directory will surely be smaller than that specification. The swap partition and the /extra partition were sized and positioned very specifically. With 64 Mbytes of RAM I wanted a swap partition that could be as much as double that size. That would mean that I'd need about a 128 Mbyte swap file. In Linux kernel verion 2.1 128 Mbytes is the upper limit of the size of a single swap partition but that limit has been raised since then. My sytem dosn't usually use much swap space though, so I broke that in to two partitions. One was made into a swap partition and the other was made mountable by formatting it as an ext2. This gave me the option of later changing the second partition to a swap partition, but to be able to use it for file space for now. Note: The /extra was remounted as /var as explained in and that is why /extra dosen't appear in the previous table. I made the /extra and swap partitions about 64 Mbytes a piece. If I found that I needed more swap space I could convert the /extra partition to a swap partition. For the time being, I can mount the /extra partition and use it for storage. Finally, I also positioned the /extra between the / and /opt partitions so that the /extra partition could be combined with either one of those partitions to expand their size. The /opt partition holds some more programs. And in that way, it has the same problems in using it for a backup partition as the /usr partition. You'll need to have and idea of how much space the upgraded programs will take up and the remaining space is available for backup data. Contributing to the 352 Mbytes (as shown in the table above. See .) of my /opt partition are acroread-4.0 , KDE , KDE 2 and rvplayer5.0 . Note that if you have Netscape it also gets installed in /opt . Starting with a fresh install What are the good reasons for erasing your Linux and starting with a fresh install? Why perform a fresh install? Your distribution may want you to. Linux has a mess of programs and files that you don't want to keep and would love an easy way to get rid of them. Installing on a new harddrive. You've got no files that you care about loosing. You don't have time to do anything more than the minimum effort and your backups are complete and up-to-date. Summary In conclusion, there are many possible ways of re-arranging your data between various partitions. The advantage this gives is to keep an undisturbed copy of the data while doing a complete install. This was just one possible scheme and gives you an idea of how much space is needed for Linux in the various directories. Gathering this type of information from your existing system before installing will be very useful if you decide to re-partition the drive. If you repartition a drive that has data in one or more partitions make sure that you don't change the size of any of the partitions holding data. If you do the data will be destroyed with any standard partitioning program like fdisk . If you accidentally change the size of a partition which is holding backup data, don't panic. All you have to do is either quit the application, or have it re-read the partitioning information from the disk. In fdisk quit without writing and start over again. Command (m for help): q Prepare for trouble, before installing The dangers of upgrading the base libraries The kernel is dependant on the GNU libraries. If the libraries are removed then the running kernel can't access them. The kernel will stop running. That is a bad thing. Do not erase, uninstall, upgrade or delete the GNU libraries! At least not until you're certain that the kernel is using the upgraded libraries. I'll explain this more in the next section. 'rpm -U' verses 'rpm -i' When <application>rpm</application> upgrades ( <parameter>-U</parameter> ) a package it will : Compare the version of the rpm file with the version of the corresponding installed package to be sure that the rpm file is more recent. There are other checks that it runs for file conflicts, dependencies, etc. Install the new package files and register the new package name. Remove the old package files and the package name from the rpm database. When <application>rpm</application> installs ( <!-- FIXME : extra white space. --> <parameter>-i</parameter> <!-- FIXME : extra white space. --> ) a package it will : Do the same checks for installed versions, file conflicts, dependencies, etc. Install the new package files and register the new package name. You'll notice that the main difference is that upgrading removes the old package but installing dosen't try to remove an old package. Install assumes there isn't a package installed on your system which corresponds to this new package. That is an important difference when upgrading crucial packages that your system is using. Normally you will be upgrading the various packages. But for crucial packages, like the base GNU libraries installing ( -i ) a package allows the old package to remain. This is necessary when your running system is dependant on the files of the old package. When you install a new package, and there is an old one on your system, rpm will not notice the old package in the database but it will see the files of the package. rpm will complain about file conflicts. The complaints mean that some (or all) of the files of the new package have the same name and location as the files of the old, running package. rpm won't install the new package as long as it's detecting this error. You can use --force to have rpm ignore the error, but be careful if you do. Be sure that rpm reports no other errors before forcing the install. Correct all other errors before forcing. Once forced to install, rpm will overwrite the old files with the new ones. Since this dosen't delete the old files, but overwrites them instead, your system can still access the files and still run. Also, when querying, rpm will accurately report to you that both the old and the new packages are installed. The fact that the database has both versions listed is harmless to the database. But make a note of the redundant packages in case you want to remove the old one later. There is a possible problem with this technique though. The new files might have some compatibility bugs with the running system. I can't tell you how to avoid them. This is a risk that you will be taking with this technique. The advantages of this technique is that you're using the running system to upgrade itself and the system may not need to be shut down. The dangers of upgrading the kernel Pretty much the same as the dangers of upgrading the GNU libraries. You shouldn't remove a running kernel's files. That would stop it from running. Also, overwriting the existing files with the upgraded ones runs the risk of incompatibilities. But there's no way to avoid that risk if you want to upgrade a running kernel. Your distribution may have created new directories or new filenames in order to avoid overwriting. But the kernel is resident in memory and that makes it easier to upgrade than the libraries. You can upgrade the binary kernel package, once all of it's dependancies have been installed or upgraded properly. Ways to avoid mistakes Test an rpm comamnd with --test before you perform one that might be dangerous. Look for any error messages, understand why they're being generated and fix them before issuing the rpm command. Make sure that downloaded packages are fully downloaded once they're finished downloading. The easiest way to check this is to compare the file size on the server with the file size on your harddrive. Or you could use -K to have rpm do it's more secure and reliable checks. If you've got PGP set up right, do the full checks or use --nopgp to skip the PGP check if you don't. Verifying that the package downloaded correctly for the crucial packages (the base packages such as the kernel packages and the GNU libraries) is an important safeguard. A bad package which installs most of the files, but not all of them, can really mess up your system. (That is possible with rpm packages.) Checking is not as necessary for the less crucial packages though. So you don't need to bother for all packages. For some packages it might be a good idea to make backup copies of the files before upgrading. If the upgrade dosen't work, these backups can be used to restore without the need of rpm . This won't restore the rpm database, of course, but it will get the program running again. The times when you might need this, as stated before, are the crucial base packages and also rpm itself. Keep track of what your doing. Knowing your progress in downloading and upgrading helps you to avoid silly mistakes such as downloading a package twice or missing a package that you thought you had upgraded but haven't even downloaded. There are lots of packages in any distribution. If you ever want to backup your rpm database it's located at /var/lib/rpm . I have 576 packages installed on my system. Keeping track of all of them in your head is complicated. Having some written records of your progress will help ease your burden. Keeping track of your progress rpm can generate a list of the installed packages for you by querying all the packages. $ rpm -qa | sort > currentrpms Compare that with a list of the upgrade rpms. Generate the upgrade list by first, changing to the drectory where you put the upgrade rpms, then issue this command to make a list. sed removes the '.i386.rpm' file extensions. $ ls -1 *.rpm | sort | sed -e "s/\.i386\.rpm.*//" >> upgraderpms Finally, to make it easier to compare those two sorted lists, use diff to highlight the differences. $ diff -u currentrpms upgraderpms | less Basically, packages with a '+' before the name are files that are not installed yet. Packages with a '-' are installed on the system. Packages with a space character are just contextual information. While that gives you a nice written record of your progress, it is cumbersome to read. Kpackage is a tool that arranges all of the packges into a catorgized tree. It can sort out the upgrade packages for you, giving you a convienient, expandable tree to look at. I used both tools while upgrading. Other problems, beyond your control. "Ooops! After that upgrade, program foo won't run any more." foo could be the program that you just upgraded or one that you didn't realize was related to that upgraded program. The latter reason is because frontend programs are built to rely on other backend programs to do some of the work. Libraries are always used as a backend of another program. So, when upgrading backend programs or libraries, the frontend program may stop working because of incompatibilities between the old frontend and the new backend. On the other hand, you shouldn't get that problem when upgrading frontend programs because rpm will give you dependency errors as you try to upgrade. The dependencies tell you which backends and libraries the frontend is dependant on. But since the backend programs don't need the frontends in order to be complete, there are very few dependencies errors when upgrading backends. Ways to recover from mistakes If upgrading a backend or library causes a frontend to stop working, the best solution, obviously, is to upgrade the front end. This might not always be possible, though. There may be so many dependencies to satisfy, before upgrading the frontend, that it will take you too long to complete them all before getting your program back online. It may be worth it to downgrade back to the orignal version of the backend so that you can get the frontend program working immediately. This can be done by either : rpm -U --force <packagenames> rpm -U --oldpackage <packagenames> If you can't upgrade nor downgrade, go to your backups. If you made backups of the actual files that were a part of the old pacakge you can now use a simple cp command to restore the program. It can be complicated to get all of the files of a package backed up. But even if you miss a few, restoring might get your program running well enough to function for your needs. You should be able to use an rpm upgrade (or maybe even a downgrade) later, to get all of the files matching the database. In the worst case, if the crippled program was so crucial that you can't run your Linux system anymore, you'll need to run an alternate system. Boot up your spare Linux ( or ) and try to use that to restore your backups or rpm packages. Upgrade the packages Does everybody have their Linux up and running? Let's just get on the same page now. There have been many paths you could have taken to get to this point. Now, all of the partitioning of the harddrive is done. You have a working Linux system running. The Linux should be on that harddrive. That Linux should have a working copy of rpm with its database of packages up-to-date, relative to the Linux system. Your favorite GUI wrappers, frontends or replacements to rpm are helpful and convienient to have at this point. (See for some of your options.) Backups are on spare partitions or removable media, are up-to-date and are safe. You've obtained all of the packages needed to perform the upgrade. If you're still in the process of downloading them, you'll need to have at least the base packages and all of their dependencies. The web of dependancies can be complicated and surprising. To be safe, obtain as much as you can before starting the upgrade process. You don't want to be caught without a necessary package in the middle of a crucial upgrade, or your system might be harmed. Determining which packages are the base packages Start by upgrading the base packages. Which packages are they? There are several ways to identify them, but their names will vary, depending on which distribution you're working with. Base GNU/Linux system libraries: glib glibc libc5 (for backward compatibility) the Linux kernel's dependencies: modutils acpid kernel headers common kernel source processor specific source packages (i386, Sparc, Alpha, etc.) etc. the Linux kernel: linux kernel linux-kernel-binary etc.. Start by checking the Group field of the rpm information. Look for a string that indicates the system's base libraries and base programs. For example, Caldera's groups look like this : "Group : System/Library" "Group : System/Base" "Group : System/kernel" "Group : Base/Kernel" "Group : System/Shell" Red Hat's (Version 5.2) corresponding group names are : "Group : Libraries " "Group : Utilities/System" "Group : Development/Tools" "Group : Daemons" "Group : Development/Libraries" "Group : Base" "Group : Shells" These will include the kernel packages the GNU glib libraries kernel-headers the old libc package glibc etc . Make sure you have all of the kernel dependencies satisfied before you start installing anything. Check that the dependencies are satisfied by "test" installing the kernel rpms first with the --test parameter. This will report back to you if you're missing any dependencies. Here are the requirements listed in the Changes from kernel 2.4.17 to give you an idea of what packages support the kernel. Generally, these are upgraded before the kernel is. o Gnu C 2.95.3 # gcc --version o Gnu make 3.77 # make --version o binutils 2.9.1.0.25 # ld -v o util-linux 2.10o # fdformat --version o modutils 2.4.2 # insmod -V o e2fsprogs 1.25 # tune2fs o reiserfsprogs 3.x.0j # reiserfsck 2>&1|grep reiserfsprogs o pcmcia-cs 3.1.21 # cardmgr -V o PPP 2.4.0 # pppd --version o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version Stay cautious Once the base libraries, the kernel dependencies and the kernel are upgraded you've gotten through the most risky part of the upgrade. But not the only risk. There are other crucial packages to your system like the libz , bash and ncurses . Be sure to satisfy any dependencies and solve any errors for these or your prompt will not function and you may not be able to boot. The system initialization scripts are crucial, also. And so are the base libraries for KDE along with the Qt libraries. X has its crucial dependancies too. So, in general, be aware of your packages. Try to read the package information before upgrading it, so that you can have an idea of how cautious you need to be while upgrading it. rpm ignores tar balls rpm has some smarts built into it, but sometimes it is not smart enough. If you have any tar balls installed that serve as a dependency to an rpm package, rpm will not see those files and will give you dependancy errors. In that case, you do have the files that rpm is looking for installed but since they weren't entered in the rpm database, rpm ignores the files. To work around this, you'll have to have rpm ignore dependancies --nodeps or even --force if it keeps complaining. Full speed ahead Once you get through the base packages things will start to go quicker. Soon you get in the habit of how cautious you need to be. As things get upgraded, you'll start to see the gratification of new features and new looks to your applications. Restoring and Cleaning up Restoring and mounting the backup directory If you were using a spare partition for backup of rpm packages and system files it is now time to mount that into the system. Choose the mount point that you planned on using from the " " section. That mount point will already exist as a directory with files in it as a part of the running system. Because of this you'll need to integrate the new files with your old, backed up files. Some old files many need to be deleted. Some old files need to be merged with the new files. And, some new files many need to be deleted. It will take some work to merge old configuration files with new ones. For some packages though, there will be no work in integrating the configuation files because the file format hasn't changed in the new version. There are some more configuration files to merge once you're done with those. rpm has a feature of saving backup copies of some of the configuration files that it replaces. It will do this when it can merge the files itself. In that case it will save the original file by appending ".rpmsave" to the file name. Then it installs the new configuration file. You should locate all of the files with that string at the end of the name, and merge them with the new configuration file. Once the configuration files are merged, test out the new mount point by mounting it. The system may be using that mount point and not allow you to re-mount it. In that case, you'll have to skip to the next step. Make a backup of /etc/fstab to restore in case this modification dosen't work correctly. /etc/fstab will have to be modified to make the new mounting permanent. Reboot after modifying it to make sure that it is working correctly. While all of this merging seems daunting, don't loose heart. In general, the configuration files which haven't been changed since they were installed shouldn't need to be merged by hand. The only time they'll need to be merged by hand is when there are major changes to their format, done by the program author. That shouldn't happen often. But if there were configuration files that you made large changes too they might need to be merged. Old packages Once all of the rpm files have been used to upgrade, you might find that there are some installed packages that weren't upgraded. This is because they were a part of the old distribution's version but not the new version. Since they were not necessary by the new distribution they shouldn't be necessary for your system. You can remove them if they aren't packages that you use. You may also find some duplicate packages installed, which only differ by version number. This sometimes happens when rpm is forced ( --force ) while installing or upgrading. The database is accurate, saying that there are duplicate packages, and this isn't a problem for your system or the rpm database. Basically the newer package overwrote the common files between the two versions of the packages. So you'll wind up with all of the new versions of the files anyway. Eventually you will probably want to correct the reduncancy, though, in order to save harddrive space and avoid complicating the dependancies. rpm makes it safe to erase the old package.
"4. [RPM] reviews the RPM database to find every file listed as being part of the package, and if a file does not belong to another package, deletes the file." From
new packages /etc directory rpm command line tips Why do I need to read this when I'm using a graphical frontend for rpm? Query the package summary information : 'rpm -qi' List the package contents : ' <prompt>$</prompt> <command>rpm</command> <parameter>-ql</parameter> ' Summarize a group : 'rpm -qg' Summarize your system : 'rpm -qia' Summarize your upgrades : 'rpm -qip' Caldera 3.1 tips Lost packages between 2.4 and 3.1 Replaced packages between 2.4 and 3.1 Fixes Suggestions for package order Upgrade tools from the text plus others ncftp Here are some basic commands in the ncftp command prompt, which you will find useful when downloading the rpms. Set ncftp for binary transfers with binary. (This command isn't necessary because binary is the default transfer type. There are commnands to change through the local and remote directory (lcd, cd). Listing files in the local and remote directories (lls, ls). Set a named bookmark for the server and directory once you've found it, so that it's easy to open it the next time. get files using a wildcard. See the files in your working directory and prompting you if you'd like to [ O ]verwrite, [ S ]kip, or [ R ]esume the download of that file. Various programs mentioned in the text and alternatives to them. glint Some instructions for Glint Disk Druid (from Red Hat) Lizard (Caldera's graphical installtion tool) Lisa (Caldera's console based installation tool) fips Homepage: ? Author: Arno Schaefer <schaefer@rbg.informatik.th-darmstadt.de> Download: ftp://sunsite.unc.edu/pub/Linux/system/Install/fips01alpha.tar.z http://www.igd.fhg.de/~aschaefe/fips/ License: GPL and most Linux distributions carry it under the /dostools or /dosutils directory in the primary cd. kpackage ls cp PHI Caldera Upgrader tomsrblt Your bootable installation CD If you have a Linux installation CD that is bootable, you should be able to get a running Linux system from it. This system will probably have some minimal console tools which allow you to do some maintainence on your installed Linux, in case that is not functioning. To gain access to this Linux on a CD: Boot from the CD and get the installation program started Do not start re-installing! Try to find another virtual console by pressing Left-Alt F1 through Left-Alt F8 . One of them should give you either a shell prompt or a login prompt. If you can't find a prompt on any of those consoles, you may have to go through some of the basic initialization steps of the installation such as setting up the keyboard, screen, language and mouse. But again, do not start installing! Login to the Linux system, if necessary. Find a mount point that has some free space for a new directory. (Use the df command.) Make a directory there to be used as a mount point. Mount a partition that you want to modify under that mount point just created. FAQ questions answers &GFDLDOC; Bibliography Referenced Documents "Upgrading Your linux Distribution mini-HOWTO" Greg Louis 1996 Dynamicro Consulting Limited 6 June 1996 v1.11 Refer to an online copy "RPM+Slackware Mini-Howto" Dave Whitinger Refer to an online copy "RPM HOWTO" Donnie Barnes Refer to an online copy rpm(8) (a man page) Marc Ewing Jeff Johnson Erik Troan 22 December 1998 Red Hat Software "Linux Installation Strategies mini-HOWTO" Tobby Banerjee Refer to an online copy "THE COMPLETE redhat LINUX INSTALLATION GUIDE 5.2" Red Hat Software, Inc. Red Hat Software, Inc. 24-25 1995, 1996, 1997, 1998 Red Hat Software, Inc. 1-57595-199-1B Red Hat is a trademark of Red Hat Software, Inc. Copy Writer Download a copy from the Red Hat Linux Partition HOWTO Tony Harris Kristian Koehntopp Revision 3.3 10 July 2001 Refer to an online copy ncftp(1) Man page 3.0.2 Maximum RPM FIRST 1997 Red Hat Software, Inc. 0-672-31105-4 RPM is a trademark of Red Hat Software, Inc. Edward C. Bailey Related HOWTOs The Linux Installation HOWTO 2000 Eric S. Raymond Eric Steven Raymond Thyrsus Enterprises Revision 5.6 2001-09-06 Refer to an online copy Linux Swap Space Mini-HOWTO Rahul U. Joshi v1.42 18 January 2000 Refer to an online copy Filesystems-HOWTO.html Martin Hinner Version 0.7.5 22 August 2000 Refer to an online copy