On Fri, 2018-04-27 at 09:45 -0500, Dan Nicholson wrote:
That is simpler :) We had some people at Endless that were using nspawn for testng, but now I see that they're also working on full bootable images. I think it will be difficult for nspawn to handle a straight deployment directory since it's not actually runnable in the normal sense. OSTree deployments kinda depend on an initramfs setting up the mounts correctly so it looks like a normal root directory.
I suspect I am one of the people at Endless being referred to here, and I’d like to clarify that I do still want to run OSTree images from nspawn for testing; but booting a VM makes more sense for other kinds of testing. In particular, using nspawn makes it a lot easier to programmatically interact with the image’s processes for unit testing. That was why I was working on it.
What you could _maybe_ do is point nspawn directly at sysroot/ostree/deploy/$os/deploy/*, but I think you'd be lacking some parts without doing some bind mounting yourself. I often chroot into our raw ostree's with a little bit of bind mounting. In fact, our image builder does roughly this to make our customization hooks look like they're running on a booted system. Here's roughly what it does after doing the stuff that's in that deploy script (EIB_OSTREE_CHECKOUT is the "root" directory and EIB_OSTREE_OS is just the OS name we us, "eos"):
You can use nspawn’s --pivot-root argument to simulate the OSTree pivot root done during a normal boot: sudo systemd-nspawn -i ~/image.raw \ --bind +/sysroot/ostree/deploy/$os/var:/var \ --pivot-sysroot /ostree/deploy/$os/deploy/$checksum.0 See my earlier e-mail on it here: https://mail.gnome.org/archives/ostree-list/2017-February/msg00007.html I haven’t touched any of this nspawn stuff for a while though, so I might be a little out of date now. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part