Skip to content

Conversation

@rroohhh
Copy link
Member

@rroohhh rroohhh commented Jun 25, 2020

This is an effort to make most software problems recoverable by always providing access to a know working ("golden") version.
To do this the following steps are / will be taken:

  • make the root fs btrfs
  • create a ro snapshot that will be the base for the golden version on image creation
  • create a rw snapshot that will be the one modified by the user
  • install a copy of the kernel on image creation as /boot/zImage.golden
  • make the kernel boot using initramfs that does the following
    • it parses the kernel cmdline looking for golden. This is set by u-boot when booting into the golden version.
    • when it is found, it creates a new rw snapshot of the base golden snapshot and boots into that.
    • to do that, it needs to contain a static version of busybox and btrfs-progs

One step that could be done to make this even more robust could be putting the golden kernel (and maybe even a golden BOOT.bin) on QSPI where possible. How to trigger a boot from QSPI (without changing jumper or so) however still needs research.

Open questions:

  • Any way we can boot into the golden version without requiring user interaction?
  • What / should we use compression in btrfs? (we probably need to benchmark this, it could actually help io performance, as most sdcards are not really fast and compression reduces the actual io necessary)
  • Any special options we should enable for btrfs? (Maybe metadata duplication to make everything more robust with a low storage space price?)

@anuejn (and everybody else) any feedback?

@rroohhh rroohhh force-pushed the feature/golden_image branch from 2e5d247 to 9a5052a Compare June 25, 2020 00:56
@apertus-bot
Copy link
Collaborator

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants