[Trac #673] Maintenance tasks (such as upgrades) should be done in Linux whenever possible

[Zarro Boogs per Child]

#673: Maintenance tasks (such as upgrades) should be done in Linux whenever
possible
------------------------------+---------------------------------------------
 Reporter:  rminnich          |       Owner:  orospakr 
     Type:  defect            |      Status:  new      
 Priority:  blocker           |   Milestone:  Untriaged
Component:  develop-activity  |    Keywords:           
------------------------------+---------------------------------------------
 I went to upgrade my B-1 unit to the 212 release. The process involves
 installing a few files on a USB stick, and then having open firmware run
 an OFW script resident on the USB stick, accessing files on the USB and
 rewriting BIOS FLASH and NAND FLASH. This Forth script manages FLASH
 upgrades, version information, file system initialization, and so on --
 all based on OFW functionality that must already be present and working in
 the current FLASH before the new FLASH can be installed.

 If we have learned one thing over the past months, it is that USB is a
 moving target. I can not find a single USB stick in my house that the
 current OFW can understand. Conversely, the Linux on the current NAND
 FLASH has no trouble at all with any of my USB sticks -- the Linux USB
 guys seem to cover all the bases.

 While it is true that I might somehow contrive to flash bits of the ROM
 and so hope to get an OFW that can understand my USB stick, the automatic
 nature of the update will have been lost. I am probably going to have to
 work around this problem, but I doubt we want to present millions of users
 with this kind of situation.

 This experience points out a problem with our current, OFW-based, update
 strategy: it lacks flexibility, and is not resilient in the face of
 changing USB targets, such as newer USB sticks. The OFW drivers in FLASH
 have to work with your USB stick for upgrade, or you can not upgrade.

 In contrast, if we were to use a Linux + initrd combo on the USB stick for
 managing upgrades, and boot that, we would have several paths to booting
 to an upgrade kernel and tool:

 1. boot upgrade kernel from OFW, use Linux-based upgrade tool

 2. The Linux on the NAND flash could kexec the Linux on the USB stick, and
 one can upgrade from that point.

 3. In the event that the USB stick can't work with the kernel in NAND
 flash, and an upgraded kernel has to be used to read a USB stick, the
 upgraded kernel could be loaded over the network, and kexec'ed, and from
 there either pull down a new NAND image from network or USB stick.

 These three examples show the flexibility that would be possible with a
 Linux-based upgrade tool.

 Right now, I'm stuck. OFW can not use my USB sticks; but, at the same
 time, the only upgrade tool I have is written in Forth, and no tool save
 OFW can interpret that script. I can't upgrade from Linux. I can't upgrade
 to an OFW that might be able to read this stick, as the upgrade tool
 requires an OFW that can read the stick -- Catch 22.

 This setup lacks a needed flexibility.

 I would like to suggest that we do the following: rewrite the upgrade
 script in Python and provide a USB image which includes minimal Python
 functionality to run the script. This change would greatly increase our
 flexibility, as we would have many more options on how to actually perform
 an upgrade:

 1. via USB stick

 2. via NFS root

 3. something that a clever user in Brazil will dream up :-)

 I also think we're putting ourselves in a box with Forth-based maintenance
 tools. There is only one interpreter capable of running those tools, and
 that interpreter is in FLASH. I would suggest the following rules for
 maintenance tools:

 - always run under Linux

 - written in Python

 - update images include all support (minimal Python in this case) to run
 tools
   (note that on another project I'm building a minimal Python environment
 to support
    Xen -- integrating a minimal Python, even into an initrd, is easy)

 I am putting this proposal up as a straw man. I have no idea as to
 assignment; I do not know if you all will decide that you wish to go for
 it. It is a blocker for me, and, I expect, will be a blocker for many
 people. If there is some security or other reason for using OFW-based
 update that I missed somehow, I'm happy hear it.

 Thanks

 ron

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