Dependence on guestfish

[larstobi]

Thanks for open sourcing this! I still haven't been able to make it work for me, but I'm working on it.

I cannot find a way of installing prebuilt guestfish on CoreOS and neither on my Mac.

Is it possible to install it on the CoreOS machine, or must I install Linux in a VM on my Mac to build zfs?

Is there another tool that can do the same job that is installable on CoreOS or Mac?

[lorenz]

Guestfish is necessary since CoreOS only publishes its developer containers as full images. You won't be able to read these under macOS since they use the ext4 filesystem. This project is set up to only depend on CoreOS files for trust reasons. I don't think you can build this on non-RHEL/Debian while not trusting any of my build artifacts. I can give you prebuilt torcx artifacts if you want. There is an open issue at #3 for discussing this.

[larstobi]

Actually, I found out I can run it from the CoreOS machine, as described here: https://coreos.com/os/docs/latest/kernel-modules.html#prepare-a-coreos-container-linux-development-container

core@localhost ~ $ sudo systemd-nspawn --bind=/lib/modules --image=coreos_developer_container.bin
Spawning container coreos_developer_container.bin on /home/core/coreos_developer_container.bin.
Press ^] three times within 1s to kill container.
Update Strategy: No Reboots
System has not been booted with systemd as init system (PID 1). Can't operate.
coreos_developer_container ~ # wget https://github.com/lorenz/torcx-zfs/archive/master.zip
coreos_developer_container ~ # unzip master.zip
coreos_developer_container ~ # rm master.zip
coreos_developer_container ~ # cd torcx-zfs-master/
coreos_developer_container torcx-zfs-master # ZOL_VERSION=0.7.12 ./build.sh

BUILDDIR=$(pwd)
pwd
mkdir root
mkdir udev

emerge-gitclone
>>> Cloning repository 'portage-stable' from 'https://github.com/coreos/portage-stable.git'...
>>> Starting git clone in /var/lib/portage/portage-stable
Cloning into '/var/lib/portage/portage-stable'...
remote: Enumerating objects: 87, done.

[...]

Making install in module
make[1]: Entering directory '/root/torcx-zfs-master/spl-spl-0.7.12/module'
make -C /usr/lib64/modules/4.14.88-coreos/build SUBDIRS=`pwd` modules_install \
    INSTALL_MOD_PATH= \
    INSTALL_MOD_DIR=extra \
    KERNELRELEASE=4.14.88-coreos
make[2]: Entering directory '/usr/lib64/modules/4.14.88-coreos/build'
mkdir: cannot create directory '/lib/modules/4.14.88-coreos/extra': Read-only file system
/usr/lib64/modules/4.14.88-coreos/source/Makefile:1545: recipe for target '_emodinst_' failed
make[4]: *** [_emodinst_] Error 1
Makefile:146: recipe for target 'sub-make' failed
make[3]: *** [sub-make] Error 2
Makefile:24: recipe for target '__sub-make' failed
make[2]: *** [__sub-make] Error 2
make[2]: Leaving directory '/usr/lib64/modules/4.14.88-coreos/build'
Makefile:22: recipe for target 'modules_install' failed
make[1]: *** [modules_install] Error 2
make[1]: Leaving directory '/root/torcx-zfs-master/spl-spl-0.7.12/module'
Makefile:611: recipe for target 'install-recursive' failed
make: *** [install-recursive] Error 1

However, it still fails to build.

[larstobi]

I was able to build the torcx with some modifications to the script. See pull #5 Don't know if this is working on Ubuntu, however, although I don't see any reason it shouldn't.

[lorenz]

Yeah, systemd-nspawn works but is not as easily automatable and requires more permissions than I grant my CI. But for manual builds it's perfectly ok. I've commented on #5 regarding the inclusion of that build method.

[coreyjewett]

I've been using @lorenz scripting to install ZoL on my home coreos box for a while now. Due to my primary desktop machine being an aged MacBook, guestfish was a barrier to me as well. Instead, I use @BugRoger's coreos-developer using the script below.

#!/bin/bash
set -euxo pipefail

if [ -z "$ZOL_VERSION" ]; then
  # Check for updates here: https://zfsonlinux.org/
#  ZOL_VERSION=0.7.11
  ZOL_VERSION=0.8.0
fi

# This is the CoreOS version
if [ -z "$VERSION" ]; then
  $(egrep '^VERSION' /etc/os-release)
fi

export ZOL_VERSION VERSION

# get code
CODE_DIR=torcx-zfs.${VERSION}-${ZOL_VERSION}

docker run -ti --rm -v ${HOME}:/root -v $(pwd):/git alpine/git clone https://github.com/lorenz/torcx-zfs.git ${CODE_DIR}
docker run -it --rm -v ${PWD}/${CODE_DIR}:/root/torcx-zfs -w /root/torcx-zfs -e ZOL_VERSION bugroger/coreos-developer:$VERSION ./build.sh

# install
sudo mkdir -p /var/lib/torcx/store/${VERSION}/
sudo cp ${CODE_DIR}/zfs:${ZOL_VERSION}.torcx.tgz /var/lib/torcx/store/${VERSION}/

# setup to run
sudo tee /etc/torcx/profiles/zol_manifest.json <<MANIFEST
{
  "kind": "profile-manifest-v0",
  "value": {
    "images": [
      {
        "name": "zfs",
        "reference": "${ZOL_VERSION}"
      }
    ]
  }
}
MANIFEST

if ! grep zol_manifest /etc/torcx/next-profile; then
  echo "zol_manifest" | sudo tee -a /etc/torcx/next-profile
fi

# add zfs tools to path (note: not quite right for root.)
test -e /etc/profile.d/torcx-path.sh || (echo 'export PATH="/var/run/torcx/bin:${PATH}"' | sudo tee /etc/profile.d/torcx-path.sh)

Eventually I should get around to triggering the script automatically when CoreOS updates, but I just haven't. (demoralized by the eventual demise of CoreOS). If I happen to forget to update (or a power outage occurs) I end up needing to disable the outdated driver, reboot, run the scripting, re-enable zol_manifest, and reboot again. Kind of a pain, but only happens occasionally.

I just ran it for coreos-2135.5.0 and ZoL-0.8.0. Some previous successful builds were zfs-0.7.{9..11} on coreos-1745, 1800, 1911, & 1967.

[lorenz]

I'm toying with the idea of just opening my torcx bucket (on an S3-compatible internal storage) to the public, I have autotrigger & autobuild on my CI anyways.