[Trac #498] Bad filesystem shipped on B1 unit

Zarro Boogs per Child bugtracker at laptop.org
Mon Nov 20 20:15:15 EST 2006


#498: Bad filesystem shipped on B1 unit
---------------------+------------------------------------------------------
 Reporter:  mfoster  |       Owner:  mfoster
     Type:  defect   |      Status:  new    
 Priority:  blocker  |   Milestone:  BTest-2
Component:  distro   |    Keywords:  relnote
---------------------+------------------------------------------------------
 Hi, Folks,

 I don't know if this is a universal problem or not, but the B1 unit that I
 hand-carried back from Quanta had a bad filesystem installed on it.  The
 unit would boot fine out of the box.  However, after updating to Build
 185, the unit would not boot.  At bootup, after displaying the boot
 parameters, OFW waited almost two minutes, then displayed:

 <buffer at 1e43689>:0:

 Can't open boot device

 Further investigation revealed that the bad block table was reporting that
 the last four blocks of the device were all bad: 0x1ff80000, 0x1ffa0000,
 0x1ffc0000, and 0x1ffe0000.  Rebooting with kernel parameter
 cafe_nand.skipbbt=1 and running flash_eraseall revealed that the NAND
 device on this machine really does have a physically bad block at
 0x1ffe0000 - the others were apparently spurious.  Subsequently installing
 Build 185 worked fine.

 The problem is that the factory obviously didn't perform a clean
 flash_eraseall before shipping out this unit, and the question is whether
 this was a unique case or not.  Please check this by performing just a
 nandwrite without a flash_eraseall to see if that's necessary.

 If the units were built in this way, we can expect some very odd results
 from the filesystem until the machines are cleaned up via a flash_eraseall
 and a clean nandwrite.

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



More information about the Bugs mailing list