Re: Running an ostree deployment in a container

[Arnaud Rebillout <arnaud rebillout collabora com>]

On 04/27/2018 09:45 PM, Dan Nicholson wrote:
> 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?

Yep actually I've seen this discussion thanks to your commit message on
deb-ostree-builder. I hope we'll be able to tackle the opened bugs in
Debian and improve things.

> > 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.

I agree that for ostree, spawning a container doesn't get you very far,
and quickly enough you need a VM to run the bootloader and init parts.
For me right now, and maybe for everyone getting started with OSTree,
the whole point of the container is just to have something that you can
run *easily*, without to much headache. It's a milestone on your way
toward mastering ostree :)

> 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.

Thanks!

 Arnaud