ZFS Boot Project FAQ (Community Group zfs.zfsbootFAQ)

ZFS Boot Project FAQ

ZFS Boot and Installation Release Questions

What is the status of ZFS boot and install features?

The plans are to integrate the ZFS boot and installation features in a phased putback:

ZFS swap support (CR 6528296) integrated into Nevada, build 88
ZFS boot support (CR 6521468) integrated into Nevada, build 88
ZFS install support (CR 6521472) integrated into Nevada, build 90

When will full ZFS boot and installation features be available?

Because of the phased putback in both Nevada build 88 and 90, it is best to wait for the SXCE, build 90 release before using these features.
We recommend waiting for the full boot and install support rather than attempting to use any of these features individually.
ZFS boot and install support is available starting in the Solaris 10 release 10 10/08 release. Before you install or migrate to a ZFS root file system, review the following information:

What are the ZFS boot and install known issues?

Before you begin, check out the list of known issues at the ZFS boot project page.

Can I use the Nevada build 62 ZFS boot/root support with the new ZFS boot and installation features?

Systems that already have ZFS root file systems can be bfu'd to build 90, but bfu does not convert the legacy mounts (of /, /var, and so on) to ZFS mounts. Backwards bfu to releases that don't support ZFS boot is prohibited. We recommend that you reinstall your systems at some future time to achieve the standard ZFS boot configuration provided in this release, which uses ZFS mounts, not legacy mounts. However, the system continues to boot with legacy mounts, at least for now.

Can I upgrade from the OpenSolaris 2008.05 release to the SXCE, build 90 release?

No, you can't upgrade or bfu from the OpenSolaris 2008.05 release to the SXCE, build 90 release.

What else should I know about using ZFS installation and boot features?

You should know that the final installation phase of creating the dump device takes a long time and it might appear that the system is hung. Be patient.

ZFS Boot Questions

What ZFS boot features are included?

Both x86 and SPARC systems use the new style of booting with a boot archive, which is a file system image that contains the files required for booting.
While the system is booted for installation, a ramdisk is used for the root file system during the entire installation process, which eliminates the need to be booted from removable media.
If you do an initial install of the SXCE, build 90 release or Live Upgrade from the SXCE, build 90 release, you will be able to boot from a ZFS root file system on both SPARC and x86 systems.
Entries are added to the menu.lst file during the installation or Live Upgrade process to boot ZFS automatically. For example, on an x86 system:

title Solaris Express Community Edition szboot_0508 X86
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/szboot_0508
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
module$ /platform/i86pc/$ISADIR/boot_archive

For example, on a SPARC system:

title snv_90
bootfs rpool/ROOT/snv_90
title snv_90b
bootfs rpool/ROOT/snv_90b

On a system with both bootable ZFS and UFS root file systems, you will be able to boot from either one by using the luactivate command. Or, if the active BE is ZFS, the system is booted from ZFS. If the active BE is UFS, the system is booted from UFS. On SPARC systems, you can use the boot -L command to display a list of available ZFS BEs that have been activated and then boot a ZFS BE with the boot -Z command when when the boot device contains a ZFS storage pool with bootable ZFS datasets. On x86 systems, you can boot from the bootable environments that are listed in the GRUB menu.
During the install and Live Upgrade process, the ZFS root file system is automatically designated with the bootfs property.

How should I create my ZFS storage pool? Can I boot from a mirrored ZFS root configuration?

Due to an existing boot limitation, you must create your ZFS storage pool with disk slices rather than whole disks if you are going to boot from ZFS file systesm in this pool. For example:

# zpool create rpool mirror c1t0d0s0 c1t1d0s0

Yes, you can boot from a mirrored ZFS configuration. A mirrored ZFS configuration for the root pool is recommended.

How do I boot from an alternate mirror in a mirrored ZFS configuration?

If you created a mirrored ZFS root pool during an initial installation, you can boot from an alternate disk automatically. Identify an alternate disk in your mirrored ZFS root pool. For example, disk c1t1d0s0 in the output below.

# zpool status
  pool: rpool
 state: ONLINE
 scrub: none requested
