Обсуждение: Strange problem upgrading to 7.0.3x
Ever since I upgraded to 6.5.2 I've had problems upgrading to the 7.x series. I'm running Red Hat 6.1 (2.2.17 kernel) on this box. Now I'm trying to upgrade to 7.0.3 via the rpm. When I tried both the freshen (-F) and upgrade (-U) switches, I found a failed dependency: /lib/gcc! and a bunch of complaints that 6.5.2 needed some files being replaced. So, the attempt failed. I manually plucked all traces of the old 6.5.2 from the system and tried a regular install: [root@salmo rshepard]# rpm -ivh postgresql-7.0.3-1.i386.rpm error: failed dependencies: /lib/cpp is needed by postgresql-7.0.3-1 [root@salmo rshepard]# rpm -ivh --force postgresql-7.0.3-1.i386.rpm error: failed dependencies: /lib/cpp is needed by postgresql-7.0.3-1 Very strange! I _have_ /lib/cpp (for I've used it to build many applications): [root@salmo rshepard]# ls -l /lib/cpp lrwxrwxrwx 1 root root 53 Nov 21 1999 /lib/cpp -> ../usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/cpp* So, can someone please explain to me why the 7.0.3-1 package complains that /lib/cpp isn't there when it is? FWIW, I got the same error when I tried using the --force switch with rpm. Something's screwy here. Thanks, Rich Dr. Richard B. Shepard, President Applied Ecosystem Services, Inc. (TM) Making environmentally-responsible mining happen. (SM) -------------------------------- 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Rich Shepard wrote: > So, can someone please explain to me why the 7.0.3-1 package complains > that /lib/cpp isn't there when it is? FWIW, I got the same error when I > tried using the --force switch with rpm. Something's screwy here. Use --nodeps to override dependencies. It is complaining because RPM apparently has no record of /lib/cpp -- rpm --rebuilddb may be needed. RPM's dependencies are not checked against the filesystem, but against the RPM database. You can verify this by executing 'rpm -qf /lib/cpp' -- see what it says. However, the error should not have occurred in the first place -- I guess a -2 RPMset is in order. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Wed, 15 Nov 2000, Lamar Owen wrote: > Use --nodeps to override dependencies. It is complaining because RPM > apparently has no record of /lib/cpp -- rpm --rebuilddb may be needed. > RPM's dependencies are not checked against the filesystem, but against > the RPM database. You can verify this by executing 'rpm -qf /lib/cpp' > -- see what it says. Lamar, I was hoping that you'd answer, and you did. And all I can say is, "d'uh!". I must have been more incapacitated by my head cold than I realized. Of course, the switch I've used before is "--nodeps", not "--force". And, I understand that the rpm database doesn't know about files installed from a tarball. > However, the error should not have occurred in the first place -- I > guess a -2 RPMset is in order. Whatever that is. :-) What threw me is that this is a Red Hat installation, and the compiler does some from a package. As I wrote, this is quite strange. But, ... I'll just go install it now. Thanks, Rich Dr. Richard B. Shepard, President Applied Ecosystem Services, Inc. (TM) Making environmentally-responsible mining happen. (SM) -------------------------------- 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
On Wed, 15 Nov 2000, Lamar Owen wrote: > However, the error should not have occurred in the first place -- I > guess a -2 RPMset is in order. This is getting more strange all the time. I grabbed the 7.0.3-2 rpms and tried to install them. Here's what I get: [root@salmo rshepard]# rpm -ivh postgresql-server-7.0.3-2.i386.rpm file /etc/rc.d/init.d/postgresql from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 file /usr/bin/initdb from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 file /usr/bin/initlocation from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 file /usr/bin/ipcclean from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 file /usr/bin/pg_passwd from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 file /usr/bin/pg_version from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 file /usr/bin/postgres from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 file /usr/bin/postgresql-dump from install of postgresql-server-7.0.3-2 conflicts with file from package postgresql-server-6.5.3-1 There is no /etc/rc.d/init.d/postgresql, nor any of the files in /usr/bin. I specifically removed them. Something, somewhere, has a record that 6.5.3-1 is installed, and I don't know where to look for it. Once getting past this mess, I assume that the install sequence is postgresql, postgresql-server, then the others I want (-python, -test, -tk, -devel). Yes? How strange! I'm sure there's a simple answer that I cannot see. Thanks, Rich Dr. Richard B. Shepard, President Applied Ecosystem Services, Inc. (TM) Making environmentally-responsible mining happen. (SM) -------------------------------- 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Rich Shepard <rshepard@appl-ecosys.com> writes: > There is no /etc/rc.d/init.d/postgresql, nor any of the files in /usr/bin. > I specifically removed them. Something, somewhere, has a record that 6.5.3-1 > is installed, and I don't know where to look for it. I know approximately zilch about RPMs, but I do see that the rpm command has a "rebuild database" option, which apparently refreshes its list of what's installed. Perhaps you need to run that (especially if you've been removing files manually rather than via rpm -e). regards, tom lane
On Thu, 16 Nov 2000, Tom Lane wrote: > I know approximately zilch about RPMs, but I do see that the rpm command > has a "rebuild database" option, which apparently refreshes its list of > what's installed. Perhaps you need to run that (especially if you've > been removing files manually rather than via rpm -e). Thanks, Tom. I had run 'rpm -e ...' after the upgrade option (rpm -U <package>) failed to upgrade the existing installation. I wonder, ... could the packages be built for a newer RH release than the 6.1 I have here? I think that the rpm package was updated and that could cause problems. Regardless, I'm rebuilding the package database now and I'll see if that makes a difference. Rich Dr. Richard B. Shepard, President Applied Ecosystem Services, Inc. (TM) Making environmentally-responsible mining happen. (SM) -------------------------------- 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Rich Shepard <rshepard@appl-ecosys.com> writes: > On Wed, 15 Nov 2000, Lamar Owen wrote: > > > However, the error should not have occurred in the first place -- I > > guess a -2 RPMset is in order. > > This is getting more strange all the time. I grabbed the 7.0.3-2 rpms and > tried to install them. Here's what I get: > > [root@salmo rshepard]# rpm -ivh postgresql-server-7.0.3-2.i386.rpm > file /etc/rc.d/init.d/postgresql from install of postgresql-server-7.0.3-2 You need to upgrade the package, not install it ("U" instead of "i") - if you try to have both installed at the same time, some files will overlap. -- Trond Eivind Glomsrød Red Hat, Inc.
Rich Shepard wrote: > On Thu, 16 Nov 2000, Tom Lane wrote: > > I know approximately zilch about RPMs, but I do see that the rpm command > > has a "rebuild database" option, which apparently refreshes its list of > > what's installed. Perhaps you need to run that (especially if you've > > been removing files manually rather than via rpm -e). > Thanks, Tom. I had run 'rpm -e ...' after the upgrade option (rpm -U > <package>) failed to upgrade the existing installation. The result of 'rpm -qa|grep postgres' would be educational here. > I wonder, ... could the packages be built for a newer RH release than the > 6.1 I have here? I think that the rpm package was updated and that could > cause problems. I can provide you with a set built on and by a RedHat 6.1 box to test to see if there are differences -- AFAIK, the 6.2 binaries work fine on 6.1. However, if this is not the case, then I can make 6.1 binaries available for download easy enough. What I would like to see is for someone to try to build the 7.0.3-2 SRPM on RedHat _5.2_ -- I no longer have a build system running that release. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > What I would like to see is for someone to try to build the 7.0.3-2 SRPM > on RedHat _5.2_ -- I no longer have a build system running that release. [ pokes at some spare boxen... ] I've got a RH 5.1 over in the corner, if anyone still cares. regards, tom lane
On Thu, 16 Nov 2000, Lamar Owen wrote: > The result of 'rpm -qa|grep postgres' would be educational here. I actually do understand the differences among -i (install) -U (upgrade) and -F (freshen). What I don't understand is why what _should_ work _isn't_ working. For example, as Lamar and others suggested: [root@salmo rshepard]# rpm -qa | grep postgres postgresql-server-6.5.3-1 postgresql-test-6.5.3-1 postgresql-7.0.3-2 "Aha, I said. The rpm database thinks that postgresql-server, and -test are still installed." Then I tried to erast the server: [root@salmo rshepard]# rpm -e postgresql-server-6.5.3-1 error reading information on service postgresql: No such file or directory execution of script failed Where this gets more interesting is that the first time I ran the rpm query postgresql-devel-6.5.3-1 also showed up. Running erase on that package came up with all sorts of errors because I had already removed /usr/include/pgsql/ and /usr/lib/pgsql/. But, when I ran the query again, -devel didn't show up. I just tried erasing -test, and found the same messages: cannot do it because the files or directories do not exist. But, now the query shows only -server (that is, -test is gone, too). But, I cannot replace the server. Let's see what happens if I try to upgrade the server ... it worked! I guess it was the problems with -devel and -test still being registered in the rpm database that made the difference. Next: re-starting postgres. Do I do this by invoking initdb? Here's what that did: [root@salmo rshepard]# initdb The program pg_id needed by initdb could not be found. It was expected at: /usr/bin/pg_id If this is not the correct directory, please start initdb with a full search path. Otherwise make sure that the program was installed successfully. Thanks, everyone. Getting closer here to a working postgres-7.0.3! Rich Dr. Richard B. Shepard, President Applied Ecosystem Services, Inc. (TM) Making environmentally-responsible mining happen. (SM) -------------------------------- 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
Rich Shepard wrote: > On Thu, 16 Nov 2000, Lamar Owen wrote: > > The result of 'rpm -qa|grep postgres' would be educational here. > [root@salmo rshepard]# rpm -qa | grep postgres > postgresql-server-6.5.3-1 > postgresql-test-6.5.3-1 > postgresql-7.0.3-2 > "Aha, I said. The rpm database thinks that postgresql-server, and -test are still > installed." Then I tried to erast the server: Ok, do the following steps: rpm -e --nodeps --noscripts -- force postgresql-server postgresql-test postgresql What is happening is that, since the uninstall scripts for server are not completing, the server uninstall is failing -- producing the results you have seen. Once you have verified with rpm -qa|grep postgres that there are no more postgresql RPM's on your system, then you will need to clean out the old 6.5.3 data directory (rm -rf /var/lib/pgsql). Now you should be able to install the new RPMset. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Fri, 17 Nov 2000, Lamar Owen wrote: > Once you have verified with rpm -qa|grep postgres that there are no more > postgresql RPM's on your system, then you will need to clean out the old > 6.5.3 data directory (rm -rf /var/lib/pgsql). > > Now you should be able to install the new RPMset. Thanks, Lamar. I upgraded the server package, and that appeared to work just fine. Then I installed the others. Is 'initdb' the proper way to restart everything, and creat a new /var/lib/pgsql? It's been a while since I worked with postgres, but I need to really dig into app development now. Thanks, Rich Dr. Richard B. Shepard, President Applied Ecosystem Services, Inc. (TM) Making environmentally-responsible mining happen. (SM) -------------------------------- 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
> I actually do understand the differences among -i (install) -U (upgrade) >and -F (freshen). What I don't understand is why what _should_ work _isn't_ >working. > > For example, as Lamar and others suggested: > >[root@salmo rshepard]# rpm -qa | grep postgres >postgresql-server-6.5.3-1 >postgresql-test-6.5.3-1 >postgresql-7.0.3-2 > > "Aha, I said. The rpm database thinks that postgresql-server, and -test >are still >installed." Then I tried to erast the server: > >[root@salmo rshepard]# rpm -e postgresql-server-6.5.3-1 >error reading information on service postgresql: No such file or directory >execution of script failed Note that last line: execution of script failed. Try running that same command with --force. The problem is that you manually deleted the files, or --force'd 7.0 to install, and now it can't figure out how to remove it from the database. >/usr/include/pgsql/ and /usr/lib/pgsql/. But, when I ran the query again, >-devel didn't show up. Evidently, enuf stuff was left that it was able to go all the way thru the script, so it was successfully removed. > Next: re-starting postgres. Do I do this by invoking initdb? Here's what >that did: > >[root@salmo rshepard]# initdb >The program pg_id needed by initdb could not be found. It was >expected at: > /usr/bin/pg_id >If this is not the correct directory, please start initdb >with a full search path. Otherwise make sure that the program >was installed successfully. > > Thanks, everyone. Getting closer here to a working postgres-7.0.3! Try uninstalling everything related to postgres that is now installed. Then remove /var/lib/pgsql and any data directories that may exist. Start from scratch. Oh, and as to order? I just installed them all together, like "rpm -ivh postgresql-7.0.3*" Rob Nelson rdnelson@co.centre.pa.us
Rich Shepard wrote: > Thanks, Lamar. I upgraded the server package, and that appeared to work > just fine. Then I installed the others. Is 'initdb' the proper way to > restart everything, and creat a new /var/lib/pgsql? It's been a while since > I worked with postgres, but I need to really dig into app development now. You can let the packaged initscript do it for you, as long as there is no previous database structure in place under /var/lib/pgsql -- you would want to remove everything below that dir EXCEPT the subdirs data and backups, as well as .bash_profile. Execute as root '/etc/rc.d/init.d/postgresql start' and it will both initdb and start the postmaster for you. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Fri, 17 Nov 2000, Robert D. Nelson wrote: > Try uninstalling everything related to postgres that is now installed. Then > remove /var/lib/pgsql and any data directories that may exist. Start from > scratch. Oh, and as to order? I just installed them all together, like "rpm > -ivh postgresql-7.0.3*" Thanks, Rob! I keep forgetting about the Microsoft approach: unload everything and start from scratch. That did it. Of course, I forgot the password for user "postgres", so I deleted and re-added that account. Then initdb wouldn't work because of ownership problems. The rpms installed /var/lib/pgsql as owned by root.root. I changed that to postgres.users but still had ownership problems. Turns out that the owner/group for for every file and directory under this was 26.26. I changed those, too, and initdb ran just fine. Postmaster was already running so it wouldn't start another instance. Many thanks, all! Now I'll get back to using the tool. Rich Dr. Richard B. Shepard, President Applied Ecosystem Services, Inc. (TM) Making environmentally-responsible mining happen. (SM) -------------------------------- 2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A. + 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com