Re: Running an ostree deployment in a container

[Dan Nicholson <nicholson endlessm com>]

On Fri, Apr 27, 2018 at 6:52 AM, Arnaud Rebillout
<arnaud rebillout collabora com> wrote:
> On 04/27/2018 06:43 PM, Dan Nicholson wrote:
> > On Wed, Apr 25, 2018 at 5:22 AM, Arnaud Rebillout
> > <arnaud rebillout collabora com> wrote:
> > > Dear OSTree maintainers,
> > >
> > > I'm attempting to build a basic Debian Stretch OS with OSTree. I'm using
> > > the scripts from
> > > https://github.com/dbnicholson/deb-ostree-builder/tree/simple-builder.
> > >
> > > In a nutshell:
> > > - the script 'deb-ostree-builder' create the base image with multistrap,
> > > then create the ostree repo with 'ostree commit'.
> > > - the script 'create-deployment' is in charge of creating a deployment
> > > in a local directory with 'ostree pull-local' and 'ostree admin deploy'.
> > Did this actually work? Did you have to make any changes? I've
> > literally never tried to run the results :)
>
> Almost out of the box yes, I think I had almost nothing to change. Good job!

That's great. Almost the entire reason I did that was to try to solve
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824649 so that we
can stop maintaining our forked ostree packaging and follow debian
more directly. If that tool is working for you, that's a good sign. Do
you mind if I pull you into
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824649?

> But notice that I boot that in a container, avoiding the bootloader
> question. Life is easier without a bootloader :)

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.

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"):

# There's no current symlink anymore, so query the deployment status.
# This will be the second parameter on the first line.
OSTREE_CURRENT_DEPLOYMENT=$(ostree admin
--sysroot="${EIB_OSTREE_CHECKOUT}" status | awk '{print $2; exit}')
OSTREE_DEPLOYMENT="${EIB_OSTREE_CHECKOUT}"/ostree/deploy/${EIB_OSTREE_OS}/deploy/${OSTREE_CURRENT_DEPLOYMENT}
OSTREE_VAR="${EIB_OSTREE_CHECKOUT}"/ostree/deploy/${EIB_OSTREE_OS}/var

# Mount kernel filesystems into deployment for image hooks
mount --bind /sys "${OSTREE_DEPLOYMENT}"/sys
mount --bind /proc "${OSTREE_DEPLOYMENT}"/proc
mount --bind /dev "${OSTREE_DEPLOYMENT}"/dev
mount --bind /dev/pts "${OSTREE_DEPLOYMENT}"/dev/pts

# Bind mount OS /var over deployment's /var for image hooks
mount --bind "${OSTREE_VAR}" "${OSTREE_DEPLOYMENT}"/var

# Bind mount the checkout over deployment's /sysroot, so the ostree repo
# is available for image hooks
mount --bind "${EIB_OSTREE_CHECKOUT}" "${OSTREE_DEPLOYMENT}"/sysroot

After that, I think you could point nspawn at $OSTREE_DEPLOYMENT. In
fact, nspawn probably manages the kernel filesystems and you just need
the /var and /sysroot mounts.