zhashfs: write first block last

Daniel Drake dsd at laptop.org
Sun Mar 20 12:49:31 EDT 2011


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



More information about the Devel mailing list