config:
        NAME          STATE     READ WRITE CKSUM
        rpool         ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            c1t0d0s0  ONLINE       0     0     0
            c1t1d0s0  ONLINE       0     0     0

ok boot /pci@7c0/pci@0/pci@1/pci@0,2/LSILogic,sas@2/disk@1

If you used the zpool attach command to create a mirrored ZFS root pool after the installation, then you must run the installboot or installgrub command on the alternate disks before they are bootable. For example:

sparc# installboot -F zfs /usr/platform/`uname -i`/lib/fs/zfs/bootblk /dev/rdsk/c0t1d0s0

x86# installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0t1d0s0

Will I still be able to boot from a UFS file system?

If you do an initial install of the SXCE, build 90 release, you will not be able to boot from a previous UFS file system unless you saved your UFS config on an alternate disk.
If you use Live Upgrade to upgrade your UFS root file system to a ZFS root file system with Nevada, build 90 release, you will be able to boot from your previous UFS file system as a boot environment (BE) or from your ZFS root file system. You can choose to boot either one by using the luactivate command. Or, if the active BE is ZFS, the system is booted from ZFS. If the active BE is UFS, the system is booted from UFS. On SPARC systems, you can use the boot -L command to display a list of bootable datasets that have been activated when the boot device contains a ZFS storage pool with bootable ZFS datasets. Then, use the boot -Z command to boot from the selected ZFS dataset. On x86 systems, you can boot from the bootable environments that are listed in the GRUB menu.

ZFS Installation and Upgrade Questions

Installation Questions

Caution: As with any installation process, please be sure to back up any data that you want to keep.

What ZFS install features are included?

The ability to install and boot from a ZFS root file system by using the initial install feature or the Live Upgrade feature.
You must select the text mode install option to install a ZFS root file system.
- On SPARC based system, use the following syntax from the Solaris installation DVD:

ok boot cdrom - text

- On SPARC based system, use the following syntax when booting from the network:

ok boot net - text

- On an x86 based system, select the text-mode install option when presented.
The ability to create a ZFS storage pool and designate a bootable ZFS file system from a Jumpstart profile.
You can set up a mirrored ZFS root pool by selecting two disks during the installation. Or, you can attach disks after the installation to create a mirrored ZFS root pool.
Swap and dump devices are automatically created on ZFS volumes in the ZFS root pool.

What install features are not included?

You cannot use the standard upgrade program to upgrade your UFS root file system to a ZFS root file system. However, if you want to use Live Upgrade to migrate your UFS root file system to a ZFS root file system, you will first need to use the standard upgrade program to upgrade from a previous SXCE release to the SXCE, build 90 release. Then, you can use Live Upgrade to migrate to a ZFS root file system.
Although you can use Live Upgrade to upgrade your UFS root file system to a ZFS file system, you can't use Live Upgrade to upgrade non-root file systems.
The Flash install feature is not currently available to install ZFS file systems. However, work is in progress to provide ZFS/flash installation support in the Solaris 10 release. This work is being tracked by CR 6690473. More information will be available Fall 2009.
You cannot install OS services for a diskless client on a ZFS file system.

What are the memory and disk space requirements for a ZFS root installation?

The minimum amount of available pool space that is required for a bootable ZFS root file system is larger than for a bootable UFS root file system because swap and dump devices are not shared in a ZFS root environment. Separate swap and dump devices are created during the installation process.
The minimum amount of available pool space for a bootable ZFS root file system depends upon the amount of physical memory, the disk space available, and the number of BEs to be created. Approximately 1 Gbyte of memory and at least 16 Gbytes of disk space are recommended.
For information about how the disk space is consumed and how to reduce the size of swap and dump devices before or after the installation of a bootable ZFS root file system, see the ZFS Admin Guide.

Can I create a ZFS root pool as a RAID-Z configuration?

No, a ZFS root pool cannot currently be configured with RAID-Z.

How does the initial installation provide ZFS root pool support?

