#6400 HIGH Never A: "update streams" wipe out user improvements without notice

[Zarro Boogs per Child]

#6400: "update streams" wipe out user improvements without notice
------------------------------+---------------------------------------------
  Reporter:  gnu              |       Owner:  cscott        
      Type:  defect           |      Status:  new           
  Priority:  high             |   Milestone:  Never Assigned
 Component:  upgrade utility  |     Version:  Build 650     
Resolution:                   |    Keywords:                
  Verified:  0                |    Blocking:                
 Blockedby:                   |  
------------------------------+---------------------------------------------

Comment(by gnu):

 What happened with my single laptop is not the problem here.  I do not
 need to "opt out of forced upgrades".  Forced upgrades need to "opt out"
 of creating problems for 80,000 other G1G1 laptop users!  That's why I
 filed the bug report.  If all I needed to do was fix my laptop, I know how
 to reflash it with a clean build, without telling anybody at OLPC about
 it.

 So:  from email conversation, the real problem we're trying to solve is
 that many G1G1 donors have laptops which run Q2D05 or Q2D06 firmware,
 which can brick if the clock battery jiggles loose.  I agree that this is
 worth fixing.  However, this mass forced Linux software upgrade is
 applying a battleship to swat a fly; and deploying a battleship creates
 other costs and problems.  Let's see whether we can find or construct a
 flyswatter to handle this issue.

   *  It should be possible to remotely upgrade the firmware without
 touching the OS build.       (And it should not have today's bug of
 refusing to allow the machine to boot until AC power is found or faked.
 #5422.  This is not fixed even in modern firmware.  Whatever firmware
 version we remotely upgrade them to should fix this.)

 All the other issues around forced-upgrade then don't apply, because you
 aren't changing the NAND filesystem (except to temporarily add a meg of
 signed boot firmware to it, which is removed immediately after the
 reflash).

 Ideally the remote upgrade should just drop the firmware image into NAND,
 and suggest to the user that they reboot.  It should not force the reboot
 -- particularly if there's no AC power, when the firmware will refuse to
 flash anyway.

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