3

I'm working on a hardware product that contains an embedded Linux system. The majority of what we execute on that system is a set of Python code which currently has its own Git repository and is version controlled like a normal standalone software project.

I'm stuck on how to manage and version control the OS configuration itself. In order to load the OS onto a newly built machine, we have a stored master image file of the entire filesystem (a single ~4GB file backed up onto a network drive). It does need to be in that format to install. This leaves me with no version control over a variety of important things such as:

  • Installed version of the Python software.
  • Debian version and kernel version.
  • Third party libraries and hardware drivers which have been installed.
  • Important system configuration files (Device Tree sources, rc.local, etc)

As I work on debugging my custom hardware, this is getting especially concerning because I'm poking and prodding at config files with no version control.

Is there a type of tool for managing an OS configuration like this or at least some best practices I can implement? I've tried looking at configuration management tools and everything I've found has been targeted at more of an IT sysadmin kind of application to manage fleets of in-use computers which doesn't fit the embedded hardware use case very well. I feel like I'm searching for the wrong thing.

Improve this question
2
  • 3
    You might want to look at Docker or Puppet, etc. Docker lets you version control the definition that generates the image. Puppet and Chef are designed for configuration management and auto-deployment. They also work well with versioning.
    – Berin Loritsch
    Commented Sep 14, 2017 at 18:53
  • try to use docker: docker is not for version control system, but can add vcs. techrepublic.com/article/…
    – sailfish009
    Commented Sep 15, 2017 at 0:57

2 Answers 2

Reset to default
2

Ok, you wrote you have a stored master image file of the entire filesystem on a network drive which is too large to be put into version control. I assume that master image is seldom changed, if ever.

I guess what you can do here is to make a script in your programming language of your choice

  • which loads the binary file from the network drive

  • does the installation

  • and applies a list of changes to configuration files, if needed (for example, the script may just copy a newer version of the config files to the embedded system, installs newer component versions if needed, and so on)

And you can put that script, together with the newer versions of the config files under version control, I guess? That should actually be all you need. It makes the the embedded environment reproducible, without the need of bloating your Git repo with large binary files.

The general strategy here should be, instead of versioning the whole binary, version the steps and commands to bring the image into the required state. In our team, we do this regularly with larger amounts of test data, which is frozen on a network drive, but needed in context of our local working copies of some programs. You case maybe a little bit different, but I think that strategy could work for your case, too.

Improve this answer
1
  • 1
    Adding a hash-based verification of the file to the script (as well as some other meta-data about the file) allows you to detect changes to the file so notice a failure of reproducibility when the file that "should never change" changes.
    – Derek Elkins left SE
    Commented Sep 15, 2017 at 21:30
0

I would recommend taking a look at Vagrant & family in the Hashicorp Suite which use a versionable text file as a recipe to specify the base image and all of the installed components + build steps.

The Vagrant Family

  • Vagrant: It also allows you to construct test VMs for your development & testing. Free, Open Source, Cross Platform, VCS friendly, Ruby based
  • Packer: Automates the creation of any type of machine image. Free, Open Source, Cross Platform, VCS friendly JSON configuration For embedded targets use a Custom Builder.
  • Terraform, Vault, Consul & Nomad are much more specific to distributed & cloud environments. Both open source & enterprise editions
Improve this answer
2
  • Reading up on Vagrant, this seems to be meant specifically for VM management. I've got an existing OS image that has to run on the physical hardware, can I even use that at all? Their docs are talking about configuring for VirtualBox (default) vs VMWare vs AWS etc which leads me to believe that this is one of the many sysadmin tools that don't fit the embedded hardware use case.
    – Joe Baker
    Commented Sep 14, 2017 at 19:58
  • The and family bit is what covers it I'll expand.
    – Steve Barnes
    Commented Sep 15, 2017 at 4:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.