Ticket #5424 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

In ES Language,display wrong language.

Reported by: johnlin Owned by: bernie
Priority: blocker Milestone: Update.1
Component: x window system Version:
Keywords: Cc: kimquirk, Luna, bernie
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

After add new tag,Keyboard Layout still have problem. It is different in OFW and OS.

Attachments

untitled.bmp (223.0 kB) - added by johnlin 7 years ago.
TAG vaule.bmp (1.7 MB) - added by Xiang.Wei 7 years ago.
correct-language.bmp (1.3 MB) - added by Xiang.Wei 7 years ago.
correct-language.2.bmp (1.3 MB) - added by Xiang.Wei 7 years ago.
wrong-language.bmp (1.7 MB) - added by Xiang.Wei 7 years ago.

Change History

Changed 7 years ago by johnlin

  Changed 7 years ago by jg

  • owner changed from Kim Rose to bernie
  • milestone changed from Never Assigned to Update.1

  Changed 7 years ago by kimquirk

  • cc kimquirk added

If the laptop was booted up before it had all the mfg-data correct, it will create a file olpc-configured based on a US keyboard. It will not update that file if you change the mfg-data later.

To see if this is the problem, please open a virtual terminal and type: -bash-3.2# rm /.olpc-configured -bash-3.2# reboot

What is the result after this test?

  Changed 7 years ago by Luna

  • cc Luna added

Get the test result by factory RD as below:

I and PE software member have verified the method is fail ,mentioned in the below mail . we found the defective symptom still.

I feel surprised that when we remove /.olpc-configured,then reboot,enter into XO,we find the Keyboard layout is changed.but the language version is still English

Please tell us, the result is right or there is still question exist? thanks

  Changed 7 years ago by bernie

  • cc bernie added

Looks like a consequence of this:

http://dev.laptop.org/ticket/5133

And the fix is what kim suggested already:

# rm /.olpc-configured (reboot)

Or, use copy-nand to load the ship.2 image rather than upgrading to it from earlier releases.

And make sure the KV,KL,KM tags are already set in OFW when Ship.2 boots for the first time.

  Changed 7 years ago by bernie

  • status changed from new to assigned

  Changed 7 years ago by bernie

Please let me know if this help, and I will close this bug.

  Changed 7 years ago by Xiang.Wei

I am factory RD ,I have verified the procedure with PE sofeware member,the result is fail。 later,I try to combine the two methods,and I have just do it,steps as below:

(1) copy-nand disk:\OS650.IMG(ship.2 IMG) (2) .mfg-data ,check TAG value,it's right (3) boot ,enter into OS,find the wrong language version (4) remove /. olpc-configured,then reboot (5) boot nand again ,find the wrong language version still

Is it right or not ? if step is correct,that is ,um~, the method and explanation you give maybe have some problem

  Changed 7 years ago by Xiang.Wei

Now,I use the SKU5 OLPC to the test,the steps as below : (1)using the BIOS: Q2D07 & IMG: 650,enter into XO,the language version displays as English========>It's wrong (2) then using the BIOS: Q2D03 & IMG: 623,enter into XO,the language version displays as Spanish========>It's correct Of course,the TAG value have not been changed during the two procedures. If the TAG value really explain the language version, why the same TAG value show two kinds of language?

(please see the attached photograph)

Changed 7 years ago by Xiang.Wei

Changed 7 years ago by Xiang.Wei

Changed 7 years ago by Xiang.Wei

Changed 7 years ago by Xiang.Wei

  Changed 7 years ago by Xiang.Wei

sorry,I would like to emphasize that I did not alter any TAG value during the two procedures.I just only change different BIOS & IMG,then display different language version! thanks

follow-up: ↓ 11   Changed 7 years ago by AlexL

It looks like the keyboard layout is being done correctly, but the language variable is not. From looking at the script /home/olpc/olpc-configure, it seems like when the keyboard variables are set (configure_root), .olpc-configured is set to the variable OLPC_CONFIGURE_VERSION. Before setting the language, there is a check to see whether the value in .olpc-configured is equal to OLPC_CONFIGURE_VERSION. The configuration of the language is only done if this is false. Of course, it is true because the function run before it already made it true.

Either there need to be two variables, one for root configure version and one for home configure version, or configure_root shouldn't be setting the .olpc-configured file.

I will talk with bernie to see if this is truly the cause or not.

in reply to: ↑ 10   Changed 7 years ago by AlexL

Replying to AlexL:

It looks like the keyboard layout is being done correctly, but the language variable is not. From looking at the script /home/olpc/olpc-configure, it seems like when the keyboard variables are set (configure_root), .olpc-configured is set to the variable OLPC_CONFIGURE_VERSION. Before setting the language, there is a check to see whether the value in .olpc-configured is equal to OLPC_CONFIGURE_VERSION. The configuration of the language is only done if this is false. Of course, it is true because the function run before it already made it true. Either there need to be two variables, one for root configure version and one for home configure version, or configure_root shouldn't be setting the .olpc-configured file. I will talk with bernie to see if this is truly the cause or not.

sorry, I didn't look at the code closely enough. There are in fact two variables. The problem is definitely with olpc-configured, and once bernie gets here, we can figure out exactly what it is.

follow-up: ↓ 13   Changed 7 years ago by AlexL

In fact, there appears to be many problems with olpc-configure, which have been fixed in Joyride. The problem experienced here is that configure_home() is run before configure_root(), and it is in configure_root() that the language and keyboard variables are set. This is why the LANG variable in /home/olpc/.i18n is empty.

in reply to: ↑ 12   Changed 7 years ago by bernie

Replying to AlexL:

In fact, there appears to be many problems with olpc-configure, which have been fixed in Joyride. The problem experienced here is that configure_home() is run before configure_root(), and it is in configure_root() that the language and keyboard variables are set. This is why the LANG variable in /home/olpc/.i18n is empty.

I think your analysis is correct. In #5133, I failed to recognize this additional failure mode and described the problem as only happening on updates.

To solve this, we could proceed like this: we install the olpc-utils-0.53 RPM from Joyride on a Ship.2 build, test it both on updates and new installs, and then roll a new Ship.2 build with just this change.

Alternatively, we could suggest Quanta to edit /home/olpc/.i18n to set LANG="en_UY.UTF-8" manually on all machines.

  Changed 7 years ago by AlexL

Yes, the new olpc-configure file looks much better. On 650, I overwrote the olpc-configure file with the one from Joyride 1415. I then changed the language and keyboard configuration files to the wrong things, and rebooted. The laptop came up correctly in spanish, and all the variables were set correctly. I didn't have to remove the .olpc-configured files because they were at version 2 and the one in joyride was version 5. Also, it is good to note that the terminal doesn't come up in the spanish layout until after another reboot, which makes sense.

Questions: What is the correct upgrade test? (build numbers, etc) Should we try this with the rpm, or is changing out the file sufficient? What other things could possibly be affected/broken by this change? (so we can make sure they weren't broken)

  Changed 7 years ago by bernie

olpc-utils-0.48.2 should fix this.

The patches we applied are in the ship.2 branch:

http://dev.laptop.org/git?p=projects/olpc-utils;a=shortlog;h=ship.2

Please review these changes. Build 652 will be out shortly with these fixes.

  Changed 7 years ago by Xiang.Wei

I use the Build 653 to verify the language version, it’s correct , and after reboot ,the keyboard layout have been done correctly in OFW and OS.

  Changed 7 years ago by bernie

  • status changed from assigned to closed
  • resolution set to fixed

This seems to be fixed at last. Thank you!

Note: See TracTickets for help on using tickets.