First of all, thanks so much for replying! I would never have known to
try these things.
Secondly, unfortunately, I still haven't isolated the problem =/
On Sat, 11 Oct 2003 at 07:12 GMT, Oliver Elphick penned:
>
> First, try installing after doing:
>
> # export DEBCONF_DEBUG=developer
>
> because the value of the error code suggests a debconf error. If that
> doesn't help, get the preinst script as below; add set -x at line 2
> and run it (as root). Let me know where it stops. (You may have to
> extract the debconf files and load them into the debconf database -
> see debconf-devel(7) in the debugging section.)
Okay, I tried setting DEBCONF_DEBUG. Of course, I've never used that
before, so I don't know what the expected output would be, but I didn't
see anything that was obviously an error. The only thing that looked
slightly suspicious, because of the word "missing", was the following.
debconf (developer): starting /var/lib/dpkg/tmp.ci/config configure
6.5.3-23
debconf (developer): <-- SUBST postgresql/missing_conf MISSING
debconf (developer): --> 0
debconf (developer): <-- /etc/postgresql/pg_hba.conf
debconf (developer): <-- /etc/postgresql/pg_ident.conf
debconf (developer): <-- /etc/postgresql/postgresql.conf
debconf (developer): --> 30 question skipped
debconf (developer): <-- GO
subprocess pre-installation script returned error exit status 128
Note that the error status is 128, whereas before it was 20. I'd gotten
128 previously, but thought I'd fixed it by putting back
/etc/init.d/postgresql (for some reason I thought I needed to remove it
before installing, but comments in the preinst made it clear that it of
course needs that file to shut down the existing process).
Then I tried the -x business. -e was already set; I tried running
preinst with both "set -ex" and "set -e" and "set -x". Both ways, the
script actually completed and exited with return code 0. I also tried
running the script with argument "upgrade," to force it to try to stop
the existing postgres process -- the script still exited happily. I
also tried running apt-get after killing the existing postgres instance
manually -- no such luck.
The only thing that looks slightly wonky to me is this:
++ ps ax
++ grep postmaster
++ grep -v grep
++ awk '{print $1}'
+ pid=21492
21493
+ '[' -n '21492
21493' ']'
as the output to this:
pid=`ps ax | grep postmaster | grep -v grep | awk '{print $1}'`
if [ -n "${pid}" ]
... That's because pgsql on my system apparently starts two processes:
postgres 3903 1 0 11:40 pts/12 00:00:00 sh -c
/usr/local/pgsql/bin/postmaster -D /var/lib/postgres/data >
/var/log/postgres.log 2>&1
postgres 3904 3903 0 11:40 pts/12 00:00:00
/usr/local/pgsql/bin/postmaster -D /var/lib/postgres/data
But that doesn't really matter, as the script uses invoke-rc.d to kill
them, and that gets rid of both.
So now I'm really lost.
I would guess that the fact that the original install was from
postgresql's site source might be a problem -- after all, things are
installed in /usr/pgsql/gbin -- but the /etc/init.d script points to
that properly, and the preinst script seems to work fine on its own.
The existing database files are exactly where the debian installer would
put them.
Any further ideas?
If I run dpkg -i on the d/l'd package instead of running apt-get, will
it still attempt to convert my existing databases for me? I'm guessing
the answer is yes, but I want to make sure. Or is that totally silly,
since apt-get is just a frontend for the same tool?
--
monique
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
