3 ms·

Does anyone have experience using either BUildroot or Yocto to build a virtual appliance? That is, a VM image that runs on a typical x64-based hypervisor. I'd b

Does anyone have experience using either BUildroot or Yocto to build a virtual appliance? That is, a VM image that runs on a typical x64-based hypervisor. I'd be particularly interested in experience building an immutable image with an A/B setup for updates, in the style of Chromium OS or the old CoreOS (now Flatcar Linux).

pmorici 6y ago
Yes, Buildroot comes with a bunch of configs you can use to build images that run on x86_64 and qemu. 'make list-defconfigs' will list everything that is available The A/B update thing typically works by having two disk partitions and then using your boot loader to switch between them and only updating one or the other. You can probably write a u-boot script to track failed boots and switch between images or something like that though I've never ventured down that road.
mitchs 6y ago
I was able to load up yocto's standard VMDKs into HyperV on my windows desktop, but AWS's import tool barfed on it. I build an embedded linux and wanted to use AWS as a hypervisor for larger scaled testing. (It was fairly easy to setup a custom machine config in yocto. (Require tune-core2.inc and you're off to the races.) I use the variable overrides system to tweak build build arguments on some packages to have them stub out hardware in the virtual images. I've found though that making your own image classes to be the most direct way of formatting your image if you need something exotic. The image classes system is kind of fun - you can keep stacking on more reusable classes that act as a kind of pipeline. To get it working on AWS I ended up doing what I needed to do by spawning a VM with an off the shelf AMI, attaching a second disk, dd-ing my image on, and then capturing that as an AMI. (I'm kind of annoyed that I couldn't find a proper API for this, but maybe I'm not looking in the right place. Their import tools all want to understand things about your image and mess with it, and I just wanted to send them a flat disk image.) This process was an annoying enough slow down for testing that I ended up making an image that would boot up just enough to get networking up, then fetch the real image from S3 based on directions in user-data, over-write itself, and reboot. If going with newer AWS instance types, don't forget to include their kernel modules, and have fun debugging when it doesn't boot :)
adfjklsfdgs 6y ago
buildroot has defconfigs for building uefi or bios images capable of booting on most any hypervisor. you can easily extend them. you can also easily strip them down and get itty bitty tarballs suitable for import as a docker container images https://github.com/br-containers/br-containers https://github.com/br-containers/br-containers

pmorici 6y ago

Yes, Buildroot comes with a bunch of configs you can use to build images that run on x86_64 and qemu. 'make list-defconfigs' will list everything that is available The A/B update thing typically works by having two disk partitions and then using your boot loader to switch between them and only updating one or the other. You can probably write a u-boot script to track failed boots and switch between images or something like that though I've never ventured down that road.

mitchs 6y ago

I was able to load up yocto's standard VMDKs into HyperV on my windows desktop, but AWS's import tool barfed on it. I build an embedded linux and wanted to use AWS as a hypervisor for larger scaled testing. (It was fairly easy to setup a custom machine config in yocto. (Require tune-core2.inc and you're off to the races.) I use the variable overrides system to tweak build build arguments on some packages to have them stub out hardware in the virtual images. I've found though that making your own image classes to be the most direct way of formatting your image if you need something exotic. The image classes system is kind of fun - you can keep stacking on more reusable classes that act as a kind of pipeline. To get it working on AWS I ended up doing what I needed to do by spawning a VM with an off the shelf AMI, attaching a second disk, dd-ing my image on, and then capturing that as an AMI. (I'm kind of annoyed that I couldn't find a proper API for this, but maybe I'm not looking in the right place. Their import tools all want to understand things about your image and mess with it, and I just wanted to send them a flat disk image.) This process was an annoying enough slow down for testing that I ended up making an image that would boot up just enough to get networking up, then fetch the real image from S3 based on directions in user-data, over-write itself, and reboot. If going with newer AWS instance types, don't forget to include their kernel modules, and have fun debugging when it doesn't boot :)

adfjklsfdgs 6y ago

buildroot has defconfigs for building uefi or bios images capable of booting on most any hypervisor. you can easily extend them. you can also easily strip them down and get itty bitty tarballs suitable for import as a docker container images https://github.com/br-containers/br-containers https://github.com/br-containers/br-containers