Ticket #8715 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

XO doesn't activate in latest build/ofw

Reported by: kimquirk Owned by: cscott
Priority: blocker Milestone: 8.2.0 (was Update.2)
Component: initramfs Version: not specified
Keywords: blocks?:8.2.0 Cc: mstone, gregorio, cscott, kimquirk, edmcnierney
Action Needed: test in release Verified: no
Deployments affected: Blocked By:
Blocking:

Description

Cleaninstalled 8.2-765; q2e18

Set write protect on, then the laptop, CSN7460136E, said it was not activated. I got an activation key from the activation server, added the lease.sig file to the root directory of a USB key, and it did not find it.

The developer key for the same laptop, using the same USB key (in 'security' directory) DOES work.

Change History

Changed 5 years ago by cjb

  • cc cscott added
  • owner set to wmb@…
  • component changed from not assigned to ofw - open firmware
  • priority changed from high to blocker

Mitch, any ideas here?

Changed 5 years ago by wmb@…

  • owner changed from wmb@… to cscott
  • component changed from ofw - open firmware to initramfs

On the USB stick in question, the /lease.sig file in the root directory is in the JSON-encapsulated form as produced by the activation server.

OFW, by design, does not process JSON-format files in the root directory, but rather it processes raw "act01:" records from /security/lease.sig . There is no such file on either the USB key or the NAND.

It is the responsibility of the Linux init code to read the JSON /lease.sig file, extract the relevant record for the machine, and write the raw act01: format file to /security/lease.sig , typically on the NAND. This is apparently not happening, since there is no nand:\security\lease.sig . I also looked in various other places like nand:\versions\pristine\765\security and nand:\versions\run\765\security . There was not lease.sig file in any of those security directories.

Changed 5 years ago by gregorio

  • cc kimquirk added

Hi Scott,

Let us know if this is some kind of mistake or a real issue that deployments will see if they get unactivated XOs.

Kim,

Can we deliver 8.2 to Quanta and ensure that it only gets shipped on activated XOs?

e.g. can we be sure they wont ship 8.2 to Peru?

If so we can consider deferring this one but we will need to have a new image with this resolved as soon as another customers wants to use the release.

Thanks,

Greg S

Changed 5 years ago by gregorio

  • cc edmcnierney added

Changed 5 years ago by cscott

Real issue, related to #7113, #7369, and #7620. When we moved to modular SD/USB in our kernels (which we did in order to allow them to be unloaded during 'extreme power management mode') the necessary code to load SD/USB support was never added to the activation code paths. So, starting with this commit:

http://dev.laptop.org/git?p=olpc-2.6;a=commit;h=279b9db99a30fe60b130a4bed160d54e3bcc7991

on June 20 (http://dev.laptop.org/ticket/7113#comment:10), we've been unable to activate from SD or USB.

olpcrd-0.48 fixes this issue; should be in joyride-2500.

Definitely an 8.2.1 candidate; build 766 should not be put on unactivated machines.

Changed 5 years ago by cscott

  • next_action changed from never set to add to release

Approved by kimquirk for inclusion in build 767.

Changed 5 years ago by cscott

  • next_action changed from add to release to test in release

Packages added to stable repository in commit 7fac25ba for build 767. Please confirm the package versions are correct and test in stable build 767 or later.

Changed 5 years ago by frances

Kim, are you testing this with the gg-767-4?

Changed 5 years ago by kimquirk

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

Fixed in latest signed gg-767-4.

Note: See TracTickets for help on using tickets.