#2862 NORM Untriag: olpc-auto.zip (with backup enabled) doesn't work from SD card

[Zarro Boogs per Child]

#2862: olpc-auto.zip (with backup enabled) doesn't work from SD card
----------------------------+-----------------------------------------------
  Reporter:  gnu            |       Owner:  cscott                           
      Type:  defect         |      Status:  new                              
  Priority:  normal         |   Milestone:  Untriaged                        
 Component:  new component  |     Version:  Development build as of this date
Resolution:                 |    Keywords:  olpc-auto                        
  Verified:  0              |  
----------------------------+-----------------------------------------------
Comment (by gnu):

 Replying to [comment:3 cscott]:
 > This is the intended behavior (that is, "not a bug").  The directions
 explicitly state to remove the installation media when the restore has
 completed.

 This is a change from previously working behavior.  It should certainly be
 possible to back up a computer to attached media, and then boot the system
 repeatedly, without having the backup used to destroy the current contents
 of the filesystem!

 > If you are continually updating from build A to build B to build C, it's
 very annoying to have to delete a backup folder if you want the upgrade to
 "really" happen, and we leave the backup file in place so that a teacher
 can use this process to simultaneously update and backup a classroom full
 of XOs.

 I don't understand this sentence.  It seems to be conflating two
 situations.

 First, a developer who's always updating:  The script should upgrade the
 firmware and/or filesystem, regardless of whether there's a backup folder
 (or a file in it) on the media.  I'd hope that you could make more than
 one backup of a machine, without deleting the previous backup!
 A "backup" process that destroys the previous backup isn't much good.

 Second, a teacher updating many XOs and simultaneously backing them all
 up:  Doing such a thing would be useful.  But what's the restore process,
 when needed a week or a month later?  Insert USB stick and power on?  It
 should take much more than that to destroy the current contents of an XO's
 NAND filesystem!

 > So, I appreciate that this doesn't behave the way you would like it to,
 but (at the moment) I don't plan to "fix" this.

 I suggest that the trigger for an automated restore be something much more
 transient than the mere presence of a backup file on removable media.
 Perhaps the auto-install script should write a second file next to the
 backup, marking the machine as a candidate for auto-restore.  Before doing
 the restore, remove the trigger file, so it'll only happen once.  Even
 better would be if the newly installed NAND system image included an auto-
 restore trigger file (perhaps an /etc/init.d script), which only runs
 once, on the first boot.  That way, the backup medium can be mounted
 prudently read-only during a restoration.  (Anyone who's serious about
 backups write-protects them immediately after making them.)

 Perhaps the confusion here is because olpc-auto has a split personality --
 half of it is a non-serious backup system, the other half is a serious
 system updater.  It should either do both things well -- or fall back to
 doing ONE thing well (updating the system).

-- 
Ticket URL: <http://dev.laptop.org/ticket/2862#comment:4>
One Laptop Per Child <http://laptop.org/>