Bug 731356 - Error: unsupported locale setting
Error: unsupported locale setting
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ales Kozumplik
Fedora Extras Quality Assurance
: 739305 742355 744029 (view as bug list)
Depends On:
Blocks: F16-accepted/F16FinalFreezeExcept
  Show dependency treegraph
Reported: 2011-08-17 08:30 EDT by Fred
Modified: 2014-09-30 19:40 EDT (History)
13 users (show)

See Also:
Fixed In Version: anaconda-16.21-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-10-18 19:09:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda.log (9.02 KB, text/plain)
2011-09-21 01:06 EDT, Fred
no flags Details
anaconda-tb-MTpkcD (317.32 KB, text/plain)
2011-09-21 01:10 EDT, Fred
no flags Details

  None (edit)
Description Fred 2011-08-17 08:30:17 EDT
abrt version: 2.0.5
executable:     /usr/bin/python
hashmarkername: anaconda
kernel:         3.0.0-1.fc16.i686
product:        Fedora
reason:         Error: unsupported locale setting
time:           Wed Aug 17 12:29:46 2011
version:        16-Alpha

:The following was filed automatically by anaconda:
:anaconda 16.14.6 exception report
:Traceback (most recent call first):
:  File "/usr/lib/python2.7/locale.py", line 531, in setlocale
:    return _setlocale(category, locale)
:  File "/usr/lib/python2.7/site-packages/scdate/core/zonetab.py", line 85, in __translate_tz
:    locale.setlocale(locale.LC_ALL, "")
:  File "/usr/lib/python2.7/site-packages/scdate/core/zonetab.py", line 127, in _set_tz
:    self.__translate_tz()
:  File "/usr/lib/python2.7/site-packages/scdate/core/zonetab.py", line 59, in __init__
:    self.tz = tz.replace ('_', ' ')
:  File "/usr/lib/python2.7/site-packages/scdate/core/zonetab.py", line 218, in readZoneTab
:    entry = ZoneTabEntry (code, lat, long, tz, comments)
:  File "/usr/lib/python2.7/site-packages/scdate/core/zonetab.py", line 153, in __init__
:    self.readZoneTab (fn)
:  File "/usr/lib/python2.7/site-packages/pyanaconda/iw/timezone_gui.py", line 44, in __init__
:    self.zonetab = zonetab.ZoneTab()
:  File "/usr/lib/python2.7/site-packages/pyanaconda/gui.py", line 1265, in display_step
:    self.currentWindow = newScreenClass(ics)
:  File "/usr/lib/python2.7/site-packages/pyanaconda/gui.py", line 1154, in display_step
:    return self.icw.display_step(step)
:  File "/usr/lib/python2.7/site-packages/pyanaconda/dispatch.py", line 352, in dispatch
:    rc = self.anaconda.intf.display_step(self.step)
:  File "/usr/lib/python2.7/site-packages/pyanaconda/dispatch.py", line 235, in go_forward
:    self.dispatch()
:  File "/usr/lib/python2.7/site-packages/pyanaconda/gui.py", line 1198, in nextClicked
:    self.anaconda.dispatch.go_forward()
:Error: unsupported locale setting
Comment 1 Adam Williamson 2011-09-17 14:56:36 EDT
*** Bug 739305 has been marked as a duplicate of this bug. ***
Comment 2 Adam Williamson 2011-09-17 14:58:08 EDT
Still valid with Beta RC1, as the dupe shows.

Fred, we're going to need more information about the exact process you used for install, all I have so far is "Note that I was installing from USB from the DVD image." (which, BTW, is known to be a somewhat complicated case). What happens before you hit this bug?
Comment 3 Fred 2011-09-18 01:31:19 EDT

So I went through a VM install to confirm the steps and tada tada, the VM install has 1 more screen which do not appear on the USB install:
Select installation language.

