Hi, Quanta reported a problem with XO-1.5 flashing: power can be lost during the fs-update process, but the system will proceed to boot and operate normally at a glance. (I'm sure problems would come up in the long run though)
To fix this, I've modified zhashfs to create .zd files that first of all write the block 0 as all-zero, then write the whole image starting at block 1, then at the very end write block 0 with the real block 0 data. If power is lost during flashing, the start of the disk will be zeroed out -- no chance of the system accidently working in inconsistent state. My changes to the .zd creation also mean the .zsp records the same sequence of block writes. I tested the results, OpenFirmware accepts the resultant .zd file file and powering off midway through flashing indeed results in an unbootable system. I also signed the .zsp and OFW accepted the signature. The only unfortunate side effect is that OFW incorrectly prints a red warning at the end of the flashing process (also in secure mode): WARNING: The file specified 14745 chunks but only wrote 1 chunks It's obviously a bit confused about having written block 0 at the very end, after block 14744. Even if we fix that for future firmware versions, current users upgrading to new software images would see it. So, some questions/outcomes: 1. Is this approach a good idea? 2. Are we bothered by a misleading WARNING message appearing at the end of the flashing process for those running on old/current firmware? (a firmware update would fix this in future) 3. Is this slightly strange block writing sequence expected to affect signing/verification in any way? My testing shows that it works as I've done it, but it would be good to know that the code design agrees with that. 4. Any comments on the zhashfs patch? http://dev.laptop.org/~dsd/20110320/zhashfs-first-block-last.patch Daniel _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
