Red Hat Bugzilla – Full Text Bug Listing
|Summary:||anaconda traceback in getDefaultTimeZone KeyError en_AU|
|Product:||[Fedora] Fedora||Reporter:||David Timms <dtimms>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, awilliam, bnocera, campbecg, civil, gawain.lynch, jlaska, mvanross, robert, tcallawa, teh_drmad, tore, vanmeeuwen+fedora|
|Fixed In Version:||anaconda-13.5-1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-10-30 12:54:28 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description David Timms 2009-10-11 04:39:15 EDT
Description of problem: installer stops while still in text mode, with a traceback. The install seems to be halted for ages, and I ctrl-alt-backspace it. Note this is an attempted preupgrade driven install using Fedora 11 x86 as the base. Version-Release number of selected component (if applicable): anaconda 12.32 How reproducible: Twice, same machine. Steps to Reproduce: 1. f11 i386 2. yum update 3. yum install preupgrade 4. preupgrade 5. select rawhide 6. start upgrade > machine reboots, chooses the preupgrade grub entry > loads kernel, does stuff, screen goes blue Actual results: Machine sits there for at least 5 minutes. Eventually screen is put to sleep due to inactivity. Mouse / kb activity wake screen up, but screen is black. Press ctrl-alt-backspace: top 3/4 of screen is blue Running anaconda 12.32, the Fedora syste, installer - please wait. 05:56:20 Starting graphical installation. Traceback (most recent call last): File "/usr/bin/anaconda", line 938, in <module> anaconda.id.timezone.setTimezoneInfo(anaconda.id.instLanguage.getDefaultTimeone()) File "/use/lib/anaconda/language.py", line 218, in getDefaultTimeZone return self.localInfo[self.systemLang] KeyError: 'en_AU' install exited abnormally [1/1] you may safely reboot your system mini-wm Expected results: Installer begins. Additional info: Anaconda has chosen the nouveau driver (FX5600), which may also be troubled ?
Comment 1 David Timms 2009-10-11 04:47:34 EDT
Created attachment 364371 [details] /tmp/ contents (minus the install.img) ie logs, preupgrade command etc. anaconda.log: ... 05:56:08 INFO : setting up kickstart 05:56:08 ERROR : got to setupCdrom without a CD device 05:56:08 ERROR : unable to set to requested language en_AU 05:56:08 INFO : starting STEP_STAGE2 ... 05:56:20 INFO : Started mini-wm 05:56:20 ERROR : Error running xrandr: None 05:56:20 ERROR : Exception when running xrandr: Error running xrandr: None 05:56:20 INFO : Starting graphical installation. ...
Comment 2 David Timms 2009-10-11 04:50:30 EDT
Actually, it is enough to switch vt's and the traceback has already occurred (do not need to terminate x to see this error).
Comment 3 David Timms 2009-10-11 06:08:07 EDT
I rebooted the F11, System admin|language, chose en botswana. Reran preupgrade, it places en_XX.UTF8 in ks.cfg. Adjusted language back to en australian. reran preupgrade, it places en_AU.UTF8 in ks.cfg. Only change on booting the upgrade anaconda is: anaconda 12.35 (change to rawhide that preupgrade retrieved I guess) ... KeyError: 'en+AU.UTF-8' . If I add text to the grub upgrade item, when it gets to the blue screen, the traceback occurs at the top of the text mode screen, immediately (ie don't need vt switch).
Comment 4 Chris Lumens 2009-10-13 13:16:43 EDT
This should be fixed in the next build of anaconda in rawhide, though I have been unable to test. This will not be in F12.
Comment 5 David Timms 2009-10-14 08:16:54 EDT
(In reply to comment #4) > This should be fixed in the next build of anaconda in rawhide, though I have > been unable to test. This will not be in F12. Interesting; do you mean will not be in F12 beta or F12 release ? I would have thought that a crash during upgrade when started via preuprade, would be worth getting into the release images at least ? Is this something specific to my machine, or does it occur for other/all machines ?
Comment 6 David Timms 2009-10-14 08:18:03 EDT
(In reply to comment #5) > would be worth getting [a fix] into the release images at least ?
Comment 7 Chris Lumens 2009-10-14 11:23:24 EDT
It's specific to your locale setting. Basically any locale that's not in the fourth column of the lang-table (http://git.fedoraproject.org/git/?p=anaconda.git;a=blob;f=lang-table) is going to cause this problem. If you temporarily change to en_US.UTF-8, it should work just fine for you. I think this change is too invasive to be brought into F12. If you feel otherwise, please propose it as a blocker and we'll talk through everything to decide whether it gets pulled in or not.
Comment 8 Gawain Lynch 2009-10-14 12:00:16 EDT
Hi Chris, I was able to get around this in the same way you describe. However given that this will affect the majority of Australian users, I'd humbly request that it indeed be considered a blocker.
Comment 9 David Timms 2009-10-14 17:08:26 EDT
(In reply to comment #7) > It's specific to your locale setting. Basically any locale that's not in the > fourth column of the lang-table > (http://git.fedoraproject.org/git/?p=anaconda.git;a=blob;f=lang-table) is going > to cause this problem. If you temporarily change to en_US.UTF-8, it should > work just fine for you. Is it enough to add the entry, or would it need to actually have translations and so forth in anaconda ? > I think this change is too invasive to be brought into F12. If you feel > otherwise, please propose it as a blocker and we'll talk through everything to > decide whether it gets pulled in or not. Having to have a stupid release note to cover something like this could be considered laughable... my vote would to include a fix. Perhaps there is a workaround that can be applied from preupgrade, to avoid the issue, and hence not mess with anaconda ? (without testing, I assume that you are saying that this occurs for iso based upgrades as well ?)
Comment 10 Chris Lumens 2009-10-16 09:35:28 EDT
> > It's specific to your locale setting. Basically any locale that's not in the > > fourth column of the lang-table > > (http://git.fedoraproject.org/git/?p=anaconda.git;a=blob;f=lang-table) is going > > to cause this problem. If you temporarily change to en_US.UTF-8, it should > > work just fine for you. > Is it enough to add the entry, or would it need to actually have translations > and so forth in anaconda ? The entries in lang-table really only correspond to languages with translations, not to dialects/regional variations/whatever you want to call it. So there's really nothing that needs to be done in lang-table. I was showing you that link to explain what set of languages will have problems. > Perhaps there is a workaround that can be applied from preupgrade, to avoid the > issue, and hence not mess with anaconda ? (without testing, I assume that you > are saying that this occurs for iso based upgrades as well ?) There's probably a workaround you could use in preupgrade, but that's probably more trouble than putting my patch through some additional testing and getting it onto f12-branch.
Comment 11 John Webster 2009-10-20 19:20:47 EDT
I get exactly the same message when doing a clean install via the F12 Beta LiveCD. I guess that it can be covered by a release note telling Australians to leave US English as the initial default language should we wish to proceed to install to disk, but it hardly conveys a fair message about F12 quality control. I would vote for fixing the bug prior to release.
Comment 12 Adam Williamson 2009-10-21 13:10:59 EDT
what exactly do you have to do on the live CD install to trigger this? I just did a test install of the F12 Beta live CD, selecting Australian choices where I could - it seemed only at the timezone stage. The install worked, but the locale of the installed system is en_US.UTF-8, so I must have missed something? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 13 Chris Lumens 2009-10-21 13:28:26 EDT
(In reply to comment #12) > what exactly do you have to do on the live CD install to trigger this? I just > did a test install of the F12 Beta live CD, selecting Australian choices where > I could - it seemed only at the timezone stage. The install worked, but the > locale of the installed system is en_US.UTF-8, so I must have missed something? The key steps you're missing are: 3. yum install preupgrade 4. preupgrade
Comment 14 John Webster 2009-10-21 16:59:04 EDT
Sorry Adam, I should have been more precise. When the liveCD offered me the chance to choose a language, I selected Australian English. Fedora then appeared to boot normally (in live user mode). After checking that a few basic things worked OK, I proceeded to install from the live system. That's when the wheels came off the cart. Given the content of the error message, I went back to the beginning, settled for US English, and was then able to proceed to a live install with no problems. I was able to select Melbourne, Australia as my locale during the installation process. However, I am still stuck with US English language and formats.
Comment 15 Chris Campbell 2009-10-21 18:33:04 EDT
Reproduced this bug. I installed a VirtualBox OSE Guest of Fedora 11.92 beta, LiveCD, i686. Upon logging in to the live session, I chose English (Australian) and left keyboard alone. Logged in just fine. Attempted to install to hard drive and Anaconda crashed.
Comment 16 Adam Williamson 2009-10-21 18:59:28 EDT
chris: we are trying to determine whether this bug affects more than just preupgrade usage. comment #11 indicated that it did. it seems the impact is on: a) upgrades from 11 -> 12 on systems with australian locale; it would be nice to know if that affects only preupgrade, or direct media boot upgrades too. b) clean live installs, if you select australian locale when booting into the live CD. will be revisited on Friday... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 17 Chris Lumens 2009-10-22 08:09:52 EDT
Any upgrade will run into this problem, as all preupgrade does is download a bunch of packages and then reboot so anaconda can run upgrade as normal. Here you're hitting it because of the language in the kickstart file. On regular upgrades, you'd hit it because of the setting in /etc/sysconfig.
Comment 18 Chris Lumens 2009-10-22 08:10:24 EDT
*** Bug 530278 has been marked as a duplicate of this bug. ***
Comment 19 Bastien Nocera 2009-10-23 08:13:05 EDT
I've run into this problem trying the live install with F12 Beta, selecting en_GB.UTF-8 in the gdm login screen. This is definitely a blocker for F12, it happens on the Live CD as well...
Comment 20 Adam Williamson 2009-10-23 14:36:08 EDT
Discussed at the blocker review meeting today. Agreed (jlaska, adamw, denise) that even though the fix is quite invasive, this is sufficiently serious that we need it in F12. jlaska will sync up with clumens to try and make sure the fix is carried out as smoothly as possible and to devise a test plan to try and make sure we don't cause regressions. setting back to ASSIGNED for now till we have something testable for F12. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 21 Chris Campbell 2009-10-24 09:23:08 EDT
*** Bug 530718 has been marked as a duplicate of this bug. ***
Comment 22 Robert Laverick 2009-10-25 18:07:47 EDT
I'm seeing the same error via the live CD when selecting en_GB as reported in Comment 19. As this is an error caused in getDefaultTimeZone would a simple fix not be to simply provide a default fall-back (say the US time zone, or GMT/UTC or whatever) in that function when no matching entry is found in lang table rather than erring? Or am I missing something, and this is an indication of a much deeper problem with running anaconda when no match exists in the lang table that will have effects on other parts of the anaconda install?
Comment 23 Chris Lumens 2009-10-26 09:23:07 EDT
Patch pulled in for anaconda-12.40-1 as well.
Comment 24 Adam Williamson 2009-10-28 17:08:48 EDT
A build of anaconda 12.40, which should address this issue, is currently in progress: http://koji.fedoraproject.org/koji/buildinfo?buildID=138787 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 25 John Webster 2009-10-28 17:30:41 EDT
Well done Adam - thanks very much for your efforts, and those of the developers.
Comment 26 Adam Williamson 2009-10-28 17:42:05 EDT
not me doing the work, I'm just noting it down so we know where we're up to :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 27 Adam Williamson 2009-10-29 13:50:54 EDT
anaconda 12.41 was tagged into Rawhide today. a net install from a Rawhide tree updated to today's packages, or a nightly build dated 20091029 or later, should have this fix (make sure the installer says anaconda version 12.41). if you could confirm the fix, that'd be great. thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 28 James Laska 2009-10-30 12:54:28 EDT
Verified the fix using a live image built with anaconda-12.41-1 and following the procedure from John Webster in comment#14. Note the workaround for bug#531052 that is required for a full install as well. Moving to CLOSED RAWHIDE.
Comment 29 Adam Williamson 2009-10-31 01:02:58 EDT
if anyone still has trouble with this with a 20091029 or later Rawhide tree or live CD, please re-open. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Comment 30 Chris Lumens 2009-11-02 09:20:21 EST
*** Bug 532088 has been marked as a duplicate of this bug. ***
Comment 31 David Timms 2009-11-03 17:50:00 EST
I retested, by: - installing F10, en-AU, defaults except for deselect office productivity. - yum --enablerepo=updates-testing update yum preupgrade - preupgrade|view test releases|rawhide (2009-11-02). - reboot to start upgrade - go to bed ;-) - morning: machine is on F12(rawhide) at the login screen :-) The version of anaconda used was anaconda-12.41-1. Confirmed fixed. Do we need additional testing for other out of table locales ?