My process from USB install is:
- Use livecd-iso-to-disk from full DVD image to generate the USB disk
- Boot from USB
- 1st question is "Select keyboard type" in text mode (blue and red): I chose US
=> note that in the VM test above I had to chose a language first and both questions where in a graphical mode
- Prompts me that it's not production version: I select 'Install anyway'
- Next screen: Basic Storage
- Next screen: Fresh install
- next screen: hostname
=> then unexpected crash has happened...

Anything else you need me to do?
Comment 4 Adam Williamson 2011-09-18 03:17:46 EDT
From the install guide:

" Creating Fedora USB Media in Fedora, Red Hat Enterprise Linux, and similar Linux distributions
Graphical and command-line tools are available to create Fedora USB media on computers that run Fedora, Red Hat Enterprise Linux, and Linux distributions derived from Red Hat Enterprise Linux. The graphical tool and the works only with the Fedora live image. To create Fedora USB media from the distribution image or minimal boot media image, use the command-line method described in Section, “Making Fedora USB Media with dd”. "

so, writing the DVD image to USB with livecd-iso-to-disk is not supported: only writing it with dd, apparently. How did you write it?
Comment 5 Fred 2011-09-18 03:31:11 EDT
So that has changed for F16? 

I remember reading livecd-iso-to-disk working with full DVD image and that's how I did for F15 without any trouble. I'm trying to find the wiki page but it seems the wiki had a revamp.
Comment 6 Fred 2011-09-18 03:38:33 EDT
Found it! Here is the link:
and the example is clearly using both livecd-iso-to-disk and the DVD image.
Comment 7 Adam Williamson 2011-09-18 03:44:01 EDT
yeah, I was looking at the install guide, and it explicitly says that livecd-iso-to-disk only works with the live image, so they're in conflict.

There have been changes to livecd-iso-to-disk lately which may affect its use for writing the DVD image; are you on livecd-tools 16.6?

