Thread: 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