Alex Ellis

With regards to image update management, personally what I wish to do for my Yocto image is to have it be:

- Small enough that it fits into RAM.

- Fetched over the network on boot, PXE-style.

- Configured to not write any files to the greatest extent possible, and where writing files can not be avoided one would use tmpfs.

With the above three criteria satisfied, the following is achieved:

a) We never write to an SD card so we avoid SD card corruption issues.

b) Since the whole system image is sitting in RAM, we could do without NFS, Samba or similar either.

We do need to persist some data, but that data is coming from our application and is going to be stored in a database on a server on the local network.

I am currently working on developing the application that our image will run, but I have dug up some preliminary information relating to what I said above:

- Read-only Raspberry Pi [1]. Applies to Raspbian but certainly provides a starting point for doing the same thing with Yocto.

- Poky NFS Root [2]. Like I said, I don't need the NFS root part if the image can fit in RAM, but the portions that deal with gPXE might certainly be relevant.

- The State of Netbooting Raspberry Pis (December 2017) [3]. "Net-booting works well on the Raspberry Pi B Model 3 without an SD Card." So actually we won't be needing gPXE.

- Network Boot Your Raspberry Pi [4]. Referenced by [3] and provides the steps needed to configure Raspberry Pi 3 for network booting without an…

This bubbled up the other day which was interesting as well.

https://blog.alexellis.io/building-containers-without-docker/

It does seem like Docker will be holding back containers from achieving their true promise, as it flounders looking for profitability and chasing k8s. Its sad that we're still moving around tar balls without advancing some of the tooling around it.

One of my biggest gripes as a non-k8s container user are that we are still keeping all this versioned cruft with every container. I would like to see an easier way to just get the latest binaries not dozens of tar hashes with versions going back to the first iteration of the container. Probably closer to singularity https://singularity.lbl.gov/

Another area is the ability to update containers in place. Hass.io https://www.home-assistant.io/hassio/ does some of this with the ability to manage the container version from within the container, but seems like a little bit of a hack from what I've seen. Watchtower is closer to what I'd like https://github.com/containrrr/watchtower, but why can't we have a more integrated system built into the default tooling?

I have 2 questions which I hope can be answered

Firstly, can there be an easier way to stop a microVM mid execution in this single executable bottlefire format and then rerun that and it would start mid execution. (something akin to how criu does it?)

Secondly, and although this isn't related to your product but rather about microvm and that is if something like microvm could be run in normal cloud infrastructure?

I saw this article (https://blog.alexellis.io/how-to-run-firecracker-without-kvm-on-regular-cloud-vms/) and It mentioned PVM and I was thinking if this can be applied here because then I feel like if I can run a container as a microvm on big cloud and then stop it mid execution and rerun it elsewhere, then I have essentially got an incentive to use spot instances which are (I think) 80% more cheaper and I am just curious about it from a devops side of things.

The Snapdragon 3xc Gen 3 one needed a downstream kernel and community effort: https://github.com/merckhung/linux_on_arm64_laptop#microsoft-dev-kit-2023

(initially there was some bring-up trickery that led to Linux not booting past Grub, but OpenBSD working fine: https://blog.alexellis.io/linux-on-microsoft-dev-kit-2023/ )

Re: Microsoft, Secure Boot should be disable-able and the devices are ServerReady. As close to an open platform as it gets in ARM land. Other than that, we're on our own, unless Qualcomm will help with their mainlining efforts. That'll be almost enough for the DevKit, but the upcoming Snapdragon X laptops have lots of additional stuff besides the SoC itself.

The recently released OpenBSD 7.2 boots and installs on it, support for the same Qualcomm Snapdragon SoC used in the ThinkPad x13s was added during last release cycle, so support for the Microsoft Dev Kit 2023 came for the most part for free.

https://www.openbsd.org/72.html

OpenBSD developer Patrick Wildt shared boot messages (dmesg) here: https://twitter.com/bluerise/status/1585584481854816256

Another UK tech reviewer Alex Ellis showed it booting OpenBSD into X11: https://blog.alexellis.io/linux-on-microsoft-dev-kit-2023/