#10040 HIGH 1.5-sof: OFW unable to burn 4GB image onto 4GB SD card

[Zarro Boogs per Child]

#10040: OFW unable to burn 4GB image onto 4GB SD card
------------------------------------+---------------------------------------
           Reporter:  wad           |       Owner:  cjb                              
               Type:  defect        |      Status:  new                              
           Priority:  high          |   Milestone:  1.5-software-update              
          Component:  build-system  |     Version:  Development build as of this date
         Resolution:                |    Keywords:                                   
        Next_action:  diagnose      |    Verified:  0                                
Deployment_affected:                |   Blockedby:                                   
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by Quozl):

 I urge caution; using ''resize2fs'' this way means we're now also using
 Linux as an installer, rather than just an image builder and image runner.

 Previous Linux distributions have solved the initial layout variability by
 running an installer than does ''mke2fs''.  We haven't had to; there's
 enough functionality in !OpenFirmware to let us unpack an image block by
 block.  Apart from adding ''mke2fs'' and ''tar'' support to !OpenFirmware,
 or writing an installer, I've no suggestion.  ;-)

 I'm also not sure that testing by pulling the power during ''resize2fs''
 will generate useful conclusions.  A code review might be more
 appropriate.  The comment in ''resize2fs.c'' immediately prior to
 ''move_itables()'' says:

 {{{
 /* Resize processing, phase 5.
  *
  * In this phase we actually move the inode table around, and then
  * update the summary statistics.  This is scary, since aborting here
  * will potentially scramble the filesystem.  (We are moving the
  * inode tables around in place, and so the potential for lost data,
  * or at the very least scrambling the mapping between filenames and
  * inode numbers is very high in case of a power failure here.)
  */
 }}}

 Lastly, the man page for ''resize2fs'' has this gem: "''If the filesystem
 is mounted, it can be used to expand the size of the
 mounted filesystem, assuming the kernel supports on-line resizing.''" ...
 and ''fs/ext3/resize.c'' points out in the comment to
 ''ext3_group_extend()'' that a resize can be done with ''mount'' options
 "remount,resize=<size>".  This looks more fun than ''resize2fs''.  Does it
 work for us?

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