Opened 6 years ago

Closed 6 years ago

#10818 closed defect (fixed)

interrupting fs-update can lead to bootable system

Reported by: dsd Owned by: dsd
Priority: normal Milestone: Not Triaged
Component: build-system Version: not specified
Keywords: Cc: wmb@…, rsmith, Quozl
Blocked By: Blocking:
Deployments affected: Action Needed: package
Verified: no


Quanta reported that if power is lost during a fs-update run, the system will still boot into Linux afterwards.

This is because the "important" stuff gets written at the start of the disk, and if the end of the disk is not written then you won't see problems until later - but the problems would probably be nasty and confusing.

This can be fixed by tweaking the zhashfs program to create .zd files that write the first block last. As the entire disk is erased at the start of the fs-update process, it means that you will end up with an all-zero sector 0 if you interrupt fs-update, and the system will not boot.

However, these .zd files confuse OFW, which then reports that only 0 of X blocks were written. (the data is written correctly though)

After fixing OFW, we should also modify the .zsp file creation to patch that final routine to avoid the confusing warning. That way, secure mode reflash users won't see a confusing error message.

Unsecure users will see a confusing error until they upgrade their firmware, but we can simply communicate this to the community, and ship the fixed firmware from the very first build image that uses this "new format" (so it would be a one-off).

Quanta will not see any confusing error because they will flash the new firmware which avoids displaying the confusing error message.

Change History (3)

comment:1 Changed 6 years ago by wmb@…

svn 2186 fixes the OFW end of things.

comment:2 Changed 6 years ago by Quozl

Released in Q3A64.

comment:3 Changed 6 years ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

pushed new zhashfs version

Note: See TracTickets for help on using tickets.