#10316 NORM Not Tri: XO-1 "Journal Full" - did 'olpc-update' take too much room in jffs2 ?

[Zarro Boogs per Child]

#10316: XO-1 "Journal Full" - did 'olpc-update' take too much room in jffs2 ?
------------------------------------+---------------------------------------
           Reporter:  mikus         |       Owner:                                   
               Type:  defect        |      Status:  new                              
           Priority:  normal        |   Milestone:  Not Triaged                      
          Component:  not assigned  |     Version:  Development build as of this date
         Resolution:                |    Keywords:                                   
        Next_action:  never set     |    Verified:  0                                
Deployment_affected:                |   Blockedby:                                   
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by Quozl):

 > What you are pointing out here is that 'olpc-update' lets stand all
 changes I've made to the content of the previous build.

 Yes.  If this was not done, then the boot to previous operating system
 feature (using the game keys) would not work.

 > Why would 'olpc-update' think it needed to repair 300 MB of files?

 The reason ''olpc-update'' must repair 300 MB of files is that ''olpc-
 update'' has the task of creating a filesystem tree that matches the
 filesystem tree that was built by the release engineer, and you had
 modified 300 MB of files.

 > ... why, without notice, 'olpc-update' can leave the system in a state
 where unexpected warnings appear ...

 The reasons ''olpc-update'' may leave the system in a state where
 unexpected warnings appear are:
  * the builds currently available are a substantial proportion of the
 storage space available on the laptop,
  * ''olpc-update'' does not and cannot manage the customisations you have
 made, or the journal contents a child may have created, and;
  * the warning logic is simplistic, assuming that only the child can cause
 the conditions leading to the warning.

 I expect a deployment in your position (with a goal of maintaining a set
 of significant 300 MB customisations over several release cycles) would
 use ''olpc-os-builder'' to construct their own builds, and then use a
 local ''olpc-update'' server rather than the server that OLPC provides.

 The ''olpc-update'' server that OLPC provides is the backstop for laptops
 where a deployment isn't providing any customised build; such as the
 developer and tester community, or tiny deployments.

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