Bug report for Red Hat 5.2 install -- corruption of rpm databases (+ other install comments later) I have been running, updating, and administrating a slackware distribution for the last 3 years, but I thought it was time to replace my much-updated distribution by a coherent one with glibc, and I picked Red Hat 5.2. However, I ran into a severe problem with the Red Hat 5.2 install that I think you should be aware of. I was installing using the install boot disk copied from a $10 Red Hat CD distributed by our local LUG. As far as I can tell this CD is a snapshot of your ftp web site taken Oct 15 1998. ls -lt |head 10 on the RPMS directory gives: -r--r--r-- 1 root root 36065 Oct 15 00:43 TRANS.TBL -rw-r--r-- 2 root root 49437 Oct 15 00:28 initscripts-3.78-1.i386.rpm -rw-r--r-- 3 root root 6765 Oct 14 03:40 xinitrc-1.6-1.noarch.rpm -rw-r--r-- 3 root root 1563458 Oct 14 03:40 urw-fonts-1.0-3.noarch.rpm -rw-r--r-- 3 root root 139529 Oct 14 03:40 words-2-11.noarch.rpm -rw-r--r-- 3 root root 46789 Oct 14 03:40 swatch-2.2-3.noarch.rpm -rw-r--r-- 3 root root 147598 Oct 14 03:40 termcap-9.12.6-11.noarch.rpm -rw-r--r-- 3 root root 9033 Oct 14 03:40 timetool-2.3-7.noarch.rpm -rw-r--r-- 3 root root 6923 Oct 14 03:40 setuptool-1.0-1.noarch.rpm I don't think my hardware information matters much, but just in case I have a pentium-133, with 2 HDD and a CDROM drive all on a SCSI (ASUS SC200) bus. My video card is S3 trio64, and my monitor is the Sony Multiscan 15sfII. All the initial stages of the install (**custom class install**) went well (impressive compared to what I had to go through with slackware 3 years ago). However, I ran into severe trouble with the package installs. I had selected the following components: X, networking, tex, the extra documentation, and all aspects of programme development. However, this came to 285 Megabytes, and it was all supposed to fit into a 293 Megabyte partition that I had prepared with disk druid and which I had subsequently asked to be formatted and searched for bad blocks. I ran into severe trouble in the rpm databases as a result of me deselecting part/all of these components in an attempt to save disk space. In the next two paragraphs I will try and recreate for you as much as I remember about my package selection to give you some idea of the mixture of packages that caused the problem. (1) One comment I have is your install software should allow deselecting whole components. After I got to the selection stage and saw the huge number of packages involved, I went back to the components GUI and deselected everything but X, but it made no difference to the size. I then went back and even deselected X, and in desperation finally went two back to try and re-enter the component GUI. However, with everything deselected from that, your install softwareskipped right to the individual package GUI with the full 285 Megabytes still there. (2) I then deselected most of the individual packages from networking, tex, documentation, and programme development, and **also deselected some of the X packages I didn't think I would need** (afterstep was one, but there were several more including gtk+ and perhaps other X libraries). My thought was that if I deselected too much, the package software would catch it and install the packages my selected packages depended on. Some of the packages did notice there were other packages missing, and I vaguely recall a GUI where I confirmed that the required required extra packages should be installed. The admittedly odd combination of packages I had selected from the previous interactive process caused installation errors for the following packages: newt, the slang library, tcl, tk, xaw3d, xfree86-libs, and xpm. Nevertheless, I carried on to the finish, booted the system, and attempted to correct the package problems by re-installing using rpm. When I tried rpm -Va, it generated a scsi i/o error on reading (always reporting the same block somewhere on the disk (lun=1) where my new partition containing Red Hat was located). I got the identical error (including block number) whenever I tried to re-install any of the packages that had failed during the install phase, and I got **no** errors if I attempted to re-install packages that had no problems during the install phase.Although from the lun number I thought I had narrowed down the problem to have something to do with my hard disk, I did check the CD by copying certain of the "problem" packages (no i/o problems) and by comparing with the same packages at your ftp site (no differences). Thus, I doubt very much that I am the victim of media errors on the CD. I then copied all the rpm data bases in /var/lib/rpm to another path (no i/o errors), and rebuilt the rpm data base using the new path to the rpm data bases (no i/o errors). However, any attempt to deal with the "problem" packages using the rebuilt rpm data base always generated the i/o error. My tentative conclusions from all of these tests: there was no "real" read i/o error for any file associated with the rpm software or rpm packages. (I have never had any trouble with my SCSI disks, the partition was reformatted and tested for bad blocks as part of the install process, there were no i/o errors associated with the SCSI CD when I did things like "rpm -qil -p *.rpm", I copied all files I could think of in an attempt to find the "bad" file without success, and finally, it seems improbable to me that the first ever bad block on my disk happens to fall right in an area that is critical to rpm.) I believe the i/o error was generated by a corrupted rpm database somehow pointing to an incorrect disk block, and I believe this corrupted rpm data base was caused by the unusual combination of packages that I had selected. Once I had drawn this conclusion, I should have made a copy of the list of all installed packages for you to try for yourself, but I am afraid I foolishly lost this information (see below). I believe you could easily replicate the error by selecting X and deselecting afterstep and some X libraries such as gtk+ afterward. (I don't think there the problem could have been generated by the rest of the components because I largely removed all packages from those components. I reason the other components were probably okay because I removed virtually all of them so there would be no leftover dependencies to cause software troubles.) What I did instead was to try another fresh install on the same disk partition (that is why I don't have a list of the packages). This time I chose X alone and didn't deselect anything afterward. In 10 minutes I had a working system with X up and running, (and no rpm data base troubles). So all is well that ends well, but I thought I should let you know of the following two major issues: (1) the install software's inability to deselect whole components (I think this is an important problem that should be rectified). (2) the install software's running into "i/o" problems (which I think are associated with an rpm database that becomes corrupted) when certain individual X packages are de-selected after the whole X component was selected. There were several other minor problems I encountered that I should mention as well (3) The information for 100 dpi X fonts doesn't make complete sense because it has obviously been copied from the 75 dpi package information whose commentary refers to the higher-resolution 100 dpi package. (4) telnet, ftp, and probably other packages officially depend on the "inetd" package, but such a package does not exist and stops the installation of these packages from glint. After some investigation I found inetd was part of netkit-base. Once that was installed, telnet (and ftp) could be installed without difficulty. There is obviously some inconsistency here in the naming of the packages that should be straightened out. (5) I found the navigation of the GUI's for the install programme to be counter-intuitive. It is obviously a matter of personal taste and what your experience is with other GUI's, but selection by space bar rather than CR seemed strange to me. (In fact I found there was an undocumented feature where you could often *but not always* select by CR.) Also, I think navigation around the components of the displayed GUI should strictly be by the arrow keys without the tab confusing things. You might want to copy something like the arrangement that lynx has with its arrow navigation. Anyhow, my feeling is more thought needs to go into this. I kept stumbling over the current navigation, and I am usually pretty good about whipping around a GUI. (6) Xconfigurator is fine to get a lowest-common-denominator X configuration that works for almost everybody. However, once X is working how do you tune the configuration to get the maximum vertical refresh rate consistent with the resolution you have picked and the maximum horizontal frequency allowed by your monitor? As far as I can see xvidtune only plays with the pixel limits for fixed dot-clock frequency. What is needed is a fresh version of that programme that allows you to change the dcf if/when that is allowed by the video card (and most modern cards allow a variable dot clock). Such a programme would greatly improve the "saleability" of Linux. The impression left by Xconfigurator is you have to put up with a flickering display if you want to use RedHat Linux. Fortunately, I had the modelines left over from many X configuration experiments I had done by hand under slackware for my particular combination of videocard and monitor so I popped those into the X configuration file, and, voila, I had a good looking display again. (98 Hz vertical refresh definitely looks much better to my eyes than 72 Hz.) (7) When creating a user account under linuxconf, the sysadmin is asked to put in a new password for the user. But what if you mistype it or the user forgets it so you have to enter it at a later date? I could find nothing under linuxconf to allow the sysadmin to set a user password (except the submenu that only seems accessible when you first create an account). Despite the two major issues and the grab-bag of minor issues, you are to be congratulated on a fine distribution. Once I found a way to get around the show-stopping major issues, the installation was a breeze, and the subsequent configuration using linuxconf was nice also. rpm is great, and I also enjoyed using glint for the straightforward package installs. I will dual-boot for a while to my old distribution for things I haven't configuredyet, but I can forsee I will quickly become attached to the new distribution because of its enhanced ease of administration and package upgrading. All the best, Alan W.Irwin
Thank you for your input on this matter. We are working to improve the install process regarding detection of free disk space so that these things will not happen. This should hopefully be alot better in our upcoming releases of Red Hat.