I always like to ask this question with respect to BEs: what are the facts that make life easier when administering Oracle Solaris 11?
Maybe the answers aren't so difficult; to prove this, let's imagine a scenario. We are requested to update Oracle Solaris 11, and to do this, we need to reboot the system, insert the Oracle Solaris 11 installation DVD, and during the boot, we have to choose the upgrade option. Is the upgrade complete? Is there no further problem? Unfortunately, this is not true because there are some potential tradeoffs:
We had to stop applications and reboot the operating system, and users had to stop work on their tasks
If there was trouble upgrading the Oracle Solaris operating system, we'll lose all old installation because the upgrade process will have overwritten the previous version of Oracle Solaris; consequently, we won't be able to reboot the system and go back to the previous version
As you will have realized, this is a big threat to administrators because in the first case, we had a working (but outdated) system, and in the second case, we risked losing everything (and our valuable job) if anything went wrong. How can we improve this situation?
In Oracle Solaris 11, when we are requested to upgrade a system, Oracle Solaris 11 takes a BE automatically to help us during the process. The boot environment is a kind of clone that makes it possible to save the previous installation, and if anything goes wrong during the upgrade, the boot environment of Oracle Solaris 11 lets us roll back the OS to the old state (installation). One of the biggest advantages of this procedure is that the administrator isn't obliged to execute any command to create a BE to protect and save the previous installation. Oracle Solaris 11 manages the whole process. This has two advantages: the upgrade process gets finished without rebooting the operating system, and the boot environment enables us to roll back the environment if we encounter a problem.
You should know that BEs aren't only used for upgrade operations. Indeed, we can deploy them to patch the system, install an application, or create a test environment. In all of these cases, the BE makes it possible to revert the system to the previous state. So, after we have taken care of these fundamentals, it's time to practice.
Nowadays, professionals are making heavy use of the BE, and this is the true reason that creating, activating, and destroying BEs is most important when administering Oracle Solaris 11. You can be sure that this knowledge will be fundamental to your understanding of Oracle Solaris 11 Advanced Administration.
To follow this recipe, it's necessary that we have a machine (physical or virtual) running Oracle Solaris 11; we log in to the system as the root user and open a terminal. Additionally, our system must have access to the Internet. Some extra free space might be required.
Without any delay, we execute the following commands:
root@solaris11:~# beadm create solaris-backup-1 root@solaris11:~# beadm list BE Active Mountpoint Space Policy Created ------------- --------------------------------- ---------- solaris NR / 4.99G static 2013-10-05 20:44 solaris-backup-1 - - 163.0K static 2013-10-10 19:57 solaris-backup-b - - 173.0K static 2013-10-12 22:47
Oracle Solaris 11 automatically creates an entry in the GRUB list and makes it the default choice. However, it is relevant to note that another BE named solaris-backup-b is already present on the system from previous tests and it will be used in some steps ahead.
To enable the solaris-backup-1 BE, execute the following commands:
root@solaris11:~# beadm activate solaris-backup-1 root@solaris11:~# beadm list BE Active Mountpoint Space Policy Created ----------------------- ------------------------------------ ---------- ------------------------ solaris N / 4.99G static 2013-10-05 20:44 solaris-backup-1 R - 163.0K static 2013-10-10 19:57 solaris-backup-b - - 173.0K static 2013-10-12 22:47
Note the Active column from the last command. The flag for solaris-backup-1 has changed to R, which means that it will be the active boot environment in the next boot. Therefore, it's time to reboot the system and list all the BEs:
root@solaris11:~# init 6 root@solaris11:~# beadm list BE Active Mountpoint Space Policy Created solaris - - 511.60M static 2013-10-05 20:44 solaris-backup-1 NR / 4.74G static 2013-10-10 19:57 solaris-backup-b - - 173.0K static 2013-10-12 22:47
If we need to destroy a boot environment (not the current one, for sure), we can do so by executing the following command:
root@solaris11:~# beadm destroy solaris-backup-b Are you sure you want to destroy solaris-backup-b? This action cannot be undone(y/[n]): y root@solaris11:~# beadm list BE Active Mountpoint Space Policy Created solaris - - 247.55M static 2013-10-05 20:44 solaris-backup-1 NR / 4.90G static 013-10-10 19:57
What can we say about GRUB? There is no problem with it because Oracle Solaris 11 automatically removed the BE entry from the existing GRUB configuration.
Creating a new BE is an excellent way to have an additional environment to initially test a new Oracle Solaris 11 patch or operating system upgrade from Oracle. If something goes wrong, we are able to switch back to the old environment without losing any data. Following the creation of the BE, we need to remember to activate the new BE before rebooting the system.