Bug 480830 - Anaconda fails when upgrading a system which is set to Romanian via preupgrade (F8->F10)
Anaconda fails when upgrading a system which is set to Romanian via preupgrad...
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F11Target
  Show dependency treegraph
Reported: 2009-01-20 14:41 EST by Răzvan Sandu
Modified: 2013-01-10 00:01 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-04 10:08:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Error message when anaconda exits abnormally (486.29 KB, image/jpeg)
2009-06-18 09:43 EDT, Răzvan Sandu
no flags Details

  None (edit)
Description Răzvan Sandu 2009-01-20 14:41:12 EST

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:

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).
Comment 1 Răzvan Sandu 2009-01-20 14:48:07 EST
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,
Comment 2 Will Woods 2009-01-20 14:59:21 EST
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.
Comment 3 Jesse Keating 2009-01-20 20:09:47 EST
This is something we should fix for F11, but it's not an alpha blocking issue.
Comment 4 Răzvan Sandu 2009-01-21 01:22:06 EST
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,
Comment 5 Răzvan Sandu 2009-01-21 01:48:23 EST
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 ;-) .

Comment 6 Chris Lumens 2009-01-21 10:04:29 EST
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.
Comment 7 Răzvan Sandu 2009-01-21 15:21:00 EST
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

Best regards,
Comment 8 Andy Lindeberg 2009-02-12 11:33:29 EST
Răzvan, any idea when you'll be able to get the photos?
Comment 9 Răzvan Sandu 2009-04-15 16:09:15 EDT
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.

Comment 10 Răzvan Sandu 2009-06-18 09:21:37 EDT
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,
Comment 11 Răzvan Sandu 2009-06-18 09:43:53 EDT
Created attachment 348463 [details]
Error message when anaconda exits abnormally
Comment 12 Alexandru Szasz 2009-06-18 10:07:41 EDT
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 ?
Comment 13 Răzvan Sandu 2009-06-21 02:49:52 EDT
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.

Comment 14 Bug Zapper 2009-11-16 04:46:26 EST
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:
Comment 15 Bug Zapper 2010-11-04 07:33:21 EDT
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: 
Comment 16 Răzvan Sandu 2010-11-04 08:33:58 EDT

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.

Comment 17 Chris Lumens 2010-11-04 10:08:29 EDT
Thanks for the information.

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