]>
UNDER DEVELOPMENT -- RPM download and upgrade -- UNDER DEVELOPMENT 2002 Steven Sanfratello $Date: 2002/03/09 05:31:25 $ v0.02 The GNU/Linux world asserts that the operating system can be downloaded from the Internet and installed for no money. Upgrading is a fundamental task when maintaining a GNU/Linux system. The easiest way to upgrade is by installing GNU/Linux on a fresh partition. In my readings about upgrading 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 up to the next major release from the same vendor, 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 identify the pitfalls that I encountered and give tips on avoiding them, so that you will spend less time when you upgrade. 0.2 2002/03/10 srs After discussing the issues with Greg Louis, we decided not to merge his Upgrade HOWTO and mine. 1.0 2002/03/?? srs Initial public release. THIS DOCUMENT IS STILL UNDER DEVELOPMENT. PLEASE, HOLD ANY CRITICISMS 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 GNU Copyleft with no Front-Cover Texts and 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@linuxmail.org . If you're commenting on text from this HOWTO then please include and $Date$ to identify the version and release date of the HOWTO. If you are profiting from the use or distribution of this document please consider giving something back to the Linux community or to the author and then act on those considerations. Warranty Although this HOWTO has been carefully prepared, the author assumes no responsibility for errors or omissions or the risks that using these ideas creates. No liability is assumed for damages resulting from the use of the information contained herein. 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 Conventions used in this HOWTO There are some example commands in this HOWTO. They are formatted like this: application-name with prompt-character(s) command-name command-parameter(s) Sometimes I'll talk about my experiences during an upgrade. These are meant to convey my experiences, motivations and pitfalls to you. These experiences apply to my system but may also apply to yours, with some adapting. They are formatted like this: I appreciated having Linux and so I wrote this to give back to the community. Also I wanted to preserve this experience in writing so I wouldn't forget what I learned. What better way to preserve it than with a HOWTO? Notes like this one give you useful tokens of information that stand beside the main text. Cautions like this one tell you that a procedure can be dangerous to your system if done carelessly. Cross references to other sections of the text are formatted : . They are very similar to links which look : like this . 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. Reading this HOWTO gives you a real picture of the effort required before you start the process for yourself. In that way it will help you decide if the big download and the upgrade is worth the trouble. If your installation program doesn't give you enough control over which packages are installed, this method gives you the control to eliminate what you don't need. That control allows you to customize your installation to almost any size that you want. While some installation programs give you this level of control, some do not. Whether you decide to download or you obtain the rpm packages on disk, then this will explain what it takes to do the upgrade. Many commercial distributions are packaged as binary rpms, so I thought that a HOWTO on a major rpm oriented upgrade would make useful HOWTO. The most important factor when upgrading the rpms is choosing the right order (hint: start with the libraries.) 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 several of them. This is not a HOWTO about upgrading a single program, with its dependencies. That knowledge can be obtained from the rpm documentation. But if you find that there are so many new dependencies that package requires, and you've worked the dependencies all the way down to the kernel, you may decide that it's time to upgrade the whole distribution. That is the task that this HOWTO discusses. By using the rpm binary packages, you will have the convenience of using the compilation options and configuration options that the vendor has chosen. But, you will lose the ability to customize the compilation options. 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. I've also been told a 600 Mbyte CD-ROM image downloaded at an average 180 kilobytes per second -- seven and a half hours -- in one try, using a cable modem. A more automated FTP procedure would reduce the download time significantly. The FTP server disconnected 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 (T nr ), added to the time it took me to notice and check that message (T not ), added to the time it takes to reconnect (T rc ), multiplied by a disconnect every 20 to 60 minutes totaled many wasted hours. (T nr + T not + T rc ) * (20 to 60 minutes) = many wasted hours In addition to all of that there is, of course 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 which might help that problem. It can download files in the background: ncftp> bgget foo which might make the download easier and possibly faster too. After issuing a background command you might also want to issue a bgstart to give the download a kick in the pants. ncftp> bgstart Upgrading would go smoother and quicker for someone with more experience upgrading than I have. 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 regardless of your experience with upgrading. The benefits and costs of upgrading this way Benefits 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 developing the future 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 to make sure that any modification you make can be undone, so that you can recover from your mistakes.) Using the binary packages is more convenient than compiling each package. You will be dependent on the compilation options that the packager has chosen for you. You will have to trust that your packager knows the right options for your system. This control could be very helpful when you have to squeeze Linux into a small hard disk or tailor Linux in any other way. 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. There's sunlight, people and roller coasters out there in the real world! :-) 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. Writing this HOWTO as one procedure probably won't work for everyone. You'll have to be informed and stay aware of what you're doing understand why you're doing it and figure out the best way to apply it to your system . This is aimed at an intermediate Linux, at-home, administrator. 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 Compatibility with other distributions Well structured grouping Configured and tested packages Packages configured for versatility and security Includes useful packages but skips unnecessary ones Easy and flexible installation program A bootable CD with a Linux that can be used to do maintenance on your system Compliance with the LSB standards will allow better compatibility between various Linux distributions. 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 relevant factors in regards to this HOWTO. Switching vendors when upgrading It's not impossible to switch to a different vendor when upgrading but it is very difficult. You'll have to deal with missing files, unsatisfied dependencies, incompatible groupings and incompatible package names. It would be nice to be able to switch vendors by upgrading, allowing you to see the advantages of other vendor's distributions. When building the rpms the builder can choose which files are added to a package, how the packages are grouped, the name of the package and the dependencies of the package. These are some of the functions that vendors do. These will vary from one vendor to another in quality and name. And so when you try to use a package from one vendor to upgrade a package of another vendor, 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 is "intended to guarantee your freedom to share and change free software". This includes derivative work made from the software. According to the GPL a derivative work is, "a work containing the Program or a portion of it, either verbatim or with modifications." ( rpm itself is covered by this license. When used as a library it's covered under the LGPL.) 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 from the GPL, "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. But the GPL allows you access to the ones that are covered by it. So, this HOWTO refers to downloading GPL software. Software that isn't covered by the GPL may require different steps to respect those licensing requirements and those differences will not be addressed here, for the sake of simplicity. 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 that isn't as convenient. 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 in 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 which allows unattended downloads . 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, use two Ctrl-C keystrokes. This will stop your download 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 desktop packages but most home users won't want to do that. Home users can skip many of the server packages, though. Base your choices of what to download on the packages of your current system, but understand that your vendor may have introduced some new and necessary packages that cannot be skipped. Generate a list of your current system's packages with one simple command: bash$ rpm -qa > currentrpms There's a way you can get ncftp to skip over some files while getting files using 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 : ncftp> set auto-resume no When ncftp comes to that file during a 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 file system to see their exact names. ncftp> ls To create an empty file with the same name: bash$ touch FILE X allows you to highlight the file name and copy it with the middle mouse button . Then start downloading the files : ncftp> get foo* Time saver trade off The trade-off of setting ncftp in this way is that you'll have to tell ncftp to [ S ]kip each empty file as ncftp encounters each one and asks you how to handle it. 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 off, 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 a clever name?) I found that the default timeout was way too long and slowed me down. This setting delays how long ncftp will take before announcing that the server isn'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 the timeouts down slowly, one at a time, and pay attention to see if decreasing that timeout makes your connection less reliable. If that happens then you have gone too low and you should increase the timeout a little. 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 when upgrading Using a spare partitions You may find as you're upgrading that having a separate partition can be very handy. You can choose to stick with the distribution's original partitioning but consider the possible flexibility that adding one or more spare partitions might give you when upgrading. If you try to change a partition, which already has data on it you will destroy the data. To change a partition with data you will need program that can do non-destructive repartitioning such as fips parted or Partition Magic A spare partition can be used to install a whole new Linux, side by side with your current one. After that one is running the old data can be copied or merged into the new system. Then the old partitions, once the files on them aren't needed any more, can be repartitioned and merged back into your new system as its space requirements grow. Or if you don't have the hard drive space for a second Linux but your data is small enough, a spare partition can be used to back up the data. For example, back up the /etc and /home directories or store your downloaded rpm packages on the partition. mount the partition 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. The choice of how to use your hard drive's spare space, for the new Linux or for backup data, depends on how your drive is partitioned. If Linux is all that you are running and you have the space to make the partitions for a new Linux then that will probably be the safest and easiest way to upgrade. If you are dual booting, with seperate operating systems on seperate partitions, then you might want to use the other OS's spare space for tempoary back up while upgrading. Back up any data which you are worried might be damaged during the upgrade. Upgrade by overwriting the existing Linux sytem. There is a detailed HOWTO ( ) on partitioning if you'd like to learn more about them and their use. Also GNU's parted has documentation that explains many issues about partitioning. Growing into spare space After the upgrade, you will eventually want to integrate the spare space back into your new system. One way is dividing the space into smaller partitions and mount them into the directory tree of other partitions that are running out of space. As an example of integrating a small partition, 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 . That freed up enough space on the / partition and gave the new /var partition more room to grow. Here is a pitfall that scared me and how I got around it. 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 that I had downloaded. I was lucky to have a separate partition (my Windows partition) to store the downloaded rpms while I re-installed Linux. The spare partition saved me from having to destroy over 600 Mbytes of downloads. Because that spare partition held the data, I was able to re-partition, re-format and re-install Linux without losing any of the backup data. Partition sizes When you have multiple partitions in Linux the partitions should be appropriately 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: bash$ du -sh [FILE] 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 back up the rpm packages, as they were downloaded. 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. While re-installing, I used one of these logical partitions for back up in addition to the first primary partition just for reduncancy. Use fdisk or your distribution's installation program, to display partition information. Run fdisk as root. The partitions can be manipulated later. bash# fdisk -l device Check how much free space is on your partitions. bash$ df -h [FILE] The mount point information can be obtained from the file /etc/fstab or with mount using no arguments. bash$ mount Whichever partition(s) hold your backups, make sure that you do not reformat or resize it during installation. In most programs either of those actions would destroy your backups. You can use top or kpm to monitor how much swap space your system uses. A partitioning example 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 worth trying on your system. Here is how my logical partitions are mounted and their usage : Partition Mount point Size Used space Used percentage /dev/hda5 /home 963 Mbytes 596 Mbytes 65% /dev/hda6 /boot 15.9 Mbytes 3.32 Mbytes 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 back up 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 apache might want to use or as /home/ftp which an ftp program might use. 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. It can be useful for putting the kernel below cylinder 1024 on large hard disks in order to avoid the well documented BIOS limitation. This partition will be too small to be much use for back up. The /usr partition tends to be large because it holds the majority of your programs. It is probably big enough to be useful for backing up 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 size of your Linux then it should be fine to use the remaining space for backing up. That is because this directory will surely be smaller than that specification. The swap partition supplements your RAM. It is used to hold data from RAM which isn't currently being accessed, in order to free up more RAM. There was a rule of thumb saying to make this twice the size of your RAM. But the best way is to base this size on your current sytem. Find out how much RAM you're using with the kpm or top program. Each will give you a number that varies depending on how many programs you're running. So run the programs that you normally use to get an idea of the normal amout of swap space you use. Then size the partition a little bigger. My 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 the amount of RAM. That would mean that I'd need about a 128 Mbyte swap file. In Linux kernel version 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 system doesn't usually use much swap space though, so I broke 128 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 as file space for now. Note: The /extra was remounted as /var as explained in and that is why /extra doesn'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 .) 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 hard drive. You've got no files that you care about losing. You don't have time to do anything more than the minimum effort and your backups are complete and up-to-date. Wrap up ideas In conclusion, there are many possible ways of re-arranging your data amung various partitions. The advantage that a backup partition gives is to keep an undisturbed copy of the data while doing a complete install. Or you can install a whole new Linux on a spare partition to keep your old Linux undisturbed while configuring your new sytem. This are just a couple of possible schemes. This section gave you an idea of how much space is needed for Linux in the various directories. But gathering space requirements from your existing system before installing will be very useful if you decide to re-partition the drive. Prepare for trouble, before installing The dangers of upgrading the base libraries The many programs are dependent on the GNU libraries. If the libraries are removed then your system can't access them and will stop running. That is a bad thing. Do not erase, uninstall, upgrade or delete the GNU libraries! Wait until you are certain that the system 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 doesn't try to remove an old package. Install assumes that there isn't an older package installed on your system. That is an important difference when upgrading an application that your system is running. The running application might be using the files of that package. Removing the files can cause the application to crash. Normally you will be upgrading ( -U ) the packages. But for packages that the system is running, like the base GNU libraries, installing ( -i ) a package allows the old package to remain. This is necessary when your running system is dependent on the files of the old package. You can remove the old package later. 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 doesn't delete the old files, but overwrites them instead, your system can still access the files and still run. Once installed, 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. This technique lets you use the running system to upgrade itself. After restarting the application (or the system, if necessary), all of the upgraded files will be loaded and those problems should be solved. Reboot the system after the kernel and its dependencies are upgraded to get them running. Restart each application after each is upgraded to get the new files running. After restarting you can remove the old packages by erasing ( -e ) the old or upgrading ( -U --replacepkgs ) to the new package. The dangers of upgrading the kernel As you're upgrading the kernel dependencies, there could be some incompatibilities between the running kernel and the dependencies. That's because as you upgrade you have a mixture of older and newer files. Incompatibilities could cause the kernel to have trouble running properly. To avoid overwriting the kernel packages, the packages may create different directories or different file names. By creating new names for the new files, the older kernel files are preserved and can be booted if for any reason the new ones don't work. It's a common practice to keep two verions of the kernel installed so that if one has problems booting you have another as a backup. It is possible to upgrade ( -U ) the binary kernel package and dependancies all at once. To be safe you should make backup copies of the kernel image under /boot/vmlinuz or /vmlinuz and also the modules under /lib/modules before upgrading the kernel binary package. Restore those backups in case the upgrade stops the kernel from booting. Ways to avoid mistakes Test an rpm command 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 downloaded successfully. The easiest way to check this is to compare the file size on the server with the file size on your hard drive. Or you could use -K to have rpm do its 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. For crucial packages (libraries, the kernel and rpm , for instance) it's a good idea to make backup copies of the files before upgrading. If the upgrade doesn't work, these backups can be used to restore without the need of rpm . If the upgrade fails for any reason copying the files back in place won't restore the rpm database, of course, but it will give the program the files that it needs to run again. Keep track of what you're 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 back up 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. bash$ rpm -qa | sort > currentrpms Compare that with a list of the upgrade rpms. Generate the upgrade list by first, changing to the directory where you downloaded the upgrade rpms, then issue this command to make a list. sed removes the '.i386.rpm' file extensions. bash$ 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. bash$ diff -u currentrpms upgraderpms | less Basically, packages with a '+' before the name are files that are not upgraded/installed yet. Packages with a '-' are installed on the system but have no upgrade file. Packages with a space character are just listed as 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 packages into a categorized tree. It can sort out the upgrade packages for you, giving you a convenient, expandable tree to look at. I used both tools while upgrading. Other problems, beyond your control. I CANNOT SAY THIS FOR CERTAIN. THE LIBRARY UPGRADES DO SEE THAT THE FRONTEND ARE DEPENDIED ON THEM. THIS PROBABLY HAPPEND TO ME WHEN I WAS --forcing THE PACKAGES. Test out upgrading some library to refresh your memory. Upgrade one that has several frontends depending on it. "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 program that you just upgraded. Frontend programs are built to rely on other backend programs to do some of the work, this is how upgrading one package can affect others, if that package is a backend. 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 dependent on. These dependencies must be upgraded before, or at the same time as, the frontend. But since the backend programs don't need the frontends in order to be complete, there tend to be 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 original version of the backend so that you can get the frontend program working immediately. This can be done by either : bash# rpm -U --force <packagenames> bash# 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 package 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 some of them 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 hard drive is done. You have a working Linux system running on that hard drive. 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 convenient 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 dependencies 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. Start with the package name but realize that 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. Next check 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 any kernel packages. 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 kernel requirements listed in the /usr/src/linux-2.4.17/Documentation/Changes from kernel 2.4.17 to give you an idea of what packages support the kernel. Upgrade the packages that you need before the kernel is upgraded. 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 When doing an upgrade using the binary files, you don't need make or the C compiler . Some of the other packages won't be needed on some systems. 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 dependencies too. So, in general, be aware of your packages. Try to read the package information before upgrading it. From this determine how cautious you need to be while upgrading it. Pitfall when upgrading rpm There are a couple of problems with upgrading rpm that you should be aware of. rpm isn't just a frontend program, it is also a library and a backend. Other programs might be dependent on it. In particular, if you have a graphical frontend to rpm it will be dependent on it. Upgrading rpm can cause a conflict between it and any other program which depends on it. rpm will run fine after the upgrade but the other application(s) might stop running. Also, packages that were built with the older version of rpm might not be compatible with the new version of rpm and so it might not be able to extract the files in the package. There can be an incompatibility between the new rpm and older rpm packages. For these reasons, I recommend that you hold off upgrading rpm a long as you can. It will not hurt anything to wait, but it could be slightly harmful if you do not. 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 dependency errors. In that case, the files that rpm is looking for are in place 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 dependencies --nodeps or even --force it to stop complaining. Full speed ahead Once you get through the base packages, upgrading will start to go quicker. Soon you will get in the habit of how cautious you need to be. As things get upgraded, you'll start to feel the gratification and excitement 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 backing up 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 configuration files because the file format hasn't changed in the new version. The directories /etc and /home contain the majority of the configuration files. There are some more configuration files to merge once you're done with those. rpm has a feature of saving backup copies of the configuration files that it replaces. It will do this only when it can not merge the files on its own. 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, as necessary. Also, when rpm replaces a file that wasn't installed with rpm , the original will be saved with ".rpmorig" added to the end of the filename. Find those files and merge them with their replacements, as necessary. 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 doesn'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 lose heart. In general, the configuration files which haven't been changed since they were originally installed on your system shouldn't need to be merged by hand. For the most part, the only time configuration files will need to be merged by hand is when there are major changes to their format, done by the program author. That should not happen often. But if there were configuration files on your system that had large changes from the default, 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 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 are not needed 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. The database is accurate in saying that there are duplicate packages. 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 your system winds up with all of the new versions of the files. Eventually you will probably want to correct the redundancy, though, in order to save hard drive space and avoid complicating the dependencies. 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
rpm command line tips Why do I need to read this when I'm using a graphical frontend for rpm? Throughout the HOWTO you have seen some tips on how to use rpm at the command line. This section adds additional tips. A graphical frontend to rpm is very convenient but it doesn't necessarily offer the power and versatility of the command line. For that reason, you might want to read this section. This section gives some further explanation of how to use the commands mentioned in the HOWTO and it adds some more examples. I made the mistake of upgrading the rpm package before upgrading my frontend. That caused an incompatibility between the two and I couldn't run the frontend anymore. Since there were many libraries and other programs to upgrade before I would have a chance to upgrade the frontend I was forced to rely on the command line to do the rest of the upgrading. This was inconvenient for me. What follows are some suggestions to help you if you run into this pitfall too, and have to use the command line. See . Query the package summary information bash$ rpm -qi packagename qi is the basic parameter to read the package descriptions and some other fields. Querying the information is generally the first query that you perform. To look at the information from all of the packages, add an 'a' to the parameter. This will produce lots of information that can be used to examine the packages on your system. Redirect the output to a file and use grep or a text editor to find text in the file. You might want to search for all of the packages named with a certain sub-string, all the packages of a Distribution, all of the GPL licensed packages, etc. bash$ rpm -qia > allinfo If you want to apply the query information command to an rpm file, add a ' ' p ' to the parameters. bash$ rpm -qip package-filename .rpm List the package contents bash$ rpm -ql packagename If you need to list all of the files belonging to a package, this is the query you will use. This query is helpful if you want to know which files to back up before a crucial upgrade. Identify which package a file belongs to bash$ rpm -qf /foopath/foofile If you know a file's name and location and you need to know which package it belongs to, then this is the query that you want to use. Summarize a group bash$ rpm -qg groupname The grouping arranges the various packages into a hierarchy. This reveals one branch of that hierarchy to you. This can be useful when looking for packages of a certain category, the "System/Base" packages for instance. List dependencies bash$ rpm -qp --requires package filename When you want to know the dependencies of a package file this command will produce a list for you. You will have to satisfy these dependencies before installing the package because they are required by the package. Suggestions for package order This is the order that I installed the packages on my system, as an example for you. Don't think that you have to follow this list exactly. Your dependencies could require something a little different. The order you follow can have lots of variations from this list. This is just a guide to give you a good start. Note that not all of these package are GPL licensed. Order of the new packages glib libjpeg libstdc++-compat libpwdb glib-devel glibc-localedata libz libmng qt2-nsplugin qt2-xt gd gd-devel gdbm gdbm-devel gdbm-devel-static libpam libpam-devel bzip2 modutils ext2fs ext2fs-devel ext2fs-devel-static qt2-opengl qt2-qimgio ldp ldp-en-html ldp-en-ascii howto howto-en-ascii howto-en-html glibc ------kernel dependencies-------- gcc binutils util-linux e2fsprogs ppp -------------kernel-------------- kernel include linux source kernel binary any additional kernel modules --------------------------------- qt qt-opengl qt-qimgio qt-tutorial qt-doc-html qt-examples qt-devel qt2 qt2-devel-static qt2-devel qt2-doc-html qt2-examples qt2-tutorial jade ncurses cracklib libstdc++ gcc-doc libtiff libtiff-devel libpng libpng-devel libpng-devel-static libtiff-devel-static mm mm-devel SysVinit SysVinit-scripts net-scripts OpenLinux setup DEV OpenLinux-keys bool cgetty cpio PHI PHI-data bdflush coas2 fbset fileutils grep kbd lisa sed setserial sysklogd tar termcap utempter which gtk+ gtk+-perl imlib imlib-devel mesa mesa-devel xpm xpm-devel libpwdb-devel libtool libcap libcap-devel sh-utils freetype slang slang-devel libident-devel libjpeg-devel libz-devel libz-devel-static popt imap-devel isp-devel gettext freetype-devel kdelibs-devel cleandir logrotate fdutils hdparm isapnptools pciutils tcpdump adduser rsync wget dosemu aumix libmikmod libmikmod-devel tiff-utils transfig gdb gdb-doc expect expect-devel ppp-devel Glide afio compat-ncurses db dhcp doc-devguide-html doc-install-html doc-sag-html doxygen dump freetype2 freetype2-devel libstdc++-devel libstdc++-devel-static giftrans jikes eject diffutils gnupg gpm gpm-devel gpm-devel-static lsof m4 m4-examples mktemp ncompress strace wdiff dialog col-tools ipx net-tools readline readline-devel bc readline-devel-static netkit-base netkit-ftp netkit-rsh netkit-telnet pilot-link pilot-link-devel ed vim recode sharutils enscript psutils texinfo LSM copyrights faq fhs ghostscript-doc mailcap mimetypes mtabase screen gzip unarj unzip zip zoo bzip2-devel grub lilo file fatfs findutils mkisofs mtools am-utils rstatd procps psmisc bash bash2 tcsh at crontabs ktzset time vixie-cron zoneinfo imap procmail nis-client tcp_wrappers xntp apache gnuplot apache-devel autoconf automake bin86 bison byacc dejagnu flex gawk gawk-doc gperf indent make mawk nasm patch rcs cvs cvs-doc-ps ncftp less gv mailx info doc-install-html glib-devel-static glibc-devel glibc-devel-static iptables iptables-doc ipxripd ispell ispell-english jpeg-utils kernel-addon lha libIDL libgif a2ps libogg libkwave libmimelib libminimagick libqwsprite libgif-devel libgif-devel-static libjpeg-devel-static libmimelib-devel libmimelib-devel-static libmng-devel libmng-devel-static libpwdb-devel-static libsidplay libsigc++ libsigc++-devel libsigc++-examples libsmallrpc-devel libuulib libuulib-devel libuulib-devel-static libvorbis libxml lilo-doc lilo-doc-ps logcheck ltrace macutils mc mc-doc mesa-devel-static mgetty mikmod mm-devel-static mod_backhand minicom openssl man-pages perl perl-add perl-cgi perl-examples perl-man perl-modules perl-pod python python-devel python-doc python-eclass python-tk mutt webmin lynx plugger fetchmail tcl tcl-devel tclX tclX-devel tix tix-devel tk tk-devel tcl-devel-static tcp_wrappers-devel tk-devel-static binutils binutils-cross kdevelop-c_c++_ref kdelibs kdelibs-doc groff groff-dvi groff-misc textutils rpmcompat-devel groff-ps kdoc netpbm netpbm-devel nfs nfs-lockd portmap-safer portsentry traceroute-safer vim-X11 vim-help gimp-data teTeX teTeX-font teTeX-tex jadetex sgml-common docbook-dtd41-sgml docbook-dtd41-xml sgml-tools mysql mysql-client mysql-devel openslp openldap openldap-devel pam_ncp pam_ldap cups cups-client qtlinguist teTeX-doc xmms mpeglib mscompress mt-st nss_ldap openmotif parted slocate XFree86-server XFree86-libs XFree86-SVGA XFree86-VGA16 XFree86-Mach64 XFree86-config XFree86-fonts-75dpi XFree86-contrib XFree86-fonts-scale XFree86-addons XFree86-fonts XFree86-imake XFree86-programs XFree86-setup XFree86-twm XFree86-xterm XFree86-xsm XFree86-devel XFree86-devel-prof XFree86-devel-static XFree86 XFree86-Xvfb XFree86-fonts-cyrillic XFree86-fontserver acpid adjtimex bonnie++ libaudiofile libaudiofile-utils kdelibs2 kdelibs2-devel kdelibs2-devel-static kdelibs2-doc libao libkdegames lrzsz rpm rpm-devel kdebase2 kdebase2-opengl kdepasswd kdeapps kdebindings2 kdecoas kdesdk2 kdestudio kdeconfig kpackage xmms-devel korganizer ksaferppp ghostscript-fonts ghostscript cervisia kdevelop ddd ddd-doc kdbg ImageMagick ImageMagick-devel hwprobe kviewshell kdvi qtcups libsasl sendmail cupdate-console cupdate linux-kernel-binary midi-instruments SDL htdig arts ark cscope doctool docbook-style-dsssl doctool-meta ethereal fetchmailconf ipchains iptables-doc-ps tidy tripwire tmake xemacs-base xemacs-emacs-link xemacs-icons karm kcalc kdialog kedit kfind kfloppy kghostview khexedit khotplug kmail knode knotes koffice-libs kspread koffice-filters konvert kpm ksirc ksystemsnapshot ktimemon opera kups kwave kword perl-SGMLSpm psgml quanta sendmail-cf sendmail-doc stunnel tcsh-doc-html teTeX-dvi xemacs-mule xmms-arts xmms-crossfade xmms-infinity xmms-kj xmms-liveice xmms-midi xselection xterm-color xtoolwait samba samba-doc kscd XFree86-server-modules mpeglib_artsplug nw-eps-icons sgmltools-lite htmldoc expat libxml2 libxml2-devel libxslt xpdf XFree86-config-eg groff-gxditview gv-doc-html klpq mod_perl mod_ssl nedit usbutils kcharselect pgg man buildkernel samlib util-Linux reiserfs-utils docbook-dtd30-sgml docbook-dtd31-sgml isp gtk+-devel gtk+-devel-static gimp Lost packages between Caldera 2.4 and 3.1 Just for the sake of curiosity, here are the packages that got lost between the old distribution and the new. XFree86-misc Xaw-3dlook Xaw3d Xaw3d-devel acroread drdos-hdimage-eval jdk kautorun kde-translated-docs kdegraphics kdelibdocs kdemultimedia kdenetwork kdesupport kdesupport-devel kdethemes kdeutils kpilot lesstif lesstif-devel libc5 mico-devel mico-examples rvplayer svgalib svgalib-devel xemacs-lispsource xemacs-packages xforms xforms-devel xv Upgrade tools from the text, plus others ncftp Here are some basic commands for the ncftp command prompt, which you will find useful when downloading. Set ncftp for binary transfers with binary . (This command isn't necessary because binary is the default transfer type.) ncftp> binary There are commands to change through the local and remote directories. ncftp> lcd directoryname ncftp> cd directoryname Commands that list files of the local and remote directories. ncftp> lls wildcard-filename ncftp> ls wildcard-filename Set a named bookmark for the server and directory once you've connected to it, so that it will be easy to open it the next time. ncftp> bookmark bookmarkname Open that bookmark by its name. ncftp> open bookmarkname get files using a wildcard file specification for the filename. Use the background version of the command if you would like. ncftp> get wildcard filename ncftp> bgget wildcard filename Let ncftp find the files in your working directory and prompt you if you'd like to [ [ O ] verwrite, [ S ] kip, or [ R ] esume the download of that file. Turn off the auto-resume feature in order to enable this feature. ncftp> set auto-resume no Here is the ncftp home page : http://www.ncftpd.com/ kpackage Excellent KDE front end for rpm . All of the packages get arranged into a nice, graphical, hierarchical tree. Satisfied and unsatisfied dependencies are identified. Single or multiple packages can installed, upgraded or uninstalled. Operations can be tested first. The replacepkgs and replacefiles switches are available. FTP installs are seamlessly integrated. There is support of package types other than rpm. Download a copy from : http://www.general.uwa.edu.au/u/toivo/kpackage/doc/installation.html#HOW-TO-OBTAIN-KPACKAGE tomsrtbt Linux on a floppy, in case the Linux on your hard drive isn't running. Its home page is http://www.toms.net/rb/ 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 maintenance on your hard drive in case the installed Linux 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! Look for other virtual consoles 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! Look through the consoles again until you find a prompt. 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 new directory to used as a mount point. Mount a partition from the hard drive that you want to modify. Mount it under that mount point just created. ls Listing out the package files and comparing them to what you have installed is how you can keep track of your progress. This is a standard Linux command. If you don't recognize it, then this HOWTO is too advanced for you. cp Use cp to make backups of crucial files before they are upgraded, in case you find that the upgrade didn't work for whatever reason. If you don't recognize this command, then this HOWTO is too advanced for you. glint Glint is an X program, made to be a frontend for rpm. There are some instructions for Glint from Red Hat's web site. parted GNU's partitioning tool for creating, moving, copying and resizeing partions. Disk Drake (Mandrake) Partitioning from Mandrake Linux . fips (DOS) Used for non-destructive partitioning of your hard drive. Included in most distribution's installation CDs. Try looking under a tools sub-directory on your installation CD. The author was Arno Schaefer. You can download a copy from : http://www.igd.fhg.de/~aschaefe/fips/fips20.zip The licensing is GPL. Most Linux distributions carry it under the /dostools , /dosutils or tools directory in the primary cd. apt and dpkg This is Debian's method of download and upgrade. I've heard that this is very good compared to rpm . The programs are : apt and dpkg . Here is a presentation on using them : http://www.cinlug.org/education/Debian_Packaging/page1.html This is the HOWTO for apt : http://www.debian.org/doc/manuals/apt-howto/index Disk Druid (partitioning from Red Hat) Used to partition your hard drive. It is part of Red Hat's installation program. Lizard (Caldera's graphical installation tool) An installation program, used for partitioning, installing, etc. Lisa (Caldera's console based installation tool) A console based installation program. Caldera Upgrader Caldera's graphical, automated, upgrade program. It didn't work for me. PHI An automated, console based, upgrade program from Caldera. Other standard ones These programs are standard Linux commands : mount top bash touch df sort sed diff and less . grub is a standard replacement for the lilo bootloader. kpm is a KDE replacement for the top process displayer. &GFDLDOC; Bibliography Referenced Documents "Upgrading Your Linux Distribution mini-HOWTO" Greg Louis 1996 Dynamicro Consulting Limited 6 June 1996 v1.11 The LDP has an online copy that you can refer to "RPM+Slackware Mini-Howto" Dave Whitinger 1998 Dave Whitinger 13 April 1998 v1.3 The LDP has an online copy that you can refer to "RPM HOWTO" Donnie Barnes 1999 Red Hat, Inc. V3.0 3 November 1999 The LDP has an online copy that you can refer to rpm(8) (a man page) Marc Ewing Jeff Johnson Erik Troan 22 December 1998 Red Hat Software "Linux Installation Strategies mini-HOWTO" Tobby Banerjee 1.0.1 2001-05-02 The LDP has an online copy that you can refer to "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 Red Hat has an online copy that you can refer to Linux Partition HOWTO Tony Harris Kristian Koehntopp Revision 3.3 10 July 2001 The LDP has an online copy that you can refer to ncftp(1) Man page 3.0.2 Maximum RPM 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 The LDP has an online copy that you can refer to Linux Swap Space Mini-HOWTO Rahul U. Joshi v1.42 18 January 2000 2000 Tim Bynum The LDP has an online copy that you can refer to File Systems-HOWTO.html Martin Hinner 1999 Martin Hinner Version 0.7.5 22 August 2000 The LDP has an online copy that you can refer to