Testing with some other Ubuntu boxes also failed - I tried a few
variants of the (very new!) 20.04 release and they exhibited a range
of problems giving unreliable startup. I've switched to 18.04 (aka
-"ubuntu/bionic64") and so far that has worked flawlessly.
+"ubuntu/bionic64") and (so far!) that has worked flawlessly.
************************************
+
+Setup of the runtime VM
+-----------------------
+
+This is a little more involved, as we don't have easy-to-use tools
+like vagrant here. It's easy enough to write scripts to drive qemu
+virtual machines, but the images themselves need to be created or
+borrowed from elsewhere.
+
+I've simply created a Debian 10.3 (Buster) arm64 image for now, using
+qemu and kvm on an arm64 host. It's set up to boot via UEFI using
+qemu's pflash interface. Inside the machine I've made the following
+changes:
+
+ * Set up to EFI boot via the removable media path (in case EFI boot
+ variables get lost or corrupted)
+
+ * Added an fstab entry to mount the /vagrant filesystem from the host
+ using the plan9 fs. This does *not* always work automatically due
+ to startup timing. Made it "noauto" and added an extra @reboot cron
+ job for it
+
+ * Added a "vagrant" user
+
+ * Symlink that user's .ssh/authorized_keys to
+ /vagrant/runtime/vagrant-pub-key, to allow passwordless ssh login
+
+ * Added passwordless sudo access for the vagrant user
+
+ * Add a startup script to mount /vagrant and do other startup stuff,
+ then run any provisioning if needed
+
+ * Add an @reboot cron job to run that script
+ @reboot /usr/local/bin/runtime_vm_startup
+
+We'll also need a similar 32-bit Arm image to support 32-bit labs. The
+driver script "start_runtime" can easily support that, but the image
+does not (yet!) exist.
+
+It's also possible to use a different image here, but we'll need to
+find and test with them.