Thread: Installation trouble
I'm having difficulty installing 8.0.4. Server is SuSE 8.2 without PG installed. However some client libraries are Yast installed due to dependency reconciliation. I'm doing the standard install (./configure, make, make install) and have created the postgres user and appropriate data directory but when I run: initdb /var/lib/pgsql/data I get: initdb: file "/usr/share/postgres.bki" does not exist This means you have a corrupted installation or identified the wrong directory with the invocation option -L. Running: initdb -L /usr/local/pgsql/share/ /var/lib/pgsql/data Looks pretty good at first but fails at: creating conversions ... FATAL: could not access file "$libdir/ascii_and_mic": No such file or directory Reports from pg_config: --libdir: /usr/lib --bindir: /usr/bin --configure: -blank- --includedir-server: /usr/include/server --includedir: /usr/include --pgxs: /usr/lib/pgxs/src/makefiles/pgxs.mk --pkglibdir: /usr/lib Note, the directories shown for libdir, bindir, includedir and such are not where the files were actually installed. Now I could just start shuffling files around till things work but since I've installed/upgraded many PG installations without this difficulty I suspect there is something basic that I'm missing that is causing all of the trouble. Suggestions? Cheers, Steve
Steve Crawford <scrawford@pinpointresearch.com> writes: > Note, the directories shown for libdir, bindir, includedir and such > are not where the files were actually installed. > > Now I could just start shuffling files around till things work but > since I've installed/upgraded many PG installations without this > difficulty I suspect there is something basic that I'm missing that > is causing all of the trouble. Suggestions? I think you have the wrong binaries in your PATH. Set thing up so /usr/local/pgsql/bin comes before the other stuff. -Doug
Steve Crawford wrote: >I'm having difficulty installing 8.0.4. Server is SuSE 8.2 without PG >installed. However some client libraries are Yast installed due to >dependency reconciliation. > >I'm doing the standard install (./configure, make, make install) and >have created the postgres user and appropriate data directory but >when I run: > > > The below looks to me like you have more then one version installed... try: >initdb /var/lib/pgsql/data > > /usr/local/pgsql/bin/initdb /var/lib/pgsql/data Sincerely, Joshua D. Drake -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Steve Crawford wrote: >I'm having difficulty installing 8.0.4. Server is SuSE 8.2 without PG >installed. However some client libraries are Yast installed due to >dependency reconciliation. > >I'm doing the standard install (./configure, make, make install) and >have created the postgres user and appropriate data directory but >when I run: > > Sorry I hit send before I was ready. If you used the exact command above then everything will be in /usr/local/pgsql ... Which means from the below it looks like you have more then one install of PostgreSQL. Try: /usr/local/pgsql/bin/initdb --no-locale -D /var/lib/pgsql/data Sincerely, Joshua D. Drake >initdb /var/lib/pgsql/data > >I get: > >initdb: file "/usr/share/postgres.bki" does not exist >This means you have a corrupted installation or identified >the wrong directory with the invocation option -L. > >Running: > >initdb -L /usr/local/pgsql/share/ /var/lib/pgsql/data > >Looks pretty good at first but fails at: > >creating conversions ... FATAL: could not access file >"$libdir/ascii_and_mic": No such file or directory > >Reports from pg_config: >--libdir: /usr/lib >--bindir: /usr/bin >--configure: -blank- >--includedir-server: /usr/include/server >--includedir: /usr/include >--pgxs: /usr/lib/pgxs/src/makefiles/pgxs.mk >--pkglibdir: /usr/lib > >Note, the directories shown for libdir, bindir, includedir and such >are not where the files were actually installed. > >Now I could just start shuffling files around till things work but >since I've installed/upgraded many PG installations without this >difficulty I suspect there is something basic that I'm missing that >is causing all of the trouble. Suggestions? > >Cheers, >Steve > >---------------------------(end of broadcast)--------------------------- >TIP 6: explain analyze is your friend > > -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Friday 28 October 2005 19:18, you wrote: > Try: > > /usr/local/pgsql/bin/initdb --no-locale -D /var/lib/pgsql/data OK. That works (even without the --no-locale). Which makes me puzzled and worried.The initdb I used and the one I used earlier are identical (as verified by the fact that I copied the binaries from /usr/local/pgsql/bin to /usr/bin and by checking with diff and by searching the entire drive for all versions of the PG binaries - checks shown below). Is postgresql (or some parts thereof) now using relative pathing and has that behavior changed? I don't recall having this problem in the past. Running /usr/bin/pg_config --bindir returns /usr/bin while /usr/local/pgslq/bin/pg_config --bindir returns /usr/local/pgsql/bin even though the two binaries are identical. Looks like the lesson is that if you want the programs in /usr/bin, use symbolic links rather than cp. Cheers, Steve for x in * ; do md5sum /usr/local/pgsql/bin/$x /usr//bin/$x ; done c9bf803d2ee9960d7435fff80ec35737 /usr/local/pgsql/bin/clusterdb c9bf803d2ee9960d7435fff80ec35737 /usr//bin/clusterdb cb62a668ffa7048907d03a6432498424 /usr/local/pgsql/bin/createdb cb62a668ffa7048907d03a6432498424 /usr//bin/createdb b9acda85ac4797ecd8b4d1de4949e9fa /usr/local/pgsql/bin/createlang b9acda85ac4797ecd8b4d1de4949e9fa /usr//bin/createlang 3329c93c9bda413b89dfe2c717624cf3 /usr/local/pgsql/bin/createuser 3329c93c9bda413b89dfe2c717624cf3 /usr//bin/createuser d22022dd17c80867b8ff14efbd576c91 /usr/local/pgsql/bin/dropdb d22022dd17c80867b8ff14efbd576c91 /usr//bin/dropdb 675ce5ebbdf3b9bec3a96bd3040e3d4e /usr/local/pgsql/bin/droplang 675ce5ebbdf3b9bec3a96bd3040e3d4e /usr//bin/droplang a9cc5a285245332504aeae230df3aa21 /usr/local/pgsql/bin/dropuser a9cc5a285245332504aeae230df3aa21 /usr//bin/dropuser ce18d494254b3e003fe08f8e73041bc0 /usr/local/pgsql/bin/ecpg ce18d494254b3e003fe08f8e73041bc0 /usr//bin/ecpg 691f1c766d54b8a535936fbdb9591c92 /usr/local/pgsql/bin/initdb 691f1c766d54b8a535936fbdb9591c92 /usr//bin/initdb eda7372ae2a01504da905b3706ce70b9 /usr/local/pgsql/bin/ipcclean eda7372ae2a01504da905b3706ce70b9 /usr//bin/ipcclean 7682bd875fcf3c5b57d5e89bc3f57213 /usr/local/pgsql/bin/pg_config 7682bd875fcf3c5b57d5e89bc3f57213 /usr//bin/pg_config 72bb7c22ff14ef9f8dfe140cdcd9341f /usr/local/pgsql/bin/pg_controldata 72bb7c22ff14ef9f8dfe140cdcd9341f /usr//bin/pg_controldata 7549b3387bdef3022c63bc0c19098a8a /usr/local/pgsql/bin/pg_ctl 7549b3387bdef3022c63bc0c19098a8a /usr//bin/pg_ctl 6c1134ba9bbb195a1ff3ad65fcc98917 /usr/local/pgsql/bin/pg_dump 6c1134ba9bbb195a1ff3ad65fcc98917 /usr//bin/pg_dump 53c9d9fccd5d466a0976cddbec68b85c /usr/local/pgsql/bin/pg_dumpall 53c9d9fccd5d466a0976cddbec68b85c /usr//bin/pg_dumpall 6da2da5460ee64301bdbabd7ba210962 /usr/local/pgsql/bin/pg_resetxlog 6da2da5460ee64301bdbabd7ba210962 /usr//bin/pg_resetxlog 178c671867afe5483c1127a7db073955 /usr/local/pgsql/bin/pg_restore 178c671867afe5483c1127a7db073955 /usr//bin/pg_restore b64c8fa49fca11cf1340fdee6e67a75c /usr/local/pgsql/bin/postgres b64c8fa49fca11cf1340fdee6e67a75c /usr//bin/postgres b64c8fa49fca11cf1340fdee6e67a75c /usr/local/pgsql/bin/postmaster b64c8fa49fca11cf1340fdee6e67a75c /usr//bin/postmaster cc59b501ec66f39c07ea6a5862dda6dc /usr/local/pgsql/bin/psql cc59b501ec66f39c07ea6a5862dda6dc /usr//bin/psql d4abcd0d876d16f38ba5fc76d4f7de64 /usr/local/pgsql/bin/vacuumdb d4abcd0d876d16f38ba5fc76d4f7de64 /usr//bin/vacuumdb
Steve Crawford <scrawford@pinpointresearch.com> writes:
> Is postgresql (or some parts thereof) now using relative pathing and
> has that behavior changed?
As of 8.0 we attempt to determine the libdir, sharedir etc as relative
to the location of the executable. So you can't just "cp" the PG
executables to somewhere else without also copying the associated
support files into parallel directories. I believe symlinking the
executables will work fine though (ie, we look through the symlink
before doing the relative-path calculation).
regards, tom lane
On Saturday 29 October 2005 22:33, Tom Lane wrote: > Steve Crawford <scrawford@pinpointresearch.com> writes: > > Is postgresql (or some parts thereof) now using relative pathing > > and has that behavior changed? > > As of 8.0 we attempt to determine the libdir, sharedir etc as > relative to the location of the executable. So you can't just "cp" > the PG executables to somewhere else without also copying the > associated support files into parallel directories. I believe > symlinking the executables will work fine though (ie, we look > through the symlink before doing the relative-path calculation). Yes, the symlinking did appear to work fine. Thanks for the confirmation that it is an acceptable option. Cheers, Steve
On Monday 31 October 2005 08:00, Steve Crawford wrote: >>... believe symlinking the executables will work fine though (ie, we > > look through the symlink before doing the relative-path > > calculation). > > Yes, the symlinking did appear to work fine. Thanks for the > confirmation that it is an acceptable option. Symlinks work fine as long as I run the generic "initdb /var/lib/pgsql/data" but if I try to ensure the C locale I keep running up against: FATAL: XX000: failed to initialize lc_messages to "" This happens with: initdb --no-locale /var/lib/pgsql/data and export LC_ALL="C" ; initdb /var/lib/pgsql/data and initdb --locale=C /var/lib/pgsql/data and initdb --locale=C --lc-messages=en_US /var/lib/pgsql/data Other ideas? Cheers, Steve
Steve Crawford <scrawford@pinpointresearch.com> writes:
> if I try to ensure the C locale I
> keep running up against:
> FATAL: XX000: failed to initialize lc_messages to ""
We've seen a few reports of this before, but never been able to identify
the cause. What platform are you running on, exactly? Did you build
your own PG executables; if not, where did you get them from?
regards, tom lane
On Monday 31 October 2005 13:00, Tom Lane wrote: > Steve Crawford <scrawford@pinpointresearch.com> writes: > > if I try to ensure the C locale I > > keep running up against: > > FATAL: XX000: failed to initialize lc_messages to "" > > We've seen a few reports of this before, but never been able to > identify the cause. What platform are you running on, exactly? > Did you build your own PG executables; if not, where did you get > them from? Vanilla built from source (./configure ; make ; make install). Platform: SuSE Linux 8.2 (i586) uname -a: Linux web2 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003 i686 unknown unknown GNU/Linux Selected environment variables: CPU=i686 HOME=/var/lib/pgsql HOSTTYPE=i386 LANG=en_US LC_COLLATE=POSIX LOGNAME=postgres MACHTYPE=i686-suse-linux OSTYPE=linux PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games I did not install PostgreSQL when the machine was originally built _but_ certain client libraries are installed by YaST to satisfy dependencies. I do not believe any server-related libraries were installed. I also tried substituting the new libraries for the old as well as removing them from /usr/lib entirely without effect. For completeness and guc.c line numbers, here's the whole output: postgres@web2:~> initdb --no-locale /var/lib/pgsql/data The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory /var/lib/pgsql/data ... ok creating directory /var/lib/pgsql/data/global ... ok creating directory /var/lib/pgsql/data/pg_xlog ... ok creating directory /var/lib/pgsql/data/pg_xlog/archive_status ... ok creating directory /var/lib/pgsql/data/pg_clog ... ok creating directory /var/lib/pgsql/data/pg_subtrans ... ok creating directory /var/lib/pgsql/data/base ... ok creating directory /var/lib/pgsql/data/base/1 ... ok creating directory /var/lib/pgsql/data/pg_tblspc ... ok selecting default max_connections ... 10 selecting default shared_buffers ... 50 creating configuration files ... ok creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL: XX000: failed to initialize lc_messages to "" LOCATION: InitializeGUCOptions, guc.c:2389 child process exited with exit code 1 initdb: removing contents of data directory "/var/lib/pgsql/data" Cheers, Steve
Steve Crawford wrote: > On Monday 31 October 2005 13:00, Tom Lane wrote: >>Steve Crawford <scrawford@pinpointresearch.com> writes: >>>if I try to ensure the C locale I >>>keep running up against: >>>FATAL: XX000: failed to initialize lc_messages to "" >>We've seen a few reports of this before, but never been able to >>identify the cause. What platform are you running on, exactly? >>Did you build your own PG executables; if not, where did you get >>them from? > > Vanilla built from source (./configure ; make ; make install). > > Platform: SuSE Linux 8.2 (i586) > > uname -a: Linux web2 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003 i686 > unknown unknown GNU/Linux > > Selected environment variables: > CPU=i686 > HOME=/var/lib/pgsql > HOSTTYPE=i386 > LANG=en_US > LC_COLLATE=POSIX > LOGNAME=postgres > MACHTYPE=i686-suse-linux > OSTYPE=linux > PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games > > I did not install PostgreSQL when the machine was originally built > _but_ certain client libraries are installed by YaST to satisfy > dependencies. I do not believe any server-related libraries were > installed. > > I also tried substituting the new libraries for the old as well as > removing them from /usr/lib entirely without effect. > > For completeness and guc.c line numbers, here's the whole output: > postgres@web2:~> initdb --no-locale /var/lib/pgsql/data > The files belonging to this database system will be owned by user > "postgres". > This user must also own the server process. > > The database cluster will be initialized with locale C. > > fixing permissions on existing directory /var/lib/pgsql/data ... ok > creating directory /var/lib/pgsql/data/global ... ok > creating directory /var/lib/pgsql/data/pg_xlog ... ok > creating directory /var/lib/pgsql/data/pg_xlog/archive_status ... ok > creating directory /var/lib/pgsql/data/pg_clog ... ok > creating directory /var/lib/pgsql/data/pg_subtrans ... ok > creating directory /var/lib/pgsql/data/base ... ok > creating directory /var/lib/pgsql/data/base/1 ... ok > creating directory /var/lib/pgsql/data/pg_tblspc ... ok > selecting default max_connections ... 10 > selecting default shared_buffers ... 50 > creating configuration files ... ok > creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL: > XX000: failed to initialize lc_messages to "" > LOCATION: InitializeGUCOptions, guc.c:2389 > child process exited with exit code 1 > initdb: removing contents of data directory "/var/lib/pgsql/data" > > Cheers, > Steve > Progress Report: Started over. A drive failure prevented the machine from rebooting so I started from scratch with a new drive and a fresh install of SuSE 8.2 (Linux web2 2.4.20-4GB #1 Mon Mar 17 17:54:44 UTC 2003 i686 unknown unknown GNU/Linux). This time I PostgreSQL 8.1.0 (previously 8.0.3) compiled from source with vanilla ./configure ; make ; make install. Symlinked the binaries to /usr/bin. Same result (whether I specify the full real path to initdb or not). Additional searching still yields lots of messages with the question but none with the answer. Cheers, Steve
Steve Crawford <scrawford@pinpointresearch.com> writes:
>> creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL:
>> XX000: failed to initialize lc_messages to ""
We've seen this reported occasionally before, but none of the PG
developers have ever been able to reproduce it. Do you have any
LC_xxx environment variables besides what you showed? Could you
try running initdb under "strace -f -o logfile" and send me the
output (off-list, it'll likely be big)?
regards, tom lane
Tom Lane wrote: > Steve Crawford <scrawford@pinpointresearch.com> writes: >>>creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL: >>>XX000: failed to initialize lc_messages to "" > .... > We've seen this reported occasionally before, but none of the PG > developers have ever been able to reproduce it.... Summary: I installed glibc-locale and initdb now works fine. Full explanation: My base installation on this machine was a SuSE 8.2 "minimal install" to which I'm adding only the things the machine will be required to run. Among the things not included in the minimal install is gcc which I installed via YaST. NOT installed by default when YaST installs gcc is glibc-locale. (Also not installed is glibc-i18ndata). Once glibc-locale was installed, initdb worked fine. Subsequently I installed glibc-i18ndata and reran initdb which, as expected, still worked fine. I'll leave it to the development-team to decide if this situation should be classed as a bug, a failure of the installation routines to detect the absence of necessary files, a need for a better error message or simply failure of the nut behind the wheel. Cheers, Steve
Steve Crawford <scrawford@pinpointresearch.com> writes:
> Summary:
> I installed glibc-locale and initdb now works fine.
Interesting. I had just come to the conclusion that you were missing
some files from this part of your strace:
[pid 5240] open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/share/locale/locale.alias", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en_US/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en/LC_CTYPE", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en_US/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 5240] open("/usr/lib/locale/en/LC_MESSAGES", O_RDONLY) = -1 ENOENT (No such file or directory)
The references to "/usr/lib/locale/en/" look to be fallback attempts,
but on my Fedora machine, the other four files all exist and are in
the glibc-common RPM, which means that it's pretty much impossible not
to have them installed. I wasn't aware that other distros package them
as optional, but now we know.
> I'll leave it to the development-team to decide if this situation should
> be classed as a bug, a failure of the installation routines to detect
> the absence of necessary files, a need for a better error message or
> simply failure of the nut behind the wheel.
The problem is that all we see is a failure return from setlocale(),
and there's no API defined to find out *why* it failed; the presumption
is always that it's the user's fault, ie, the given locale string is
just wrong.
It might be possible to struggle along with the assumption that the
locale is really C, but I'm not sure what else might break if we try.
regards, tom lane
Tom Lane wrote: > Steve Crawford <scrawford@pinpointresearch.com> writes: >>Summary: >>I installed glibc-locale and initdb now works fine. > > Interesting. I had just come to the conclusion that you were missing > some files... > >....the other four files all exist and are in > the glibc-common RPM, which means that it's pretty much impossible not > to have them installed. I wasn't aware that other distros package them > as optional, but now we know. Well, the good news is that we can at least say that if you get the message: FATAL: XX000: failed to initialize lc_messages to "" then check to make sure that glibc-locale is properly installed. Perhaps this will help the next person to search the archives for that message. Cheers, Steve