Re: [Gumstix-users] Replacing the filesystem image from a web browser?

[Craig H. <cr...@gu...>]

On Jun 28, 2007, at 4:25 AM, Heilpern, Mark wrote:

> The wiki contains details behind updating the file system image  
> through the /dev/mtd device (http://docwiki.gumstix.org/ 
> Replacing_the_filesystem_image -- search for flashcp on that page).
>
> As long as your ram disk has enough space to hold the incoming  
> flash image and you can make certain the image is valid and not too  
> large, you should be able to do this via CGI.
>
> A few caveats to consider...
> First, Verdex has an interesting flash process regarding the file  
> system and kernel, since the kernel is no longer in the file  
> system. (I would expect the Connex to adopt this method soon as  
> well.) In that environment, you first erase flash (from 40000 and  
> higher), you then program in the file system, you then erase the  
> top 1MB of flash, and finally you place the kernel into that space.  
> (The last two steps are done with a single command, katinstall,  
> while in U-Boot.)

The new layout also has new /dev/mtd partitioning to cover the 3  
areas of flash.  So it should be pretty easy to update using flashcp  
for each of the pieces (u-boot, rootfs, uImage) in a similar way to  
the instructions above, but adding uImage to the last /dev/mtd device  
as well.

> Second, if you've got an older U-Boot configuration (where bootargs  
> includes "root=1f02") and you install a new kernel that requires a  
> bootargs change (such as "root=1f01"), you could leave the system  
> unable to boot without manual (serial) intervention.

Flashing a new u-boot which has the right default bootcmd will take  
care of this problem.

> Finally, when you're programming the new file system, you will need  
> to be certain that no running process has an open file handle to  
> any file on the flash file system. If anything has an open handle  
> to the old (erased) file system and then reads from it, it will  
> receive corrupted data. Worse, if something writes to an old  
> (stale) file handle, it will possibly corrupt your newly programmed  
> file system.

Yes; and more than that, you need to remount the old rootfs read-only  
or else the kernel might have unwritten buffers which it tries to  
write on top of your newly flashed FS, which will definitely break  
things hard.

C