please do try with dd (I'm hoping the image is a hybrid this time...) and see if it changes things, that will help triage down the problem, regardless of whether it 'should' work with livecd-iso-to-disk.
Comment 8 Fred 2011-09-18 03:47:17 EDT
I'm using livecd-tools-15.7-1.fc15.i686 (from F15). I'll try dd and revert back.
Thank you.
Comment 9 Fred 2011-09-18 10:10:06 EDT
dd didn't work, the USB stick wouldn't boot. I will try to upgrade livecd-tools then and try again.
Comment 10 Fred 2011-09-18 10:21:10 EDT
(can't get livecd-tools easily on F15). Thinking about it I think one of the Alpha RCs went a bit further but then failed later without the option to report a bug. I'm going to try with a live image and livecd-iso-to-disk available on F15
Comment 11 Fred 2011-09-19 04:09:03 EDT
Downloaded the live CD Desktop version, used livecd-iso-to-disk and I'm getting an irrevocable error on the live desktop asking me to log out and try again:
=> trying again doesn't change anything. I copied over the .xsession-error.log and can attach it here (though it should be a different bug).

What do you recommend I do now?
Thank you
Comment 12 Adam Williamson 2011-09-19 04:19:00 EDT
oh, that one's known - https://bugzilla.redhat.com/show_bug.cgi?id=738803. booting with 'enforcing=0' will work around it. For this one, we should wait for anaconda team to take a look and see what they think. thanks!
Comment 13 Nils Philippsen 2011-09-19 06:13:46 EDT
This doesn't seem to be an issue of s-c-date, as the issue seems to be that the language is never set up properly if this happens. Which component would be responsible for that in this case, livecd-tools, anaconda?
Comment 14 Fred 2011-09-19 07:14:27 EDT
So yes, the installation language question is not asked, and the keyboard layout question is asked in text mode: a silent crash? I don't mind testing anything if it can be helpful.

Thank you.
Comment 15 Adam Williamson 2011-09-19 11:08:39 EDT
anaconda, sorry, thought the bug was already assigned there.
Comment 16 Adam Williamson 2011-09-19 12:52:46 EDT
fred: can you test if you hit this if you write the dvd installer to an actual dvd? and can you test if you hit it if you choose 'basic graphics' mode? just trying to check if this is actually related to writing to USB or if it's some quirk with your system or what. thanks!
Comment 17 Fred 2011-09-20 10:12:12 EDT
Sorry for the delay, got some troubles with my internal DVD drive. So using an external drive I burnt a real DVD booted from it and all went fine (just like in the VM): got the installation language question in graphic mode, the keyboard layout, selected new install, time zone and root password. Anything else?
Comment 18 Chris Lumens 2011-09-20 10:39:22 EDT
Language isn't asked, because you're doing a live install and the language should have been set up by the live environment.  Previously, this happened via gdm.  It sounds like this is no longer the case, and that some communication for what should be happening how did not happen.
Comment 19 Fred 2011-09-20 21:29:58 EDT
@chris: the DVD I burnt is the full DVD install (not the live image, the one failing on the USB stick and not with a real DVD as a medium. So there is no live session at all. I am comparing apples with apples.
Comment 20 Fred 2011-09-20 22:03:08 EDT
oops I realize my former response was less than clear, so let me try it again: the image I burnt on the physical disk and tried is the full DVD install. This bug is about this image not working using USB stick. Adam was asking me to test that same image with a physical media to be able to identify whether the problem was coming from the image itself or my machine.

So there is no live session, and while using the DVD I get installation language asked and can install, while when using the same image with a USB stick I do not get that question and the installation fails as mentioned previously (bug report was automatically generated at failure time).

I hope that's better worded.
Comment 21 Adam Williamson 2011-09-20 22:11:34 EDT
can you attach anaconda's logs to the bug? after an install they should be present in /var/log/anaconda or as /var/log/anaconda*.log (I'm never quite sure which).
Comment 22 Adam Williamson 2011-09-20 22:11:57 EDT
er, logs from the failure case, that is. logs from the success case to compare are optional, but might help. thanks!
Comment 23 Fred 2011-09-20 22:53:06 EDT
Let me try to understand: in case of failure there is no install and I am left with a USB stick at the end of the bug report process. So the logs you want me to get would be on that USB stick and I should be able to get to a terminal to copy them over (or are they persistent files and can I find them at the next reboot on my machine by reading the USB stick)?

Thank you.
Comment 24 Adam Williamson 2011-09-21 00:43:14 EDT
sorry, I may have been on crack with that last comment. or thinking of another bug. but hey, logs are always good.

when an install is in progress, i think the logs wind up in /tmp. you can hit ctrl-alt-f4 (I think it is) to get to a console. getting the logs out of the installer environment is an exercise left for the reader. =) you can probably mount a usb stick and copy them to that.

thanks! we should see if anyone else can reproduce this, too...
Comment 25 Fred 2011-09-21 01:06:48 EDT
Created attachment 524127 [details]

CTRL+F2 did the trick (CTRL+F4 didn't seem to give me a prompt)
Comment 26 Fred 2011-09-21 01:10:00 EDT
Created attachment 524128 [details]

There was also this file which looks like a temporary file. As you said any log can be good here it is
Comment 27 Adam Williamson 2011-09-21 01:29:34 EDT
"04:58:49,574 ERR loader: unable to set to requested language en_US.utf8"

kinda jumps right out at you. No indication as to why not, though. I note my log - from an install with F15 - reads:

03:43:11,662 INFO anaconda: anaconda called with cmdline = ['/usr/sbin/anaconda', '--liveinst', '--method=livecd:///dev/mapper/live-osimg-min', '--lang', 'en_US.UTF-8'] - see the difference in case and the extra hyphen. I'm not sure exactly what generates that command, and how it decides on the language...but I do see:

04:58:46,292 INFO loader: kernel command line:
04:58:46,292 INFO loader:     initrd=initrd.img
04:58:46,292 INFO loader:     LANG=en_US.utf8


initrd=initrd.img LANG=en_US.utf8 repo=hd:UUID=a934b6f9-b810-4a8e-9aa6-060152b1d5f5:/ quiet BOOT_IMAGE=vmlinuz 

so it seems that, somehow, it was on the kernel command line.
Comment 28 Fred 2011-09-25 09:47:20 EDT
Just tried Beta RC2 and bug still in there. But I guess that was expected. Just wanted to follow up.
Comment 29 Adam Williamson 2011-09-25 14:57:13 EDT
I'm still confused as to how you wound up with en_US.utf8 (instead of en_US.UTF-8) on the kernel command line. Can you check what it looks like at the bootloader screen before you boot the installer?
Comment 30 Fred 2011-09-25 20:57:27 EDT
Kernel command line has en_US.UTF8. I tried to add the '-' between F and 8 but then it quickly ends up with 'BUG: kernel cannot handle NULL pointer dereference' or a similar message. Then there is a short trace on the screen and the system halts.

I'm curious, does it mean no one can reproduce the bug?
Comment 31 Adam Williamson 2011-09-25 21:54:56 EDT
I haven't been able to, and I haven't seen anyone else report the same thing...
Comment 32 Fred 2011-09-27 11:02:03 EDT
wow that's amazing. I also wonder how that command line gets UTF8 then. Could it be the --reset-mbr option from livecd-iso-to-disk? (my brain says no, but considering the situation I'm really puzzled now)

I'm downloading RC3 and will try again. I have little hope though now.
Comment 33 Brian Lane 2011-09-29 20:58:10 EDT
*** Bug 742355 has been marked as a duplicate of this bug. ***
Comment 34 Fred 2011-09-30 04:48:48 EDT
RC4 came out before I could test RC3... so with RC4 same behaviour, same kernel command line (utf8). I'll try to add information if this can help.
1. I noticed I need to --reset-mbr each time or else the USB stick doesn't boot. This wasn't the case for F15.
2. What I typed exactly to generate the USB stick is:
sudo umount /dev/sdb1
sudo livecd-iso-to-disk --format --reset-mbr Fedora-16-BetaRC4-i386-DVD.iso /dev/sdb1
[..] <- image check
Press Enter to continue or ctrl-c to abort

Waiting for devices to settle...
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=LIVE
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
489600 inodes, 1955328 blocks
97766 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2004877312
60 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
/home/fred/Downloads/Fedora-16-BetaRC4-i386-DVD.iso uses initrd.img w/o install.img
Size of DVD image: 3588
Size of isolinux/initrd.img: 128
Available space: 6992
Copying DVD image to target device.
Updating boot config file
Installing boot loader
/media/tgttmp.8DxHHP/syslinux is device /dev/sdb1
Target device is now set up with a Live image!
Comment 35 Fred 2011-10-01 22:11:32 EDT
Further testing with the kernel command line editing (as I said above adding '-' didn't work) proved useful: totally removing 'LANG=en_US.utf8' from the command line later prompts for installation language (and keyboard choice) leading to a successful installation. 

While this is not a fix, it at least provides a workaround for people hit by this bug and not wanting to burn a DVD to install.
Comment 36 Adam Williamson 2011-10-03 21:32:22 EDT
are you using --format when writing the USB stick, or not? I tend to use --format.
Comment 37 Adam Williamson 2011-10-03 21:33:59 EDT
It's probably worth noting this in Common Bugs as we don't know what's causing it...
Comment 38 Fred 2011-10-03 22:08:20 EDT
(In reply to comment #36)
> are you using --format when writing the USB stick, or not? I tend to use
> --format.

Yes I use both --format and --reset-mbr . It seems compulsory for F16 as otherwise the key doesn't boot. I don't think I had this issue with F15, but that's really not a problem imho (maybe documentation should be updated if confirmed though).
Comment 39 Adam Williamson 2011-10-04 00:46:46 EDT
oh. so, i think i know what causes this now...

[adamw@adam ~]$ echo $LANG
[adamw@adam ~]$ cat /etc/fedora-release
Fedora release 16 (Verne)
[adamw@adam ~]$ 

and in /usr/bin/livecd-iso-to-disk :

echo "Updating boot config file"
# adjust label and fstype
if [ -n "$LANG" ]; then
    kernelargs="$kernelargs LANG=$LANG"

so it looks like livecd-iso-to-disk tries to write a language parameter based on the system on which the USB stick is created, and it's writing it in a form which the installer isn't happy with.

I'm not sure if it's right for livecd-iso-to-disk to this at all, frankly. Why should we assume the USB stick is going to be _used_ on the same system and by the same person as the ones where it's being _created_?

This dates back to:

commit 827cd5bb05fb45a6df1ae907e63b7213af5b8501
Author: Bill Nottingham <notting@redhat.com>
Date:   Sat Sep 11 13:09:50 2010 -0500

    Set default boot language for USB images to the current locale.
    Signed-off-by: Bruno Wolff III <bruno@wolff.to>

so I think it would be in F15 and F16, but then, I don't think this bug hit F15; maybe anaconda in F15 was more tolerant to the 'wrong' lang setting?
Comment 40 Adam Williamson 2011-10-04 00:48:50 EDT
echo $LANG returns 'en_US.utf8' on 14, 15 and 16, so doesn't look like that's changed for a while...
Comment 41 Ales Kozumplik 2011-10-04 01:38:04 EDT
*** Bug 742355 has been marked as a duplicate of this bug. ***
Comment 42 Ales Kozumplik 2011-10-04 01:45:20 EDT
I am not really sure we support a usb stick created from the non-live dvd using the livecd-iso-to-disk tool. That simply is wrong and this might be closed as won't fix.

(In reply to comment #40)
> echo $LANG returns 'en_US.utf8' on 14, 15 and 16, so doesn't look like that's
> changed for a while...

Something did in fact, we now generate some of the locales data ourselves if loader is run (conversely on a livecd where loader doesn't run they are already present on the cd).

I will take a look at this, as this causes the installation to fail whenever someone passes lang=en_US.utf8 as the kernel boot line (which is what the livecd tools added there for us). However, note that this won't in any case guarantee usb sticks made in the described way are able to install anything. I think you need to use a different tool, perhaps just dd would do the trick?
Comment 43 Jes Sorensen 2011-10-04 02:29:21 EDT
(In reply to comment #42)
> I am not really sure we support a usb stick created from the non-live dvd using
> the livecd-iso-to-disk tool. That simply is wrong and this might be closed as
> won't fix.


I am sorry but that statement is just absurd. Taking the standard DVD image
and putting it on a USB stick to avoid burning a DVD is one of the most
common ways of installing Fedora and has to be supported.

Live CDs are just CDs and not complete, there are many cases where you want
to do an install where you don't have net access or lousy net access, so
having to download the rest isn't an option.

Anaconda's handling of LANG needs to be fixed.

How about applying a LANG filter as anaconda is launched which converts
$LANG into any of the values anaconda supports?

Comment 44 Adam Williamson 2011-10-04 02:34:57 EDT
well, just tested and I can reproduce this indeed, now I figured out the procedure exactly :/.

gonna have a look at f15 and see exactly what happens there.
Comment 45 Adam Williamson 2011-10-04 02:42:56 EDT
ales: using livecd-iso-to-disk with the DVD has worked for a long time and is at least de facto supported. note that you can't, for instance, produce a USB stick which is EFI bootable with a simple dd, but you can with livecd-iso-to-disk .

We do reference this sometimes in documentation - https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB claims:

"The livecd-iso-to-disk method also works with DVD install iso images, even though these are not Live images."

and the ability to write the DVD was intentionally written into livecd-iso-to-disk by wtogami:


I think overall we do kind of intend for this to work.
Comment 46 Ales Kozumplik 2011-10-04 02:59:22 EDT
(In reply to comment #45)
> ales: using livecd-iso-to-disk with the DVD has worked for a long time and is
> at least de facto supported. note that you can't, for instance, produce a USB
> stick which is EFI bootable with a simple dd, but you can with
> livecd-iso-to-disk .

OK, I stand corrected. In that case we are actually good because once I fix the language problem the whole thing should work.

Proposing as NTH.
Comment 47 Adam Williamson 2011-10-04 15:08:28 EDT
note that I think the 'incorrect' LANG variable comes from Live installs. It seems that if you boot an F14/F15/F16 live image (and install from it), you get LANG=en_US.utf8 , but if you install from the netinst or DVD, you get LANG=en_US.UTF-8 . I'll have to look into that and file a separate bug.
Comment 48 Ales Kozumplik 2011-10-05 04:44:32 EDT
Some information/explanations for those involved in Anaconda locale settings:

1) because of its considerable size we no longer ship /usr/lib/locale/locale-archive on the installation ramdisk (lorax commit ee955f3ad1ae6b7b302da169d8528742b9df6abf), instead there are source files for all locales used by Anaconda.

2) depending on several factors (lang= boot arg, user choice, dvd installation etc.) we generate locale-archive using 'localedef'. We usually do so in loader but this has failed in the case of our bug.

3) skipping loader (dvd installs) without a lang= argument was causing problems before, that's why second point of locale generation was introduced in Anaconda (Anaconda commit eb7732732d579af57d194131b61e75f5750e19a6). This is indeed triggered in our case too and default en_US.UTF-8 locale is generated (despite the lang=en_US.utf8 paramter on the command line that we don't recognize at the moment). Unfortunately the way the locale module works is remembering the existing compiled locales at its initialization. So a later call to

 locale.setlocale(locale.LC_ALL, "")

 fails nontheless.
Comment 49 Ales Kozumplik 2011-10-05 08:11:14 EDT
Fix posted for review: https://www.redhat.com/archives/anaconda-devel-list/2011-October/msg00021.html
Comment 50 Adam Williamson 2011-10-07 15:10:40 EDT
Discussed at 2011-10-07 NTH review meeting. Accepted as NTH due to severity of impact, can break install without obvious workaround.
Comment 51 Ales Kozumplik 2011-10-10 06:56:33 EDT
Fix pushed to f16-branch: 1af4774178adb994d20016509375e7569b7fc100, 572c04330dbd6185693fb556a9c6e46355d3bc66.
Comment 52 Ales Kozumplik 2011-10-10 07:48:19 EDT
Fixed on master: 152149133732a45a13f3c8ab728de767536a09ab, fd6085f6c5812373d4b1bdbefd6a10aa9eff2e61.
Comment 53 Fred 2011-10-10 08:40:56 EDT
Great. Thank you very much for all the efforts. What would be the best way to test a new image now (or should I say: where do I find an image to test)?
Comment 54 Ales Kozumplik 2011-10-10 09:01:32 EDT
New .isos are put to pub/fedora/linux/development/16 on your favourite Fedora mirror. You'll have to wait around a week for the new Anaconda version to propagate there.
Comment 55 Ales Kozumplik 2011-10-10 09:18:42 EDT
*** Bug 744029 has been marked as a duplicate of this bug. ***
Comment 56 Fred 2011-10-18 06:57:46 EDT
Fixed in Alpha TC1 (command line still has the uft8 parameter but anaconda has no issue with it).
Comment 57 Jes Sorensen 2011-10-18 07:46:10 EDT
Can confirm it seems to survive for me in TC1 as well

Comment 58 Adam Williamson 2011-10-18 19:09:03 EDT
Thanks for testing! Let's close this.
Comment 59 Adam Williamson 2011-11-07 23:32:45 EST

Fedora Bugzappers volunteer triage team

Note You need to log in before you can comment on or make changes to this bug.