Description of problem: From /var/log/boot.log: ----------------------------------------------------------- Setting up hotplug. Creating block device nodes. Creating character device nodes. Loading pata_acpi module Loading ata_generic module Making device-mapper control node Scanning logical volumes Reading all physical volumes. This may take a while... Found volume group "VolGroup00" using metadata type lvm2 Activating logical volumes 3 logical volume(s) in volume group "VolGroup00" now active Creating root device. Mounting root filesystem. Setting up other filesystems. Switching to new root and running init. /etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 20: warning: setlocale: LC_COLLATE: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 23: warning: setlocale: LC_MESSAGES: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 26: warning: setlocale: LC_NUMERIC: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 29: warning: setlocale: LC_TIME: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 19: warning: setlocale: LC_CTYPE: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 20: warning: setlocale: LC_COLLATE: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 23: warning: setlocale: LC_MESSAGES: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 26: warning: setlocale: LC_NUMERIC: cannot change locale (ja_JP.UTF-8): No such file or directory /etc/profile.d/lang.sh: line 29: warning: setlocale: LC_TIME: cannot change locale (ja_JP.UTF-8): No such file or directory Welcome to ESC[0;34mFedoraESC[0;39m Press 'I' to enter interactive startup. Starting udev: udevd[671]: specified group 'dialout' unknown ----------------------------------------------------------- My /etc/sysconfig/i18n says: ----------------------------------------------------------- LANG="ja_JP.UTF-8" SUPPORTED="ja_JP.UTF-8:ja_JP:ja" SYSFONT="latarcyrheb-sun16" ----------------------------------------------------------- Version-Release number of selected component (if applicable): initscripts-8.88-1.i386 (not tested 8.89-1) glibc-2.9.90-2.i686 How reproducible: Perhaps 100% Steps to Reproduce: 1. reboot 2. 3.
Is /usr a separate partition for you? When did this error start happening?
(In reply to comment #1) > Is /usr a separate partition for you? Yes. > When did this error start happening? Sorry, actually I didn't reboot for 25 days... From boot.log-XXXX I cannot find out when this began.
Stab in the dark - if you downgrade to bash 3.x, does this go away?
(In reply to comment #3) > Stab in the dark - if you downgrade to bash 3.x, does this go away? Seems good. I tried to reboot with 3.2-33.fc11 initscripts-8.89-1.i386 and the warnings disappeared. With bash-4.0-0.1.rc1.fc11 this is reproducible.
Moving to bash. Is there a reason this is a loud error now?
This is probably the same problem as in bug #483002. Please try bash-4.0-0.3.rc1.fc11.
bash-4.0-0.3.rc1.fc11 still reproduces this warning. It seems that this warnings come from locale.c: ------------------------------------------------------------- 187 #if defined (HAVE_SETLOCALE) 188 r = *lc_all ? ((x = setlocale (LC_ALL, lc_all)) != 0) : reset_locale_vars (); 189 if (x == 0) 190 internal_warning("setlocale: LC_ALL: cannot change locale (%s): %s", lc_all, strerror(errno)); 191 locale_setblanks (); 192 return r; 193 #else ....................... 239 if (x == 0) 240 internal_warning("setlocale: %s: cannot change locale (%s): %s", var, get_locale_var (var), strerror(errno)); -------------------------------------------------------------
Nope, this is a different issue than bug #483002 - that one is debugging output, this one is that setlocale is being invoked before /usr/share is mounted, so it can't get to /usr/share/i18n/locales/en_US or whatever it's looking for. Why the bleep are we calling /etc/profile (and thence /etc/profile.d/*.sh) when we're handling /etc/rc.sysinit, anyhow? SHouldn't the default behavior be --noprofile when running a shell script? Or is /sbin/init doing something really evil with the execve() call?
*** Bug 483409 has been marked as a duplicate of this bug. ***
It's explicitly sourced, so that localization of the scripts actually works.
Complaints are still there. Is making /etc/profile.d/lang.sh to check if /usr/share/i18n/locales/ directory is present and run only then really not an option? This looks quite simple and in an absence of /usr/share/i18n/locales/ what lang.sh tries to do will not work anyway.
Setting F11Target
I see such errors too after upgrading to the latest glibc (in fact, glibc-common) package. Not only I see the error messages on boot, when I run any program in Gnome (in fa_IR locale), it says that it cannot find the locale and uses C locale. And all of the applications (except the main menu!) appear in English instead of Persian.
While my system was running rawhide, I still saw that problem (I installed a Fedoba 11 beta Live CD, and updated it). Anyway, I installed Fedora 11 Preview, and I don't see the problem anymore.
I installed Fedora 11 Preview using this partitioning scheme: clearpart --drives=vda --all --initlabel part /boot --ondisk=vda --fstype ext3 --size=1024 part pv.0 --ondisk=vda --size=1024 --grow volgroup vos --pesize=32768 pv.0 logvol swap --fstype swap --name=swap --vgname=vos --size=2048 logvol / --fstype ext4 --name=root --vgname=vos --size=1024 logvol /home --fstype ext4 --name=home --vgname=vos --size=1024 logvol /tmp --fstype ext4 --name=tmp --vgname=vos --size=1024 logvol /usr --fstype ext4 --name=usr --vgname=vos --size=4096 logvol /var --fstype ext4 --name=var --vgname=vos --size=1024 logvol /var/log --fstype ext4 --name=log --vgname=vos --size=1024 logvol /var/tmp --fstype ext4 --name=vtmp --vgname=vos --size=1024 ...and I *am* still seeing the setlocale errors. IMHO, this isn't so much a bug as it is a faulty assumption. There is no guarantee that / and /usr will not be separate partitions/volumes.
The reason I consider it a bug is that bash was not previously nearly as verbose in this situation.
Created attachment 342553 [details] patch to fix locale handling of /etc/rc.d/rc I disagree. This isn't a bug with bash; it's a bug with the initscripts. Bash's old behavior merely hid the bug. We must not explicitly source lang.sh if locale data is unavailable. But as soon as locale data is available, we *do* want to source lang.sh This patch (against F10, because I don't have an F11 box handy ATM) attempts to source lang.sh as soon as it can, but will only source it once.
As stated, I disagree. 1) These warnings (not errors!) from bash do not come from setting the locale, but from calling *unset* on variables that have no value to begin with 2) Aside from these warnings, the behavior is, with no /usr, messages are in english until the locale data is available, at which point it switches to the defined locale 3) You're suggesting adding code to do lots of checks... which would just accomplish the behavior we already have
In response to comment 18: I don't necessarily disagree that it's bogus that bash prints these warnings multiple times (for "unset", no less). But I don't see how we can argue that a program isn't entitled to warn when setlocale(3) fails. If we don't want to see these warnings (or any warnings), the solution is simple: don't attempt to set the locale when the prerequisite data to do so (i.e., /usr/share/locale) isn't available. That's what my patch does. Yes, my patch makes /etc/rc.d/rc test if locale data is available for each initscript it invokes. But that overhead is miniscule. Furthermore, once locale data becomes available, /etc/rc.d/rc remembers that (via LANGSH_SOURCED), so the test largely short-circuits.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I can confirm I see them on an upgraded F11 i386 box (VIA En12000). What is the current workaround?
*** Bug 506063 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Complaints are still there. Is making /etc/profile.d/lang.sh to check if > /usr/share/i18n/locales/ directory is present and run only then really not an > option? This looks quite simple and in an absence of /usr/share/i18n/locales/ > what lang.sh tries to do will not work anyway. Can't we just redirect the very UGLY error messages to /dev/null? If so, what needs to be changed where so we can test?
http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=7932211055b0f66095ccb1a22cc03e07e2c64d54 Cherry-picked to the F11 branch as well.
test-rpm? :-)
*** Bug 507764 has been marked as a duplicate of this bug. ***
Can we redirect stderr to /dev/null?
Also noticed this behaviour on my machine, Fedora 11 with kernel-2.6.29.6-217.2.8.fc11.x86_64, initscripts-8.95-1.x86_64, bash-4.0-7.fc11.x86_64.
We are still getting no love for having /usr on a separate filesystem. It may be only warnings, but they are really ugly and spoil our divine boot.log output.
On my system LANG="en_us" was set in /etc/sysconfig/i18n I changed en_us to en_US and the warnings went away.
LANG="en_US.UTF-8" here. Why doesn't that help?
initscripts-8.95.1-1 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/initscripts-8.95.1-1
What is the status for Fedora 12 for this issue?
It was fixed a long time ago during Fedora 12 development. See comment #24.
Thanks, will pay extra attention during next reboot.
initscripts-8.95.1-1 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update initscripts'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-12765
initscripts-8.95.1-1 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.