Re: Running an ostree deployment in a container

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

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

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.
--sysroot="${EIB_OSTREE_CHECKOUT}" status | awk '{print $2; exit}')

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]