Hello, Description of problem: Anaconda fails when trying to upgrade a system which is set to Romanian via preupgrade. Version-Release number of selected component (if applicable): How reproducible: Always. Steps to Reproduce: 1. Install stock Fedora 8 (plus all online updates as of January 20, 2009). 2. Set system language & keyboard to Romanian (in graphical mode, via system-config-language and system-config-keyboard, in System -> Administration menu). 3. As root, type "preupgrade-cli "Fedora 10 (Cambridge)" and allow preupgrade to prepare upgrade to F10. 4. Reboot 5. After reboot, upgrade starts and a list of keyboards show up, asking for keyboard layout. "ro" is selected by default. 6. Choose "ro" or "us". 7. Anaconda crashes a few seconds later, with various Python error messages. Actual results: Anaconda crashes. Expected results: Upgrade should perform normally. Additional info: 1. One message I was able to capture was (it is NOT present on every system): "Inconsistency detected by ld.so: ../sysdeps/x86_64/dl-machine.h: 458 elf_machine_rela_relative: Assertion `((reloc->r_info) & 0xffffffff) == 8' failed!" 2. On other system, a reference to "ro_win" keyboard map is explicitly given (ATTENTION, for Romanian language the keyboard setup changed from "ro_win" to "ro" on the ocassion of Fedora 10 release).
I bet this bug can be reproduced not only with the Romanian language setup, but with other languages that need non-English characters as well. From F9 to F10 the default setup for Romanian changed from cedilla-below diacritics (which are NOT correct în Romanian) to comma-below (which ARE correct). But there area many UTF-8 fonts that don't include the necessary "s with comma below" and "t with comma below". Please test this against the future version of Red Hat Enterprise Linux as well. Thanks a lot, Răzvan
As you've correctly guessed, part of the problem is that the keymap listed on your system ('ro_win') doesn't exist in the thing you're upgrading to (F10). We don't currently have a way to handle this, but anaconda should probably continue to accept 'ro_win' (as an alias for 'ro') up until F11 or so. To fix the crash for F11, we'll need those 'various python messages' from comment #1. We'll try to reproduce it during F11 testing, but if you could attach them here that would be very helpful.
This is something we should fix for F11, but it's not an alpha blocking issue.
Hello and thanks, One error message I've got is the one quoted in my initial post, in "Aditional info" section (which I've copied by hand). For the others, the output is too quick and followed by the only option to reboot (preupgrade first prepares upgrade, then you manually reboot, then choose keymap, then anaconda throws errors an offers a reboot immediately after). I've noted that error messages are *different* on various systems where I've tried these. Also, it shows different errors depending on which keyboard setttings one chooses and/or what is written in /etc/sysconfig/keyboard. Please let me know if these final crashes are logged somewhere - the messages are too long and too complex to reproduce without cut & paste. Thanks again, Răzvan
Hello again, There *is* something wrong with the Romanian keymaps in the *stable* release of RHEL/CentOS 5.2. You may reproduce this easily: 1. Install stock RHEL 5.2 (from DVD) 2. Set system to Romanian keyboard and language (via standard tools under System menu) 3. Perform all online updates (as of January 20, 2009) 4. Reboot During boot, when the system tries to load the "ro_win" keymap, FAIL is written in red. The admin must manually put "ro" in /etc/sysconfig/keyboard There are various bugs open, pleading to correct this keymap change collateral effects: bug #472176 , bug #466117 , bug #456211 , bug #450396 , bug #456208 , bug #468081 , bug #450061 . The most important one being the first one ;-) . Regards, Răzvan
If you are receiving a traceback from anaconda, it will also write the file to /tmp/anacdump.txt which you can copy to another machine and then attach to this bug report. If you are receiving some other type of error, they're probably not written anyway so the best thing to do would be to take a picture and attach that.
No, the errors were not tracebacks. The problem is that I've finished upgrading those machines, so I don't have another F8 at hand, for the moment. I'll post the screen photos ASAP, on the first ocassion. Best regards, Răzvan
Răzvan, any idea when you'll be able to get the photos?
Sorry, for the moment I have no F8 systems at hand to perform the update and reproduce the bug. And no test machine around... (honestly, I've gradually switched the Linux routers to CentOS). It may be possible that the issue is the same at F9 -> F10 upgrade, or F10 -> F11. Răzvan
I will reopen this, since it happens exactly the same when trying to upgrade from F10 to F11 via preupgrade. The first stage of preupgrade wents smoothly. After rebooting, anaconda starts, but immediately after the graphical boot loading it exits unexpectedly, complaining about the "ro_win" keyboard setting. This is due to the fact that Romanian keyboard is now "ro", not "ro_win" anymore. I'll attach the photo you've asked for ASAP. This is an ooooooooooold issue in anaconda, when system is configured for Romanian (both in Fedora and RHEL/CentOS). Best regards, Răzvan
Created attachment 348463 [details] Error message when anaconda exits abnormally
Just a note, upstream in xorg, ro_win got renamed to winkeys. Răzvan, did you had set ro_win as a default keymap in the system that is to be upgraded ?
Regarding comment #12 Alex, if the system is older (upgraded from version to version since F7 or so), one doesn't have to set anything INTENTIONALLY. The system HAD "ro_win" as the default keymap... IMHO, anaconda should set "ro" instead of "ro_win" on ALL older Romanian system; it should also install the Terminus fonts (X and console), and make them default system fonts - for safety. Răzvan
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hello, I have no way of testing this old bug, since none of my systems run Fedora 8. I recently upgraded Fedora 13 to Fedora 14 via preupgrade and update went smoothly. Thanks, Răzvan
Thanks for the information.