Bugzilla – Bug 5092
packagemanager won't run after exiting gives locale error
Last modified: 2008-12-16 00:37:12 UTC
You need to log in before you can comment on or make changes to this bug.
On a newly installed system running snv_101a I have been using the packing gui, packagemanager. I closed it. Trying to run it again using the buttons on the display, it never starts. running it by hand, pfexec packagemanager fails with following msg joanp@rgypsy:~$ pfexec packagemanager (process:2300): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. en_US.UTF-8: unknown locale Traceback (most recent call last): File "/usr/bin/packagemanager", line 2208, in ? packagemanager = PackageManager() File "/usr/bin/packagemanager", line 100, in __init__ locale.setlocale(locale.LC_ALL, '') File "/usr/lib/python2.4/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting The locale is: joanp@rgypsy:~$ locale LANG=en_US.UTF-8 LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C"
Moving to correct Product/Component.
I have reproduce this.
It is happening with fresh install OpenSolaris 2008.11 RC2 build out-of-box install. most embarrassing and seems to be it is going to get released with such bugs. Note: The same is not happened on USB based (from *.usb file) install. based on the seriousness of the bug, elevating it to P2 level. else it won't get the folks attention. #cat /etc/release OpenSolaris 2008.11 snv_101b_rc2 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 19 November 2008 #locale LANG=en_US.UTF-8 LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES=C LC_ALL= #pkg refresh en_US.UTF-8: unknown locale Traceback (most recent call last): File "/usr/bin/pkg", line 2228, in ? __ret = main_func() File "/usr/bin/pkg", line 2072, in main_func locale.setlocale(locale.LC_ALL, '') File "/usr/lib/python2.4/locale.py", line 381, in setlocale return _setlocale(category, locale) Error: unsupported locale setting Traceback (most recent call last): File "/usr/bin/pkg", line 2296, in ? error( NameError: name '_' is not defined # work around: #export LANG="C" and run the "pkg"
My understanding is that installs on the bare metal have been tested and this bug could not be reproduced. Conny should have more details. Can you describe exactly what you did during the install process to see if we can reproduce this. Is this an installer bug in how the locale is being setup?
I can reproduce on RC2 (pkg image-update'd), though getting locale errors for locales like sv_SE.UTF-8 in GNOME apps too, though I understand that sv_SE.UTF-8 is one of the supported locales (see /usr/lib/locale/).
I can get the same failure by setting up the locale in a terminal on an RC2 build, listed above as follows in Comment #3: $ export LANG=en_US.UTF-8; export LC_CTYPE='"C"'; export LC_NUMERIC='"C"'; export LC_TIME='"C"'; export LC_COLLATE='"C"'; export LC_MONETARY='"C"'; export LC_MESSAGES="C" ~$ pfexec pkg refresh "C": unknown locale "C": unknown locale "C": unknown locale Traceback (most recent call last): File "/usr/bin/pkg", line 2228, in ? __ret = main_func() File "/usr/bin/pkg", line 2072, in main_func locale.setlocale(locale.LC_ALL, '') File "/usr/lib/python2.4/locale.py", line 381, in setlocale return _setlocale(category, locale) Error: unsupported locale setting Traceback (most recent call last): File "/usr/bin/pkg", line 2296, in ? error( NameError: name '_' is not defined
I am on locale: de_DE.UTF-8, and I did: export LC_ALL=C I got: conny@opensolaris:~$ locale LANG=de_DE.UTF-8 LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES="C" LC_ALL=C pfexec packagemanager works.
$ locale LANG=en_US.UTF-8 LC_CTYPE="C" LC_NUMERIC="C" LC_TIME="C" LC_COLLATE="C" It means your system doesn't have en_US.UTF-8 locale in /usr/lib/locale. So once you install the locale package, it will be resolved. But I don't understand why you don't have en_US.UTF-8 locale? It's installed by default. So fixing this is nice to have. e.g. try: locale.setlocale(locale.LC_ALL, "") except: print ("Your locale is not installed correctly.") exit 1 > export LANG=en_US.UTF-8; export LC_CTYPE='"C"'; export LC_NUMERIC='"C"'; export LC_TIME='"C"'; export LC_COLLATE='"C"'; export LC_MONETARY='"C"'; export LC_MESSAGES="C" The double quotation means the value was fallen back because the user doesn't specify. Normally the fallen back locale is same $LANG but the locale C mean the system doesn't install en_US.UTF-8 correctly. So you should not specify the double quoted locale by yourself.
All i have done is, took the *rc2.iso and installed it using vmware1.07. No change. Note: as said the issue was not there with *rc2.usb on a direct install to Sun U40 box tne en_US.UTF-8 locale is there and its contents. # locale -a | grep en en_AU.UTF-8 en_CA.UTF-8 en_GB.UTF-8 en_IE.UTF-8 en_MT.UTF-8 en_NZ.UTF-8 en_US.UTF-8 # ls -ald /usr/lib/locale/en* drwxr-xr-x 10 root bin 14 Nov 25 14:37 /usr/lib/locale/en_AU.UTF-8 drwxr-xr-x 10 root bin 14 Nov 25 14:37 /usr/lib/locale/en_CA.UTF-8 drwxr-xr-x 10 root bin 14 Nov 25 14:37 /usr/lib/locale/en_GB.UTF-8 drwxr-xr-x 10 root bin 14 Nov 25 14:37 /usr/lib/locale/en_IE.UTF-8 drwxr-xr-x 10 root bin 14 Nov 25 14:37 /usr/lib/locale/en_MT.UTF-8 drwxr-xr-x 10 root bin 14 Nov 25 14:37 /usr/lib/locale/en_NZ.UTF-8 drwxr-xr-x 10 root bin 16 Nov 25 16:06 /usr/lib/locale/en_US.UTF-8 # ls /usr/lib/locale/en_US.UTF-8 32 LC_COLLATE LC_MESSAGES LC_NUMERIC LO_LTYPE geo_map locale_map 64 LC_CTYPE LC_MONETARY LC_TIME amd64 locale_description methods_en_US.UTF-8.so.3 #
V - can you switch to other locales and print out the output from locale to see if they are being set correctly or are falling back as Fujiwara has indicated to the C locale.
It is not falling back to "C". after OS install and default login, this issue occurs and setting LANG="C" solves the issue. ie. choosing "C" from login language might work fine. I am doing WFH on a wireless broadband for two days. changing GUI language change over rdesktop -> VMwareconsole -> OS desktop is slowww..
> Note: as said the issue was not there with *rc2.usb on a direct install to Sun U40 box Do you mean your issue is the installed system? Now I tried LiveCD session in both *rc2.iso and *global-rc2.iso with English. When the gnome-session is started with jack user, the locale is set correctly. i.e. $ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" ... And I could launch packagemanager correctly. My understanding is, your locale was set correctly with *rc2.usb but not other. > this issue occurs and setting LANG="C" solves the issue. ie. choosing "C" from login language might work fine. Yes, setlocale C is always succeeded. Do you mean your issues depends on VMWare? Do you have a change to compare with VirtualBox? My system works with VirtualBox.
Here is what I found: On my system, the pkg(1) fails: migi@opensolaris:~$ locale LANG=sv_SE.UTF-8 LC_CTYPE=C LC_NUMERIC=C LC_TIME=C LC_COLLATE="C" LC_MONETARY="C" LC_MESSAGES=C LC_ALL= This works: migi@opensolaris:~$ locale LANG=de_DE.UTF-8 LC_CTYPE=C LC_NUMERIC=C LC_TIME=C LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES=C LC_ALL= So I did truss the pkg(1) and then I found that for de_DE.UTF-8 the file: +xstat(2, "/usr/lib/locale/de_DE.UTF-8/de_DE.UTF-8.so.3", 0x08046364) = 0 Moving this file causes the same problem as with the sv_SE.UTF-8 Is being checked and it exists, for sv_SE.UTF-8 the corresponding file doesn't exists: migi@opensolaris:~$ ls -lah /usr/lib/locale/sv_SE.UTF-8/ |grep so migi@opensolaris:~$ I am not sure what this file is for, but if it doesn't exists, then locale is not supported and pkg(5) will fail. The correct solution would be to put those files in? But at the same time we should catch the ValueError if the locale is not supported and fallback to "C" so users will have at least working "C" locale version.
> The correct solution would be to put those files in? But at the same time we should catch the ValueError if the locale is not supported and fallback to "C" so users will have at least working "C" locale version. Yes, if users removed locale files, they should be installed. It's my previous mention. Yes, packagemanager can set C locale if setlocale is failed and it's nice to have because I think many applications effect the wrong behavior with the wrong locales so fixing packagemanager only doesn't resolve the root cause. It seems the submitter has the default system and got the wrong locale. So I guess it's an installation problem and I'm asking to compare VMware and VirtualBox.
I just installed the rc2.iso on a Virtualbox. I got conny@opensolaris:~$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES=en_US.UTF-8 LC_ALL= I still cannot reproduce this problem. I have no vmware at this moment. My Vitualbox is 2.0.4, host os is Ubuntu 8.10.
Ok, it might be installed fine on VirtualBox and showed the correct locale. 1. How the same rc2.iso is different on VMware. I am sure VMware doesn't tweak anything with OS other than it just uses "Solaris 64-bit" whereas VirtualBox has the option of choosing "OpenSolaris" as OS. Again i don't know what VMware does. 2. Despite the locale is present, why does it say "en_US.UTF-8: unknown locale"? and not falling back to "C"? in case if "en_US.UTF-8" files might be corrupted.
OK, probably your issue is VMware + OpenSolaris installer. Unfortunately I don't understand VMware installation. Previously I tried free VMware Player but I didn't know the configuration file for OpenSolaris. I guess your issue can be resolved with VirtualBox at the moment.
> 2. Despite the locale is present, why does it say "en_US.UTF-8: unknown locale"? and not falling back to "C"? in case if "en_US.UTF-8" files might be corrupted. Falling back to C depends on each application. It's out of the specification of setlocale(3C) and most applications stand on the installer will be succeeded. If you ask only packagemanager will run on the wrong locale, I think it can be done. But it's not realistic for every application. I guess truss command can check which file failed to be opened. I think normally if LC_CTYPE can be set correctly, setlocale (LC_ALL, "") will be succeeded. Actually some libraries are needed in /usr/lib/locale/en_US.UTF-8. If you copy the files from the correct system to the wrong system, the system may works fine.
If you believe there is something wrong with the installation, then please do the following: - run "pkg verify" to check the installed system against the package metadata - attach the installation log, /var/sadm/system/logs/install_log from an installation where this problem is exhibited
This is not VMware specific. i have been using that from b97 onwards. only off late i used "pkg" for my testing. Note: will double check with latest RC2.iso on vmware and direct install. -bash-3.2# cat /etc/release OpenSolaris 2008.11 snv_97 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 03 September 2008 -bash-3.2# -bash-3.2# locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES=C LC_ALL= -bash-3.2# -bash-3.2# pkg install amp-dev Creating Plan \
As mentioned in comments the issue is locale shared object /usr/lib/locale/<locale>/<locale>.so.? not found in the system. Somehow this file gets removed during/after the installation. May not be the same, but something similar to 6767074 may be happening. Just after you install OS check if the locale shared object is present.
in my case, the *.so.* files are there. anything else do i need to check? $ ls -l `find /usr/lib/locale/en_US.UTF-8 -name "*.so*"` lrwxrwxrwx 1 root root 51 Nov 25 14:37 /usr/lib/locale/en_US.UTF-8/LC_CTYPE/amd64/wdresolve.so -> ../../../common/LC_CTYPE/amd64/wdresolve_unicode.so lrwxrwxrwx 1 root root 42 Nov 25 14:37 /usr/lib/locale/en_US.UTF-8/LC_CTYPE/wdresolve.so -> ../../common/LC_CTYPE/wdresolve_unicode.so lrwxrwxrwx 1 root root 47 Nov 25 14:37 /usr/lib/locale/en_US.UTF-8/LO_LTYPE/amd64/en_US.UTF-8.layout.so.1 -> ../../../common/LO_LTYPE/amd64/umle.layout.so.1 lrwxrwxrwx 1 root root 38 Nov 25 14:37 /usr/lib/locale/en_US.UTF-8/LO_LTYPE/en_US.UTF-8.layout.so.1 -> ../../common/LO_LTYPE/umle.layout.so.1 -r-xr-xr-x 1 root bin 2496928 Nov 20 13:23 /usr/lib/locale/en_US.UTF-8/amd64/en_US.UTF-8.so.3 lrwxrwxrwx 1 root root 39 Nov 25 14:37 /usr/lib/locale/en_US.UTF-8/amd64/methods_en_US.UTF-8.so.3 -> ../../common/amd64/methods_unicode.so.3 lrwxrwxrwx 1 root root 30 Nov 25 14:37 /usr/lib/locale/en_US.UTF-8/methods_en_US.UTF-8.so.3 -> ../common/methods_unicode.so.3 $ $ ls -l /usr/lib/locale/common/LC_CTYPE/wdresolve_unicode.so -r-xr-xr-x 1 root bin 7692 Nov 20 13:25 /usr/lib/locale/common/LC_CTYPE/wdresolve_unicode.so $ $ ls -l /usr/lib/locale/common/amd64/methods_unicode.so.3 -r-xr-xr-x 1 root bin 72368 Nov 20 13:25 /usr/lib/locale/common/amd64/methods_unicode.so.3 $ ls -l /usr/lib/locale/common/LO_LTYPE/amd64/umle.layout.so.1 -r-xr-xr-x 1 root bin 489048 Nov 20 13:25 /usr/lib/locale/common/LO_LTYPE/amd64/umle.layout.so.1 $ $ ls -l /usr/lib/locale/common/LO_LTYPE/umle.layout.so.1 -r-xr-xr-x 1 root bin 422656 Nov 20 13:25 /usr/lib/locale/common/LO_LTYPE/umle.layout.so.1 $
Comment from Fuyuki Hasegawa: I guess the problem is caused by 3676. http://defect.opensolaris.org/bz/show_bug.cgi?id=3676 We made the following pkg split at snv_101. SUNWlang-xxYY were included only in primary CD. SUNWlang-en -> SUNWlang-en & SUNWlang-enUS SUNWlang-fr -> SUNWlang-fr & SUNWlang-frFR SUNWlang-es -> SUNWlang-es & SUNWlang-esES SUNWlang-de -> SUNWlang-de & SUNWlang-deDE If that's the cause, the problem should always happen when did "pkg image-update" from snv_100 or earlier version to snv_101 or later version. And workaround should be: pfexec pkg install SUNWlang-enUS SUNWlang-frFR SUNWlang-esES SUNWlang-deDE I've asked Takeshi to reproduce the problem with image-update from 2008.05 to 2008.11 RC2. If anyone can also reproduce the problem, it would be helpful. Unlike NV as we don't have package history mechanism (ie, REPLACED_BY=), the fix/workaround seems to add the following dependency. package SUNWlang-en classification "System/Localizations" import SUNWlang-en depend SUNWlang-enUS <---- Insert this line end package
I tried these scenarios: - On VMware, 2008.05(primary langs CD) -> image-update with current pkg.opensolaris.org:80 (should contain 101a) - On VirtualBox, 2008.05 (primary langs CD) -> image update with current osol-re.sfbay:80 (should contain RC2) and have not reproduced the problem that en_US.UTF-8 locale is missing. I'll continue investigation but people who already have system with the problem could supply these information? - result of these commands $ pkg info SUNWlang-enUS $ pkg info SUNWlang-en $ pkg info slim_install $ ls /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3 - if possible, information on your previous BE (e.g. if your current one is opensolaris-5) # beadm mount opensolaris-4 /a # cd /a # cat etc/release # pkg authority # cd / # beadm unmount opensolaris-4 - if possible, information on your first BE (usually "opensolaris") Do same as above for "opensolaris" instead of "opensolaris-4".
mine is direct install (no upgrade scenario) from internal ISO image using vmware1.07 Note: doing one install from genunix.org and will udpate this bug sounds like one file is missing. root@ejp-152x-107-vm97:~# pkg info SUNWlang-enUS Name: SUNWlang-enUS Summary: English (U.S.A.) language support Category: System/Localizations State: Installed Authority: opensolaris.org Version: 0.5.11 Build Release: 5.11 Branch: 0.101 Packaging Date: Wed Nov 19 23:36:10 2008 Size: 4.75 MB FMRI: pkg:/SUNWlang-enUS@0.5.11,5.11-0.101:20081119T233610Z root@ejp-152x-107-vm97:~# root@ejp-152x-107-vm97:~# pkg info SUNWlang-en Name: SUNWlang-en Summary: English language support Category: System/Localizations State: Installed Authority: opensolaris.org Version: 0.5.11 Build Release: 5.11 Branch: 0.101 Packaging Date: Wed Nov 19 23:35:46 2008 Size: 20.94 MB FMRI: pkg:/SUNWlang-en@0.5.11,5.11-0.101:20081119T233546Z root@ejp-152x-107-vm97:~# root@ejp-152x-107-vm97:~# pkg info slim_install Name: slim_install Summary: slim install cluster State: Installed Authority: opensolaris.org Version: 0.1 Build Release: 5.11 Branch: 0.101 Packaging Date: Wed Nov 19 23:56:36 2008 Size: 0.00 B FMRI: pkg:/slim_install@0.1,5.11-0.101:20081119T235636Z root@ejp-152x-107-vm97:~# root@ejp-152x-107-vm97:~# ls /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3 ls: cannot access /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3: No such file or directory // i don't know how the above file is missing. though it should have been part of the following pkg. root@ejp-152x-107-vm97:~# pkg contents SUNWlang-enUS | grep en_US.UTF-8.so.3 usr/lib/locale/en_US.UTF-8/amd64/en_US.UTF-8.so.3 usr/lib/locale/en_US.UTF-8/amd64/methods_en_US.UTF-8.so.3 usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3 usr/lib/locale/en_US.UTF-8/methods_en_US.UTF-8.so.3 root@ejp-152x-107-vm97:~# so as a work around, re-installing SUNWlang-enUS will solve the issue? doing so warns about "slim_install" dependency, what is that pkg?
small note: mine is 64-bit install. ie.Solaris 10 64-bit.
is there a way to "--force" install pkg from repository or uninstall ignoring dependency of non-core-os pkgs? like "--nodeps" uninstall? pkg needs to be improved with such options.
on the same vmware env, the one which i have installed from genunix.org works fine. don't know whats wrong with internal iso and how that happened. # cat /etc/release OpenSolaris 2008.11 snv_101b_rc2 X86 Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 19 November 2008 # uname -a SunOS ejp-152-vm19 5.11 snv_101b i86pc i386 i86pc Solaris # locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL= # root@ejp-152-vm19:~# ls -l /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3 -r-xr-xr-x 1 root bin 2482668 2008-11-20 13:23 /usr/lib/locale/en_US.UTF-8/en_US.UTF-8.so.3 # i think above missing file was the culprit in my earlier case. how to re-install those pkg?
Thank you for the additional information. Your case seems not related to the package split. Regarding the workaround, I think reinstalling the SUNWlang-enUS should work. You can uninstall slim_install to enable it. However, it's strange that your system has slim_install left. In 2008.11 RC2 slim_install is uninstalled automatically before finishing installation (See 3398). Where did you get the "internal image"? Maybe the removal mechanism was also not working in your environment. slim_install is not an individual package but a cluster being used for grouping packages at installation.
It has been discovered that "slim_install" is left when using "all languages" CD (aka global CD or babel CD). See 5492. So if you used the CD for installation, having slim_install left is problem known and not specific to your case. Workaround is same as that of 3398, i.e. manually uninstall slim_install. But this is not related to the "en_US.UTF-8.so.3 is missing" problem, which is not reproducible using the "all languages CD" too.
Takeshi, could a separate bug under installer/other be filed (if not already) on "babel_install" and/or "slim_install" being left on the newly installed 2008.11 system. Please add "rn4" to the Whiteboard so we can release note this.
5492 is the bug describes slim_install left from install with babel CD. I moved it to installer/other (from opensolaris/install) and marked rn4. babel_install is removed correctly but slim_install is left.
(a) Regarding the problem en_US.UTF-8, de_DE.UTF-8, es_ES.UTF-8 and fr_FR.UTF-8 are lost *during image-update*, condition for reproductivity has been clarified. If image-update to snv100 or older to snv101 or newer after removing slim_install cluster, the problem happens. See (and please continue discussion on it if any on) 5473. (b) Regarding V's case, i.e. en_US.UTF-8.so.3 is missing after fresh installation but SUNWlang-enUS is installed, I've not reproduced it. V, if possible could you please reinstall your VM with the same internal image and see if it reproduces? (c) Regarding Glynn's case, sv_SE.UTF-8 is not affected by (a) so I don't know why. You mean you were using the locale and you no longer see the locale after image-update? (d) Regarding Wendy's case, it's newly installed system so looks not related to (a). But you wrote first run of package manager succeeded while second one failed. Which operation(s) did you do during the first run? (e) I cannot determine from information given that other people's cases are same as which of above, or another one.
(c) Regarding Glynn's case, SUNWlang-sv was moved to global CD at sync with snv_100a. So, if Glynn's system was freshed installed with primary CD snv_100a or later, sv_SE.UTF-8 is not installed as well as after image-update to RC2. Even if sv_SE.UTF-8 locale is not installed, there are installer l10n files under /usr/lib/locale/sv_SE.UTF-8/LC_MESSAGES.
The blocking bug has been fixed. The only remaining issue is that we should not throw an exception. This is captured in bug 5778 so I am closing this as a duplicate of that bug. *** This bug has been marked as a duplicate of bug 5778 ***