During an initial installation of build 90, you have a choice of selecting a UFS or ZFS file system for the Solaris install.
If you select ZFS, you can select the disk or disks to be used for your ZFS root pool. If you select two disks, a mirrored two-disk configuration is setup for your root pool. Either a two- or three-disk mirrored pool is optimal. If you have 8 disks and you select all 8 disks, those 8 disks are used for the root pool as one big mirror. This is not an optimal configuration.
A swap device and a dump device are automatically created on ZFS volumes in the root pool.
The ZFS root pool is a special kind of pool that requires no administration. The sample zfs list output below identifies the root pool components, such as the mpool/ROOT entries, which are not accessible by default.

# zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
mpool             6.81G  1.24G    19K  /mpool
mpool/ROOT        5.81G  1.24G    18K  /mpool/ROOT
mpool/ROOT/ZFSbe  5.81G  1.24G  5.81G  
mpool/dump         516M  1.24G   516M  -
mpool/swap         514M  1.67G  82.5M  -

What Solaris JumpStart features are provided?

A profile can be used to set up a ZFS root file system or a UFS root file system. The ability to boot and create UFS file systems is the same as previous Solaris releases.
A profile that contains the following keywords: pool, bootenv and the installbe and bename subcommands, creates a bootable ZFS storage pool. Some ufs-specific keywords are not allowed, such as those that specify the creation of UFS mount points.
You cannot use an existing ZFS storage pool for a JumpStart installation to create a bootable ZFS root file system.
ZFS-specific profile examples are as follows:

install_type initial_install
pool newpool auto auto auto mirror c0t0d0s0 c0t1d0s0
bootenv installbe bename sxce_xx

The above profile performs an initial install specified with install_type initial_install in a new pool, identified with pool newpool, whose size is automatically sized with the auto keyword to the size of the specified disks. The swap area and dump device are automatically sized with auto keyword based on 1/2 the size of physical memory, in a mirrored configuration of disks (with the mirror keyword and disks specified as c0t0d0 and c0t1d0). Boot environment characteristics are set with the bootenv keyword to install a new BE with the keyword installbe and a bename called sxce_xx is created.

install_type initial_install
pool newpool auto auto auto mirror c0t0d0s0 c0t1d0s0
bootenv installbe bename zfsroot dataset /var

The above profile is identical to the previous profile except that the /var file system is created as a separate dataset. At this time, you can only specify /var as a separate dataset.

install_type initial_install
cluster SUNWCall
pool newpool 80g 2g 2g mirror any any
bootenv installbe bename sxce_xx

The above profile performs an initial install with keyword install_type initial_install of the SUNWCall metacluster in a new pool called newpool, that is 80 Gbytes in size with a 2-Gbyte swap volume and a 2-Gbyte dump volume, in a mirrored configuration of any two available devices that are large enough to create a 80-Gbyte pool. If two such devices aren't available, the install fails. Boot environment characteristics are set with the bootenv keyword to install a new BE with the keyword installbe and a bename called sxce_xx is created.

Live Upgrade Questions

What Live Upgrade features are included? What Live Upgrade limitations exist?

Previous Live Upgrade features are available and if related to UFS components, work as in previous Solaris releases.
An lucreate option is provided to identify your ZFS root pool (-p).
In addition, when creating an alternatve BE that is a clone of the primary BE, you cannot use the '-f', '-x', '-y', '-Y', and '-z' options to include or exclude files from the primary BE. You can still use the inclusion and exclusion option set in the following cases:

UFS -> UFS
UFS -> ZFS
ZFS -> ZFS (different pool)

The standard upgrade option is not available to migrate to a ZFS root file system.
The flash archive feature is not available yet for ZFS support.
Due to current boot limitations, the ZFS root pool must be created with slices instead of whole disks. For example:

# zpool create rpool mirror c1t0d0s0 c1t1d0s0

Do not rename your ZFS BEs with the zfs rename command because the Live Upgrade feature is unaware of the name change and subsequent commands, such as ludelete, will fail. In fact, do not rename your ZFS pools or file systems if you have existing BEs that you want to continue to use.

What does Live Upgrade do to migrate my UFS root file system to a ZFS root file system?

