ZFS Boot Environments
With PC-BSD 9.2 just around the corner, this is a good time to take an advanced look at some of the new functionality coming with it. While there are a number of new features in the works, today we will look specifically at the implementation of ZFS Boot Environments. In coming issues, we will also look at PC-BSD’s home directory encryption via PEFS and its PKGNG support. Let us get started by first looking at ZFS Boot Environments.
ZFS Boot Environments
While ZFS boot environments have been around in Solaris for a while, they are still relatively new to the FreeBSD ecosystem and many users may be unfamiliar with them. So what is a Boot environment (BE)? Simply put, it is a fancy way to leverage the power of ZFS snapshots to create instant system backups, which can be easily booted from in case of disaster. This is accomplished on PC-BSD and TrueOS by using a specific ZFS dataset layout, the beadm utility, and the GRUB boot-loader. In order to make Boot Environments contain the proper data for backup / restore, we have to start with a slightly different layout than a traditional ZFS layout.
The first change is that we are creating a special <tank>/ROOT/default dataset. This dataset is the primary source for taking and cloning ZFS snapshots, which means anything outside of this dataset will not be included in a Boot Environment. It will be mounted as ‘/’ on your system. However, for a Boot Environment to work, we will want to include /usr, /usr/local, and such within our snapshot, while still allowing child datasets such as /usr/home and /usr/jails to be created. To accomplish this, we create a /usr ZFS dataset and set the canmount=off flag. The same is done for the /var dataset, allowing us to include it in the snapshots, while creating /var/log, /var/tmp, and /var/audit to persist between Boot Environments.
These layout choices ensure that when we take a snapshot of the system, we end up with all the system files and packages necessary to boot back up to a working desktop or server environment. Including /usr/local makes Boot Environments a good choice for backups before performing package updates, because /usr/local updates are often just as critical to a user’s system as the kernel and world are. With the default layout ready for Boot Environments, we can now take a look at the beadm command to manage your backups. The beadm command, available in ports under sysutils/beadm, provides an easy-to-use framework to create, destroy, and otherwise manage your various Boot Environments. The subcommands we are most interested in will be list, create, and destroy. On a freshly installed system, you will start with a single Boot Environment named “default”.
The “NR” flags indicate that this BE is currently active Now, and will still be active on next Reboot. Creating a new BE will take a snapshot of the current BE at the current moment, so it would be wise to remember to do this before starting anything potentially dangerous. To add a new Boot Environment, simply run the beadm create <nickname> command.
As you can see, we have created a new BE nicknamed “newbe”. A quick re-run of the list command will show the newly created environment, along with the time and current size cost.
During the creation of the new BE, you probably saw the notice about generating the grub.cfg file. This brings us to the point of putting the “Boot” into Boot Environment. Similar to Solaris, PC-BSD and TrueOS 9.2 include the GRUB boot loader out of box and have it integrated into the beadm command in order to provide boot-time functionality. If we now reboot our system, we will be presented with a new Boot Environment menu.
.
As you can see, our newbe Boot Environment has been added to the menu, along with the creation date. By default, a timer exists which will boot the first environment after 5 seconds. However, if you press any key and interrupt this timer, you can arrow up and down to select the environment you wish to boot. Once you have selected the BE you wish to boot, GRUB will load the kernel + modules from this BE and boot the system. In addition, the GRUB menu will be updated with your current BEs any time you perform a beadm create or beadm destroy command.
Since GRUB is performing the initial boot of the system, there are a few new commands and configuration options available to the end user. First among these is the ability to regenerate the /boot/grub/grub.cfg file manually. This file is re-created every time you change BEs, but there may be cases when you want to manually re-create it, such as after placing a new module or setting into /boot/loader.conf. To start the re-creation, we will use the grub-mkconfig command (Figure 7). After running this command, any changes in the original /boot/grub/grub.cfg will be lost and replaced with an updated configuration file using details about your current BEs. However, there may be cases where you want to adjust your boot menu with other options, such as a new OS as an additional boot option or changing the default BE to boot after the countdown. Let’s take a look at how to accomplish these tasks (Figure 8). The first directory of importance is /usr/local/etc/grub.d. Within this directory is a collection of files starting with a numerical prefix. These files are shellscripts, run by the grub-mkconfig command which echo out various parts of the resulting grub.cfg file. These scripts will normally be replaced when updating the GRUB package, however, it is possible to add your own scripts to this directory. These new scripts will then be executed along with the others and their output added to the end of the grub.cfg file created by the grub-mkconfig command. If you have a fairly static group of options, it is also possible to create a /boot/grub/custom.cfg file, which will be included at the tail end of the grub configuration. Setting the default GRUB Boot Environment or OS entry is also easy. To get started, we will need to edit the file /usr/local/etc/default/grub and add the GRUB_DEFAULT=saved line.
Anytime we adjust the grub defaults file, we will need to re-create the grub configuration file using the command grub-mkconfig -o /boot/grub/grub.cfg. After grubmkconfig finishes, we can then set the default boot menu option with the grub-set-default command. This command will take a numerical argument for the particular menu entry to boot, starting with 0. So the first entry will be 0, the second will be 1, and so on. Using the grep command, you can easily see which Boot Environments are available for booting. (NOTE: after setting a default Boot Environment with the grub-set-default command, if you remove a BE you may change the order of the environments and you should check your grub.cfg file to make sure you are still booting the desired BE).
In this article, we’ve taken a look at how PC-BSD and TrueOS use ZFS, beadm and GRUB to manage backups and set the booting of different Boot Environments. In the coming months, we expect to add new GUI utilities to assist desktop users with the management of these technologies, and users who want to stay current with these changes are encouraged to join us on the PC-BSD Testing & Development mailing lists (http://lists.pcbsd.org/mailman/listinfo).
About the Author
Kris Moore co-created EasyPBI with Jesse Smith in 2011 and took over full development of it for the PC-BSD project in 2012. He lives in Tennessee with his wife and two sons and is always looking for ways to make computers simpler, but no less powerful, for the average user. He is currently employed by iXsystems to work on the PC-BSD Project as both a developer and as the manager for the PC-BSD PBI repository. He can be reached at: kris@pcbsd.org.
This article was re-published with the permission of BSD Magazine. To Learn More about iXsystem’s commitment to open source check us out here: https://www.ixsystems.com/about-ix/
