As long as sysadmins need to maintain, change and update operating systems there is always need to protect against problems that may occur during these operations. Various solutions were used starting from simple backup/restore procedures or copying the contents of system filesystems into spare disks to snapshots and clones recently. None of these solutions were transparent enough or bulletproof enough to provide complete and consistent protection again failures in the change or update process. One of such holy grails is ZFS Boot Environments solution. It protects entire system (and even additional data when needed) against almost any change or update process. As ZFS Boot Environments matured in Solaris/Illumos systems and then on FreeBSD UNIX other systems started to copy its principles to provide similar solutions such as snapper with BTRFS in SUSE or Boot Environment Manager for DragonFly BSD with their HAMMER filesystem. The presentation aims to walk through the history of these solutions with the focus on practical ZFS Boot Environments solutions and examples.
A Bare Metal Installer for ZFS on Root
This repository is intended to produce a bootable UEFI image that allows installing a full bare system with ZFS disks. Be aware that it is not intended for building dual-boot systems. While you are given the ability to choose which disks are used, the EFI boot system will wipe other OS entries. It uses an Ubuntu kernel and a minimal ramdisk builder to host the scripts used to perform the actual install.[…]
Kevin Bowling has an article that shows how to setup a UEFI system to work with FreeBSD — including ZFS on root — and another UEFI OS like Windows.
I’m not sure if this article is an improved version of or just a rebroadcast of:
Add EFI ZFS boot support: This builds on the modular EFI loader support added r294060 adding a module to provide ZFS boot support on EFI systems. It should be noted that EFI uses a fixed size memory block for all allocations performed by the loader so it may be necessary to tune this size. For example when building an image which uses mfs_root e.g. mfsbsd, adding the following to /etc/make.conf would be needed to prevent EFI from running out of memory when loading the mfs_root image.
Jashank Jeremy wrote an article on using FreeBSD, ZFS, GPT, and UEFI, on a 64-bit system.
Apparently, the trick to is to use GRUB’s kFreeBSD mode. Full information here:
Hmm, WordPress imbeds the entire source file listing of a Git.Github URL. So I’m splitting this URL, you’ll have to combine it yourself:
Also check out the reply from Felix Khrohn on Jashank’s Twitter post, with an URL to alternative method by Ganael Laplanche.
From the FreeBSD Quarterly Status Report, FreeBSD’s boot loaders have a patch to support ZFS booting:
ZFS Support for UEFI Boot/Loader: UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS filesystem. The patch currently works with buildworld, and successfully boots on a test machine with a ZFS partition. In addition, the ZFS-enabled loader.efi can be treated as a chainloader using ZFS-enabled GRUB. The work on boot1.efi also reorganizes the code somewhat, splitting out the filesystem-specific parts into a modular framework. Open tasks:
1) More testing is needed for the following use cases: ZFS with GRUB+loader.efi, ZFS with boot1+loader.efi, UFS with boot1+loader.efi (to test the modularization of boot1.efi)
2) Have boot1.efi check partition type GUIDs before probing for filesystems.
3) Get patch accepted upstream and committed.