[Trac #1027] OS Installation Failure

[Zarro Boogs per Child]

#1027: OS Installation Failure
---------------------------------+------------------------------------------
 Reporter:  wmb at firmworks.com    |       Owner:  wmb at firmworks.com
     Type:  defect               |      Status:  new              
 Priority:  normal               |   Milestone:  Untriaged        
Component:  ofw - open firmware  |    Keywords:                   
---------------------------------+------------------------------------------
 Scott Tuddenham has a problem installing build 285 on his new B2 system.

 He got a 2 GB USB key and, using WinXP, copied the build 285 NAND image
 file onto it.  The first attempt resulted in a bad md5sum.  A later copy
 attempt gave a good md5sum.

 After using OFW to copy the image from the USB key to NAND FLASH, the
 subsequent attempt to boot resulted in the system hanging with the OFW
 screen still up - no Linux startup black screen.  The last progress icon
 was an XO symbol, indicating that the vmlinuz image had been loaded into
 memory.

 I (Mitch) worked with Scott on IRC to examine the vmlinuz image in memory.
 We found that the data was correct for the first 0x18000 bytes, but the
 next several (at least 0x40, perhaps more) bytes were all 0, which is not
 correct.  There is supposed to be x86 machine code at that offset.

 "dir nand:\" and "dir nand:\boot\" showed reasonable directory listings.

 The loaded size of the vmlinuz image in memory was correct.

 This suggests to me that some of the JFFS2 nodes on the NAND FLASH are
 corrupted, resulting in (zeroed) holes in the file.  If we assume that a
 NAND block or page contains bad data, it is unclear at this point where
 the data first became bad.  It could have happened in the copy from WinXP
 onto the USB Key (which should have shown up in the md5sum, but perhaps a
 user error resulted in an mistaken check).  It could have happened when
 OFW was reading the file from the USB key (perhaps a transient read error,
 or maybe a mistake in OFW's file system handling code that caused a bad
 read).  Or it could have happened when writing the data to NAND FLASH.

 I have provided a set of diagnostic tools for analyzing the integrity of
 the images on the USB key and on the NAND FLASH.

 Scott ran at least one of the tests - the report is unclear which - and
 mentioned the number 630 without specifying the exact context.  I do not
 know how to interpret that number out of context, except to point out that
 the number of erase blocks in the build 285 image is 768, so the tests
 should have proceeded to that number.

 The number 630 (hex) corresponds to an image size of 207 MB, which does
 not match any of the JFFS2 images for build 285.

 I downloaded
 http://olpc.download.redhat.com/olpc/streams/development/build285/devel_jffs2
 /olpc-redhat-stream-development-build-285-20070305_1036-devel_jffs2.img
 (using a WinXP system), copied it to a USB key, verified its md5sum, and
 used copy-nand to install in on one of my machines.  It then booted just
 fine, so I think that the  download image is okay.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1027>
One Laptop Per Child <http://laptop.org/>