Golden image - Githubissues

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?

apertus-open-source-cinema / axiom-firmware

Golden image #158