OpenSolaris

You are not signed in. Sign in or register.

ZFS Boot Project FAQ

Last updated October 31, 2008

ZFS Boot and Installation Release Questions
ZFS Boot Questions
ZFS Installation and Upgrade Questions
ZFS Swap and Dump Questions

ZFS Boot and Install Release Questions

  1. What is the status of ZFS boot and install features?
  2. When will full ZFS and boot and installation features be available?
  3. What are the ZFS boot and install known issues?
  4. Can I use the Nevada build 62 ZFS boot/root support with the new ZFS boot and install features?
  5. Can I upgrade from the OpenSolaris 2008.05 to the SXCE, build 90 release?
  6. What else should I know about using ZFS installation and boot features?

  1. 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

  2. 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 in the Solaris 10 release 10 10/08 release. Before you install or migrate to a ZFS root file system, review the following information:

  3. 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.

  4. 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.

  5. 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.

  6. What else should I know about using ZFS installation and boot features?
  7. 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


  1. What ZFS boot features are included?
  2. How should I create my ZFS storage pool? Can I boot from a mirrored ZFS root configuration?
  3. How do I boot from an alternate mirror in a mirrored ZFS configuration?
  4. Will I still be able to boot from a UFS file system?
  1. 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.
  2. 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.

  3. How do I boot from an alternate mirror in a mirrored ZFS configuration?
  4. 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
    
    On a SPARC system, enter the boot command with the alternate disk boot path.
    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
  5. 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 Install and Upgrade Questions


Installation Questions

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

  1. What ZFS install features are included?
  2. What install features are not included?
  3. What are the memory and disk space requirements for a ZFS root installation?
  4. Can I create a ZFS root pool as a RAID-Z configuration?
  5. How does the initial installation provide ZFS root pool support?
  6. What Jumpstart features are provided?
  1. 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.
  2. 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.
  3. 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. In addition, the swap and dump devices are sized at 1/2 the size of physical memory, but no more than 2 Gbytes and no less than 512 Mbytes (starting at build 96).

    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 32 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.

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

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

  5. 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  -
      
  6. What 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

  1. What Live Upgrade features are included? What Live Upgrade limitations exist?
  2. What does Live Upgrade do to migrate my UFS root file system to a ZFS root file system?
  3. What happens to my legacy UFS components?
  4. How do I use Live Upgrade to convert my UFS root file system to a ZFS root file system?
  5. Can I use Live Upgrade to upgrade my zones?
  1. 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.
  2. 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.
  3. What happens to my legacy UFS components?

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

  4. 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. For example:
        # luactivate zfsBE
  5. Can I use Live Upgrade to upgrade my zones?

    TBD

ZFS Swap and Dump Questions


  1. What ZFS swap and dump features are included?
  2. How do I make changes to my swap and dump devices?
  1. 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 area size is based on 1/2 the size of physical memory, but no more than 2 Gbytes and no less than 512 Mbytes (starting at build 96). 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 based on 1/2 the size of physical memory, but no more than 2 Gbytes and no less than 512 Mbytes (starting at build 96). 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.
  2. How do I make changes to my swap and dump devices?

    If you need to change your swap area or dump device after the system is installed or upgraded, use the swap and dumpadm commands as in previous Solaris releases.

    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.