- Copy necessary functions from zfsbootmenu/lib/zfsbootmenu-kcl.sh to
avoid a dependency on this file at runtime
- Expand concept of "boot environment" to include "ZBM EFI executable"
- Allow streaming manipulations of EFI executables with "-" indicating
stdin as a source and stdout as a destination
- "Tiered" configuration simplifies management and allows more targeted
overrides, symlinking configs in `/etc/zfsbootmenu` in the container:
1. First tier comes from `etc/zfsbootmenu` (global defaults)
2. Second tier comes from `etc/zbm-builder` (container defaults)
3. Third tier comes from the build root (build specific)
Configurations in later tiers override those with conflicting names in
earlier tiers.
- Tiered configuration now includes mkinitcpio configuration, allowing
containers to build mkinitcpio images
- Container configuration for mkinitcpio supports dracut-style snippets
in `mkinitcpio.conf.d`
- The builder now looks for an `rc.d` subdirectory in the build root and
will invoke every executable file therein before generating images to
provide a means to "terraform" the build container
- The `zbm-builder.sh` wrapper now supports a configuration file to
allow defaults to be specified; this requires a two-pass getopts to
find and load the configuration file before parsing remaining options
- A new option to `zbm-builder.sh`, `-R`, will remove any existing host
files (`hostid` and `zpool.cache`) from the build root to make sure
they are always up to date with the host versions
- The container entrypoint now configures `generate-zbm` to write its
output directly to the desired output directory rather than staging in
a temporary output directory, allowing `generate-zbm` to manage
version rollovers as it does in host installations
- Remove superfluous arguments from container entrypoint to manage
`hostid`, `zpool.cache` and `config.yaml`; the files either exist in
the build root or the container will use defaults
- Drop `docker-compose.yml` and now-obsolete `config.yaml.default`
- Update documentation to better reflect current build procedure
In cases where the `zfs` package has been updated since the container
image was built, this would trigger an upgrade of `zfs`; however, the
container does not include Linux headers by default, so the rebuild will
fail. Instead, skip the package upgrade. In the worst case, adding new
packages fails and the container image must be rebuilt.
- Allow container images to include custom Void packages via
image-build.sh
- Allow container instances to include custom Void packages via
zbm-build.sh
- Allow specification of custom Void packages and volume mounts via
user-facing zbm-builder.sh
If the xbps package is actually updated with
xbps-install -Syu xbps
it seems that it invalidates locally cached repos. Forcing a resync when
updating the rest of the packages should be sufficient to avoid this
problem.
zbm-build.sh now tells the difference between old (pre-2.0) and new
repository layouts and will correctly set up its container to build in
either environment. The default buildroot has been moved to /build so it
is much easier to launch a build container with a single bind-mount that
contains a configuration as well as optional hostid and zpool.cache and
will hold a build/ subdirectory with build products afterwards.
All core ZFSBootMenu libraries / hooks / binaries have been moved to a
generic 'zfsbootmenu' directory intended to be installed in /usr/share.
The dracut-specific module-setup.sh script has been moved to a 'dracut'
directory and it, along with the 'initcpio' hook scripts, have been
adapted to use common tooling in 'zfsbootmenu/install-helpers.sh'. Both
of these refer to the core components in '/usr/share/zfsbootmenu' when
creating a new image. The zbm-kcl utilit looks there by default.
The testing tools are now capable of producing images with mkinitcpio.
Co-authored-by: Zach Dykstra <dykstra.zachary@gmail.com>
Co-authored-by: Andrew J. Hesford <ajh@sideband.org>
Both pod2man and pod2text default to 'die' on any POD formatting errors.
We can leverage that by enabling `set -e` in pod2man.sh and pod2help.sh.
tag-release.sh will now also trap any errors from either script and exit
accordingly.
Using buildah directly provides flexibility that can not be achieved
with a Dockerfile. It also prevents the layer problem that bloats image
sizes, avoiding the need to squash the image.
Closes#230.
To allow for a complete picture of what's happening when the component
and EFI assets are built under GitHub Actions, it's necessary to pass
'--debug' to generate-zbm. zbm-build.sh now supports passing arbitrary
arguments to generate-zbm by adding them after -- to the zbm-build.sh
commandline.
The more general approach to containerized image builds makes it easier
to move configuration logic out of make-binary.sh to static configs and
volume mounts.
Accept command-line arguments and environment variables to specify:
- BUILDROOT: the default source of config, hostid and zpool.cache files
- ZBMCONF: a specific configuration file to use inside the container
- ZBMOUTPUT: a directory where build artifacts will be copied
- HOSTID: a specific hostid file to be copied to /etc/hostid
- POOLCACHE: a specific cache to be copied to /etc/zfs/zpool.cache
- ZBMTAG: a tag to fetch if /zbm is not pre-populated in container
The zbm-build.sh script now overrides ImageDir values and removes
Global.BootMountPoint from any configuration, writing artifacts to a
temporary directory and copying them to the output directory after a
successful run.
When /zbm is not pre-populated, it is now built in-container from a
tarball fetched from github.com rather than a git clone. This reduces
instantiation time and lightens the dependency burden.
Closes: #195.
Using podman to containerize the production of release assets avoids
potential leakage of personal information. To support this, the
containerized build script has been modified to separate the repo path
at /zbm from a "build" directory (previously /zbm/contrib/docker was
hard coded, now it's just the default choice). The releng script creates
a temporary directory to serve as the "build" path, populates configs,
and runs the build container with the current repo at /zbm and the
temporary directory at /build. The outputs are copied as before, with
the EFI executable standing alone and the kernel/initramfs components
stored in a gzipped tarball.
If the releng script does not find the expected builder image
(zbm-builder by default, but this can be passed as a second argument to
the script), it will invoke `podman build` to create the image.
* Prepare for v1.10.0
* Only load spl.ko if it's not already loaded
Arch loads spl.ko early, and insmod returns a 1 if the module is already
present. Check is ^spl is present via lsmod, if it's not present find
the path to the module on disk and load it via insmod.
* Split the return before the subkey handler
* Remove zbm.import_retries documentation
* zfsbootmenu.7: clean up zbm.import_delay, describe hard requirements with zbm.prefer
* zfsbootmenu.7: improve rootprefix discussion
* zfsbootmenu.7: clarify behavior of spl.spl_hostid
* Shorten embedded kcl now that new defaults are in
* Fix releng/make-binary.sh
* Detect if we can't remove the system 90zfsbootmeu directory and error
out. The copy from our current git clone needs to be used.
* cd to our custom dracut directory so that the --local option to dracut
picks up our custom dracut modules directory.
* Exit if for some reason generate-zbm fails.
Co-Authored-By: Andrew J. Hesford <ajh@sideband.org>
Co-Authored-By: Zach Dykstra <dykstra.zachary@gmail.com>
Instead of embedding documentation in zfsbootmenu-help.sh, it will now find and display files on disk. This lets us embed zfsbootmenu.7.pod in the initramfs so that the full system integration documentation is available at runtime.
The downside to this is that there's no reasonable way to fold/wrap these lines. releng/pod2help.sh now pre-computes three different sizes of documentation - suitable for 80, 120 and 160 column displays. Extremely narrow displays will fall back to the documentation formatted for 80 character displays. It won't look great, but it'll be there.
The file display name in the help menu is extracted from the zfsbootmenu - <description> line in each file. The first few lines are then stripped to normalize the display of man pages and help pages.
Andrew J. Hesford