Bug 483409
Summary: | /etc/profile.d/lang.sh goes bonkers in a startup sequence with bash-4 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | initscripts | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | notting, rvokal, valdis.kletnieks |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-02 18:36:17 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michal Jaegermann
2009-01-31 22:04:48 UTC
I'm suspecting the base cause is that you have /usr/share as a separate file system, and it's doing this before /usr/share is mounted, so setlocale can't get to /usr/share/i18n/locales/en_U. Also, this looks like a dup of bug #482888 > Also, this looks like a dup of bug #482888
Yes, indeed, it does.
Does this also mean that bash-3 was simply ignoring those errors and bash-4 is just loud? If this is indeed a matter of availability of /usr/share/locale
then running the whole thing inside "if [ -d /usr/share/locale ]; then ...; fi"
would help.
'lang.sh' is called all over the place in a startup sequence (which are really runs of /etc/profile). Just 'echo' something from it and see for yourself. It has even a code to prevent setting the same $LANG over and over.
No, *if* you get into /etc/profile.d/lang.sh, throwing those errors *is* proper. The *bug* here is that /etc/profile (and thence /etc/profile.d/*.sh) are being called for /etc/rc.sysinit - *EVEN THOUGH IT'S A SCRIPT AND NOT A LOGIN SHELL*. *THAT*'s what's broken here. > *THAT*'s what's broken here.
You mean that bash used in a startup runs as a login shell? I have no idea if this is by design or by an accident. Surely you need assorted settings, and that
includes LANG, be in a proper state before anything of X starts but that should be doable in any case. Also if you want startup error messages "internationalized" (that happens now) then $LANG is required.
*** This bug has been marked as a duplicate of bug 482888 *** |