Your existing UFS root file system remains as an alternate BE.
Existing swap areas remain as is and as entries in the /etc/vfstab file.
Existing dump device remains as is.

What happens to my legacy UFS components?

All the UFS components including swap and dump areas are preserved during the Live Upgrade process.

How do I use Live Upgrade to convert my UFS file systems to ZFS file systems?

The basic process includes the following steps:
*You must upgrade your system running a previous Nevada release to build 90. Or, you can use the initial installation to set up a UFS root file system. Then, you can use Live Upgrade to migrate to a ZFS root file system.
*You must create a ZFS storage pool for your ZFS root pool. Live Upgrade knows nothing about formatting or repartitioning disks.
*The Live Upgrade phase includes the following steps:
Run lucreate to copy the primary BE to create an alternate BE. For example, use syntax similar to the following to migrate a UFS BE to a ZFS root pool:

# zpool create mpool mirror c1t0d0s0 c1t1d0s0
# lucreate -c c1t2d0s0 -n zfsBE -p mpool

The default file systems are created in the specified pool and the non-shared file systems are then copied into the root pool.
If you create another BE in the same pool, the syntax to create an alternate BE is similar to the following:

# lucreate -n ZFS2be

Run luupgrade to upgrade the alternate BE (optional).
Run luactivate on the newly upgraded alternatve BE so that when the system is rebooted, it will be the new primary BE. In the Solaris 10 5/09 release, you must set the following environment variables before the luactivate operation or the luactivate operation will fail. For example:

# BOOT_MENU_FILE="menu.lst"
# export BOOT_MENU_FILE
# luactivate zfsBE

Can I use Live Upgrade to upgrade my zones in the Solaris 10 releases?

Yes, but supported zone configurations are limited. For more information, see the ZFS Admin Guide

ZFS Swap and Dump Questions

What ZFS swap and dump features are included?

During an initial installation or a live upgrade from a UFS root file system, a swap device is created on a ZFS volume in the ZFS root pool. For example:

zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
mpool             6.81G  1.24G    19K  /mpool
mpool/ROOT        5.81G  1.24G    18K  /mpool/ROOT
mpool/ROOT/ZFSbe  5.81G  1.24G  5.81G  
mpool/dump         516M  1.24G   516M  -
mpool/swap         514M  1.67G  82.5M  -

The swap volume size that is created during an initial installation is based on 1/2 the size of physical memory, but is generally in the 512 Mbyte to 2 Gbyte range. Swap volume size is adjustable during an initial install and after any installation. For example:

# swap -l
swapfile                  dev    swaplo   blocks     free
/dev/zvol/dsk/rpool/swap 253,3        16  8257520  8257520

During an initial installation or a live upgrade from a UFS root file system, a dump device is created on a ZFS volume in the ZFS root pool. The dump device size is calculated by the kernel based on dumpadm information and the size of physical memory. Dump device size is adjustable during an initial install and after any installation. The dump device requires no administration after it is setup. For example:

# dumpadm
      Dump content: kernel pages
       Dump device: /dev/zvol/dsk/rpool/dump (dedicated)
Savecore directory: /var/crash/t2000-bdr-02
  Savecore enabled: yes

Currently, the swap area and dump devices must reside on separate ZFS volumes.

How do I make changes to my swap and dump devices?

If you need to change the size of your swap volume or dump volume, see ZFS Swap and Dump Devices.
You can resize the swap and dump devices before, during, or after installation. Keep in mind that the process of resizing or changing a large dump device is slow.
If you need to change your swap device or dump device after the system is installed or upgraded, use the swap and dumpadm commands as in previous Solaris releases.

Can I mix a UFS root file system with a ZFS swap volume?

Do not create a ZFS swap volume to be used in a UFS root environment in the Solaris releases prior to the Solaris 10 10/08 release due to CR 6528296.
Running a mixed UFS root/ZFS swap environment in the Solaris 10 10/08 release or Solaris 10 5/09 release is not recommended because it is untested.

last modified by cindys on 2009/10/28 18:12

OpenSolaris

Top Menu