| commit | 1cfb19846c9b151f1f6b29848c4732247380b9b6 | [log] [tgz] |
|---|---|---|
| author | Jan Kundrát <jan.kundrat@cesnet.cz> | Mon Oct 30 18:05:47 2017 +0100 |
| committer | Jan Kundrát <jan.kundrat@cesnet.cz> | Mon Oct 30 18:05:47 2017 +0100 |
| tree | 86e554a0e34d2cdc083589bfd6b678253bbad1b1 | |
| parent | 41d2d2675d2092d906d185488e77fadd247f1672 [diff] |
RAUC: Copy old /cfg to the new /cfg during updates It seems that RAUC doesn't really have a concept of hooks that are already located on the system being updated. One could completely replace some steps, but that's not what I want to do because I do not really want to duplicate the logic for rootfs. Instead, let's go with hooks stored in the individual bundles. In the end, I do not think that this is a huge drawback -- the updates will have to contain this hook "somewhere", either in the rootfs, or in the bundle metadata. Having it just in the bundle metadata is no worse. In fact, it's better because changes take effect immediately. How this works: - an empty tarball is needed because RAUC otherwise attempts to mmap() a directory when no image file name is given - because there's an empty tarball, the cfg FS gets wiped at first - this empty tarball is then extracted over the just-made FS - finally, our hooks runs and copies stuff from the existing /cfg into the new /cfg This all means that any configuration changed after this update won't survive a reboot into the new software. This should probably be documented somewhere. Change-Id: I12b11ab93f53f99f1d8875655fa9ec9575830586
This repository contains CzechLight-specific bits for Buildroot. Buildroot is a tool which produces system images for flashing to embedded devices. They have a nice documentation which explains everything that one might need.
Everything is in Gerrit. One should not need to clone anything from anywhere else. The build will download source tarballs of various open source components, though.
TODO: Automate this via the CI system. I want to get the .img files for testing of each change, eventually.
git clone ssh://$YOUR_LOGIN@cesnet.cz@gerrit.cesnet.cz:29418/CzechLight/br2-external czechlight pushd czechlight git submodule update --init --recursive popd mkdir build-clearfog cd build-clearfog ../czechlight/dev-setup-git.sh make czechlight_clearfog_defconfig make
A full rebuild takes between 30 and 45 minutes on a T460s laptop for targets which use a pre-generated Linaro toolchain (clearfog, beaglebone). Other targets take longer because one has to build a toolchain first. When the build finishes, the generated image to be dd-ed to an SD card is at images/sdcard.img.
WARNING: Buildroot is fragile. It is not safe to perform incremental builds after changing an "important" setting. Please check their manual for details. Using ccache might help, but a significant time is wasted in configure steps which are not parallelized :( as of October 2017. This can be hacked by patching Buildroot's top-level Makefile, but note that one cannot easily debug stuff afterwards:
diff --git a/Makefile b/Makefile index 79db7fe..905099a 100644 --- a/Makefile +++ b/Makefile @@ -114,7 +114,7 @@ endif # this top-level Makefile in parallel comment the ".NOTPARALLEL" line and # use the -j<jobs> option when building, e.g: # make -j$((`getconf _NPROCESSORS_ONLN`+1)) -.NOTPARALLEL: # absolute path TOPDIR := $(CURDIR)
Apart from the traditional way of re-flashing the SD card or the eMMC from scratch, it's also possible to use RAUC to update. This method preserves the U-Boot version and the U-Boot's environment. Apart from that, everything starting with the kernel and the DTB file and including the root FS is updated.
FIXME: the system uses separate config partitions (/cfg), so these persistent bits are not preserved yet (see these user stories).
To install an update:
# build node make rsync -avP images/update.raucb somewhere.example.org:path/to/web/root # target, perhaps via an USB console wget http://somewhere.example.org/update.raucb -O /tmp/update.raucb rauc install /tmp/update.raucb reboot