Hide Forgot
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][4] 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 ?
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. ...
Actually, it is enough to switch vt's and the traceback has already occurred (do not need to terminate x to see this error).
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).
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.
(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 ?
(In reply to comment #5) > would be worth getting [a fix] into the release images at least ?
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.
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.
(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 ?)
> > 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.
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.
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
(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
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.
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.
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
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.
*** Bug 530278 has been marked as a duplicate of this bug. ***
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...
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
*** Bug 530718 has been marked as a duplicate of this bug. ***
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?
Patch pulled in for anaconda-12.40-1 as well.
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
Well done Adam - thanks very much for your efforts, and those of the developers.
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
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
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.
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
*** Bug 532088 has been marked as a duplicate of this bug. ***
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 ?
don't think so, it's the same bug for all of 'em after all. we're pretty confident this one's zapped. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers