#5174 HIGH Never A: Shallow copy is not atomic - shutdown during first boot is fatal

[Zarro Boogs per Child]

#5174: Shallow copy is not atomic - shutdown during first boot is fatal
-----------------------+----------------------------------------------------
  Reporter:  kimquirk  |       Owner:  jg            
      Type:  defect    |      Status:  new           
  Priority:  high      |   Milestone:  Never Assigned
 Component:  distro    |     Version:                
Resolution:            |    Keywords:                
  Verified:  0         |  
-----------------------+----------------------------------------------------
Changes (by wmb at firmworks.com):

  * owner:  wmb at firmworks.com => jg
  * component:  ofw - open firmware => distro


Comment:

 For the best possible user experience, the first boot should be happen
 quickly.  The rest of this comment will explore ways that we could make
 that so.

 Possiblity 1) Don't do shallow copies.  This would require wholesale
 changes in the update approach, so this is not an easy change.

 Possiblity 2) (As mentioned above) - Have the factory do a partial boot
 after imaging the NAND FLASH, thus pre-creating the shallow copy.  There
 might be an issue with having to do some sort of activation first, and
 there would certainly be an issue with adding a time-consuming step to the
 manufacturing process.

 Possibility 3) In OLPC's release process, create the base .img file as
 usual, then load it onto a machine with "ak", boot it through the shallow-
 copy phase (but not to the point where a sugar nick is assigned), reboot
 back to OFW, save-nand, then sign the result and submit that to Quanta.
 This is procedurally cumbersome at the OLPC end, but requires no new
 tools.  The pain is incurred once per release to manufacturing, instead of
 for every end user.

 Possibility 4) Fix mkfs-jffs2 to support hard links and amend the pilgrim
 build process to do the shallow copy at build time.  This solves the
 problem to the same degree as (3), and can be automated, but requires a
 fair amount of coding and extensive testing of the new tools.  We should
 probably do it eventually.

 (3) seems like a decent stopgap approach.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5174#comment:1>
One Laptop Per Child <http://dev.laptop.org>
OLPC bug tracking system