#2374 NORM Untriag: Autoinstall 528 on B1 fails to activate

[Zarro Boogs per Child]

#2374: Autoinstall 528 on B1 fails to activate
---------------------------+------------------------------------------------
 Reporter:  gnu            |       Owner:  cscott                           
     Type:  defect         |      Status:  new                              
 Priority:  normal         |   Milestone:  Untriaged                        
Component:  new component  |     Version:  Development build as of this date
 Keywords:  DRM, evil      |    Verified:  0                                
---------------------------+------------------------------------------------
 (See bug #2371 for my previous attempt to reflash directly from SD.)

 I plugged a !SanDisk !MicroMate USB-to-SDHC card reader into my B1.  It
 contains a "Transcend SDHC Class 2 8GB" SD card.  The SD card contains a
 carefully made autoinstall image from today's zip file and OS image.  The
 reader makes it accessible as a standard USB Storage device.

 When I powered on with the X game button held, then released the game
 button, it found the USB stick and showed the USB logo.  Then it reflashed
 the NAND, with the usual messages about bad blocks and 6fc (or so) blocks
 written.  I don't think it reflashed the SPI flash.  It then rebooted
 without my intervention, and the kernel started to boot.  There was a bit
 of unfamiliar text on the screen at the bottom, but it was quickly wiped
 out by the kernel logo and the stream of messages from the Linux kernel.
 I stopped them with Ctrl-S at some point, and scrolled back using Shift-
 FN-!PgUp, but the scrollback went all the way back to kernel messages
 marked with time 0, and then preceding time 0 there were some kernel log
 lines with time 159.something that seemed to be misplaced.  Anyway, I
 couldn't find those extraneous messages, which looked like five or six
 lines of chatty text (not from the kernel); perhaps they were from OFW.  I
 never got a good look at them, I don't know if they were about activation
 or not.

 After allowing the console to resume scrolling with Ctrl-Q, it went on
 booting the kernel.  Eventually something happened, it CLEARED THE SCREEN
 and announced that it couldn't activate.
 (I don't know exactly what it said because IT POWERED OFF THE SYSTEM AFTER
 A FEW SECONDS SO I COULDN'T REPEAT IT TO YOU!)  It did report a serial
 number of 0, which makes sense since this B1 doesn't have any
 manufacturing info.

 If there's a problem with machines that have no manufacturing data, why
 doesn't the autoinstall script write new (silly but valid) manufacturing
 data?  Rather than slowly patch every bug in every place that expects to
 see it?

 I can't understand why DRM systems have such a lousy reputation, when this
 one has such a stellar user interface, excels at clearly reporting to the
 user what it's doing, makes it so easy to report error messages verbatim,
 and has clear documentation on what the user can do to fix the problem.
 It's so convenient, both for the end users, and for the engineering staff
 debugging field problems.  How could anyone complain about this?  Things
 will only improve when the full BitFucked design is implemented.  Then
 users will be free to sit back and relax; they can't help at all with
 debugging, because their machine will come pre-bricked and won't let them
 escape to the ok prompt or into a Linux system.  This can't help but make
 those kids and teachers feel engaged and empowered.

 When I power back on and (based on Mitch's IRC suggestion earlier) escape
 to OFW I can see:
 {{{
 ok more u:\leases.dat
 [1, {"SHF00000000": ["20080721T235624Z", "SHF00000000:6A98C1DE-AD3F-43DE-
 A32C-C613926049A:20080721T235624Z"]}]
 }}}
 So it did write something to my USB storage device -- but apparently it
 had trouble swallowing it when later reading it in.

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