Thread: Locale and Initdb Errors
Hi, I'm trying to set up Postgresql 8.1.4 on my Fedora Core 5 laptop. Whenever I run initdb, I receive this error
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/pg_twophase ... ok
creating directory /var/lib/pgsql/data/pg_multixact/members ... ok
creating directory /var/lib/pgsql/data/pg_multixact/offsets ... 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 ... 100
selecting default shared_buffers ... 1000
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:2666
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/pgsql/data"
I've tried googling around for an answer, and most answers recommend adding to your /etc/bashrc the line
export LC_ALL=C
export LANGUAGE=en_US
export LANG=en_US.UTF-8
which I have. The error still persists. Any ideas?
Thanks,
Travis West
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/pg_twophase ... ok
creating directory /var/lib/pgsql/data/pg_multixact/members ... ok
creating directory /var/lib/pgsql/data/pg_multixact/offsets ... 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 ... 100
selecting default shared_buffers ... 1000
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:2666
child process exited with exit code 1
initdb: removing contents of data directory "/var/lib/pgsql/data"
I've tried googling around for an answer, and most answers recommend adding to your /etc/bashrc the line
export LC_ALL=C
export LANGUAGE=en_US
export LANG=en_US.UTF-8
which I have. The error still persists. Any ideas?
Thanks,
Travis West
"Travis West" <trav.west@gmail.com> writes: > Hi, I'm trying to set up Postgresql 8.1.4 on my Fedora Core 5 laptop. > Whenever I run initdb, I receive this error > creating template1 database in /var/lib/pgsql/data/base/1 ... FATAL: XX000: > failed to initialize lc_messages to "" > LOCATION: InitializeGUCOptions, guc.c:2666 We've seen this before. The last go-round concluded that it was a missing-locale-support problem, see this message and surrounding thread: http://archives.postgresql.org/pgsql-general/2005-11/msg01356.php But I had thought that Fedora was more or less impervious to this because it seems to treat the locale data as part of the minimal install. Or maybe it's not so minimal --- PG works fine on my FC5 machine but I went for a pretty complete install. What have you got under /usr/share/locale/ and /usr/lib/locale/, and what does "rpm -qa | grep glibc" show? regards, tom lane
[ please cc: the list when replying, so that problems and solutions can be archived ] "Travis West" <trav.west@gmail.com> writes: > When I ran rpm -qa | grep glibc, the results were: > glibc-2.4-4 > glibc-kernheaders-3.0-5.2 > glibc-devel-2.4-4 > glibc-headers-2.4-4 Hm, where's glibc-common? That seems to be what you're missing, but I would have thought it's part of the minimal install. regards, tom lane
Yep, it was the glibc-common. I looked back through install.log and during the installation, there was an MD5 sum mismatch with that package, so it failed to install it. I downloaded it, installed it, and now postgresql starts.
Thanks.
Travis West
Thanks.
Travis West
On 6/2/06, Tom Lane < tgl@sss.pgh.pa.us> wrote:
[ please cc: the list when replying, so that problems and solutions can
be archived ]
"Travis West" < trav.west@gmail.com> writes:
> When I ran rpm -qa | grep glibc, the results were:
> glibc-2.4-4
> glibc-kernheaders-3.0-5.2
> glibc-devel-2.4-4
> glibc-headers-2.4-4
Hm, where's glibc-common? That seems to be what you're missing, but
I would have thought it's part of the minimal install.
regards, tom lane
"Travis West" <trav.west@gmail.com> writes: > Yep, it was the glibc-common. I looked back through install.log and during > the installation, there was an MD5 sum mismatch with that package, so it > failed to install it. I downloaded it, installed it, and now postgresql > starts. Interesting. I had tried to replicate the problem here, and rpm wouldn't let me: $ sudo rpm -e glibc-common error: Failed dependencies: glibc-common = 2.4-8 is needed by (installed) glibc-2.4-8.i686 /usr/bin/gencat is needed by (installed) redhat-lsb-3.0-9.2.i386 /usr/bin/getconf is needed by (installed) redhat-lsb-3.0-9.2.i386 /usr/bin/iconv is needed by (installed) redhat-lsb-3.0-9.2.i386 /usr/bin/locale is needed by (installed) redhat-lsb-3.0-9.2.i386 /usr/bin/localedef is needed by (installed) redhat-lsb-3.0-9.2.i386 $ Of course I could have overridden that with --nodeps, but that's not the point. What surprises me is that the installer would allow installation to proceed without a package that core packages are marked as dependent on. ISTM that's an installer bug; you ought to file a bug report about it with Red Hat. (I would, but you have the evidence in the form of the log file, so you should do it.) regards, tom lane