10.1.3 image and Firmware q2e42

[James Cameron]

G'day,

I'm puzzled.

If you based your image on OLPC OS 10.1.3 then after installation the
firmware will be automatically upgraded to Q2E45, so you should test
with Q2E45.

If you based your image on Dextrose os439dx, the same thing should
occur, since it contains Q2E45 firmware.

If it does not occur because of not being signed, you can sign the
firmware, during image build, with your deployment keys.  (This is
assuming you have deployment keys in your secured laptop population).

Are you intending to prevent the firmware update that Dextrose normally
performs?

For OLPC OS 10.1.3, it was tested with Q2E45, and so we don't really
know how it will go wrong with Q2E41.

For Dextrose, I imagine the same testing limitation was imposed.   I
think you've found at least one way it goes wrong; the keyboard mapping.

You should review the full list of changes since Q2E41 to fully evaluate
them.  Paul didn't mention some that concern me:

Q2E42

- key delegation, (you can ignore this if you do not use key
  delegation),

- SMBIOS setup, (effect unknown, there was no test case),

- nbclone to secure XO, (you can ignore this if you do not use nbclone),

- many problems with ext2 filesystem access, (you can ignore this if you
  do not plan to deploy operating system images using ext2 filesystems),

- many problems with USB access, (you can ignore this if you do not plan
  to deploy operating system images on USB drives),

Q2E43

- free cluster tracking in FAT filesystem driver, (you can ignore this
  if you do not plan to capture data using firmware scripts that will
  write to USB or SD with FAT filesystems),

- compatibility with USB keyboards, (you can ignore this if USB
  keyboards won't be connected at the time the laptop is turned from off
  to on).

#9100 you may not be able to reproduce with your test laptops, but may
reproduce on your deployed laptops.  We don't have a firm idea of the
probability distribution, but my estimate is somewhere between 5% and
20% of a population may be affected, depending on manufacturing
variations.  You might control for this risk by monitoring failures and
applying firmware updates only to affected laptops.  (The problem is
caused by the new kernel relying on the contents of memory which is not
initialised by the BIOS).

On Wed, Feb 16, 2011 at 04:15:37PM -0200, Daniel Castelo wrote:
> My question is, the use of setolpckeys in our F11 build could be
> dangerous or incompatible with the keyboard mapping based on HAL?

I'm not sure.  I think you should test it.  Paul may have a response.

-- 
James Cameron
http://quozl.linux.org.au/