Why the Scare Quotes?

I say this is the "advanced" HAMMER2 installation process because it's not recommended. Like, at all. But I figured it'd be fun to take advantage of the fact that *BSD lets you run with scissors if you really feel the need to.
This is my process for a full-disk, EFI installation with HAMMER2 as the rootfs, and mimicking the basic setup of ZFS when using something like FreeBSD, HardenedBSD, or Illumos. It's important to remember, that while HAMMER2 is awesome, it is NOT ZFS! This is just me having fun with the ability to arbitrarily create pfs-es and administer them in a similar manner to ZFS. I cannot stress enough how much this shouldn't be done in production unless by the time you're reading this, HAMMER2 is considered stable and this process has been adopted to some degree. (As of this time of writing, 2017-01-30 @ 02:55 UTC, this is not the case)

Get the Install Media!

You can't install an OS without install media! Head on over to https://www.dragonflybsd.org/ to get yourself the latest install image. Ideally get the USB image (ends in ".img"), this way you boot into a live system with a rw rootfs, this gives you the ability to use it as intermediary storage, or build a DragonFly BSD install from source should you choose to do so.
NOTE: The USB images are compressed filesystems, the download should be around 200MB, but the uncompressed version will be around 2GB, this is meant to give you space to experiment with the OS prior to doing a full install. This is NOT like live Linux images.
After downloading, you'll need to decompress the image. This is done rather simply with the command

	bunzip2 dfly-x86_64-5.0.2_REL.img
(of course, replace the name with the actual path to your downloaded image, 5.0.2 is just the latest release at the time of writing). Then, use your favorite disk imaging utility, or even just a tool that's happy writing to a block device directly. dd(1), for example:
			## Replace da8 with the appropriate block device on your system
			dd if=dfly-x86_64-5.0.2_REL.img of=/dev/da8 bs=4m && sync

Set Up the Drive

So this time, I mean the drive you want to install your new DragonFly BSD system on. This should be a drive that has at least 50GB of free space for best results due to the design of HAMMER2, being both CoW and not immediately freeing space can lead to your drive filling up faster than you'd anticipate on something like UFS, EXT4, or XFS.
Of course, step one is to actually boot the install media. Log in as "installer" and set up your network connection, if necessary, change the keyboard layout to something more comfortable (like maybe Dvorak?). These options should be immediately available under the LiveCD Utilities option once the ncurses installer gets started. An important note here is that the installer UI is on ttyv2, ttyv1 initially had the login screen, and we want to switch to ttyv3 to make the best use of the screen space you have available. This is simple: hit Alt-F3 (no need for Control). Once on this tty, you'll be greeted with another login prompt. This time, log in as "root", there's no password, so you should be dropped into the interactive shell right away. Unlike many, if not most Linux distros, the interactive shell is csh, not bash. So you may want to run the following commands to make things a bit more comfortable:

			# Turn off the bell
			sysctl kern.sysbeep_enable=0
			# Remove the need to run rehash
			set autorehash
			# Show some completion options 
			set autolist
			# Offer to correct commands
			set correct = cmd
With the environment set up like that, we're ready to work on the rest of the installation. First and foremost, we need to know if this is going to be using Legacy BIOS to boot or if it's booting via (U)EFI. Most modern machines are using (U)EFI, which makes setting up the boot management incredibly simple, if a bit confusing at first. Legacy BIOS is also fairly simple, though I've run into more issues with that method than with (U)EFI booting, so I highly recommend using (U)EFI if your system supports it. Due to my experiences, I'm only going to cover the (U)EFI setup process. Legacy BIOS should be configured in much the same way, but the bootloader installation is different.

(U)EFI Steps

The steps taken here are essentially a customized, manual run of efisetup(8), using HAMMER2 instead of HAMMER, and possibly creating additional slices to house additional filesystems. This would enable you to mix HAMMER and HAMMER2 should you want to do so.
First: we need to initialize the target drive, if this is a SATA drive it should show up as da0 or some other number, depending on how many SATA drives are connected. If it's an NVMe drive it'll be nvme0 or a higher number, depending on how many NVMe drives you have. If you have multiple drives with multiple OS installs, you'll need to use the following commands to find the available devices and identify which drive you actually want to install to.

			# Get basic device info 
			# NOTE: does not report NVMe drives
			camcontrol devlist

			# If that doesn't give you enough information
			# this will display drive sizes
			camcontrol readcap -h

			# If you're using an NVMe drive, you'll need to 
			# use the following command instead
			gpt -rv show nvme0

			# If you need to check the partition labels, 
			# not just the types, use this instead
			gpt -rv show -l nvme0
Once the target drive is located, the process is rather simple, if potentially a bit confusing. I'll continue using shell style comments to explain the process as we go.
NOTE: HAMMER2 is still under development at the time of this writing, and not considered stable. Things may change making this guide incorrect. Not BTRFS unstable, but still, don't say you weren't warned.
			## Create a GPT partition table
			gpt create -f da0 
			# NVMe
			gpt create -f nvme0

			## Create the ESP 
			gpt add -s 524288 -i 0 -t "EFI System" da0
			# NVMe 
			gpt add -s 524288 -i 0 -t "EFI System" nvme0

			## Create the partition to install DragonFly on
			gpt add -i 1 -t dfly da0
			# NVMe 
			gpt add -i 1 -t dfly nvme0

			## Make the ESP bootable 
			mkdir -pv /efimnt
			newfs_msdos da0s0
			mount_msdos da0s0 /efimnt
			mkdir -pv /efimnt/efi/boot
			cpdup -vIm /boot/boot1.efi /efimnt/boot/bootx64.efi && sync
			umount /efimnt
			# NVMe 
			mkdir -pv /efimnt
			newfs_msdos nvme0s0
			mount_msdos nvme0s0 /efimnt
			mkdir -pv /efimnt/efi/boot
			cpdup -vIm /boot/boot1.efi /efimnt/boot/bootx64.efi && sync
			umount /efimnt

			## Create a disklabel
			## This is effectively the same as the partitioning step in other systems
			disklabel -r -w da0s1 auto
			# NVMe
			disklabel -r -w nvme0s1 auto

			## Edit the disklabel
			## As a heads-up, this will launch vi(1) by default
			## if you're not familiar with vi(1), you can also use ee(1)
			## which is similar to nano on Linux distros.
			disklabel -r -e da0s1
			# with ee(1) instead of vi(1)
			setenv EDITOR ee 
			disklabel -r -e da0s1

			# NVMe
			disklabel -e nvme0s1
			# with ee(1) instead of vi(1)
			setenv EDITOR ee
			disklabel -e nvme0s1

			## The disklabel utility has a pretty simple format 
			## slice  :  size  :  offset  :  fstype  
			## now another thing to remember is that by convention,
			## the a slice is /boot partition
			## the b slice is the swap partition (1-2x RAM size is usually a good size)
			## the d slice is the root filesystem
			## You can add as many slices as you like, though I recommend not making
			## any slice holding a HAMMER or HAMMER2 filessytem smaller than 50GB
			## the below is an example 1TB drive partition that I've set up
			## an asterisk in the size column is using all remaining space on the drive
			## an asterisk in the offset column allows the offset to be automatically calculated

			a: 1g  0  4.2BSD # boot partition, 1G mandatory
			b: 16g *  swap   # swap space
			c: 256g * hammer2 # used for jails
			d: 512g * hammer2 # root filesystem
			e: *    * hammer2 # home filesystem

			## After this has been modified to suit your needs, you'll need to format the partitions
			newfs da0s1a # create the /boot filesystem
			newfs_hammer2 da0s1c # jail partition
			newfs_hammer2 da0s1d # rootfs partition
			newfs_hammer2 da0s1e # home partition

			# NVMe
			newfs nvme0s1a # create the /boot filesystem
			newfs_hammer2 nvme0s1c # jail partition
			newfs_hammer2 nvme0s1d # rootfs partition
			newfs_hammer2 nvme0s1e # home partition

			## Now we need to get the necessary filesystems mounted 
			mount_hammer2 da0s1d@LOCAL /mnt
			mkdir -pv /mnt/boot
			mount da0s1a /mnt/boot

			# NVMe 
			mount_hammer2 nvme0s1d@LOCAL /mnt
			mkdir -pv /mnt/boot
			monut nvme0s1a /mnt/boot

			## Now we just create the additional pseudo filesystems
			## these will serve a similar role as ZFS datasets
			hammer2 -s /mnt pfs-create usr
			hammer2 -s /mnt pfs-create usr.dports
			hammer2 -s /mnt pfs-create usr.include
			hammer2 -s /mnt pfs-create usr.local
			hammer2 -s /mnt pfs-create usr.obj
			hammer2 -s /mnt pfs-create usr.share
			hammer2 -s /mnt pfs-create usr.src
			hammer2 -s /mnt pfs-create usr.local.include
			hammer2 -s /mnt pfs-create usr.local.share
			hammer2 -s /mnt pfs-create usr.local.var

			## So naturally, the next step is to create the required mountpoints
			## and mount these HAMMER2 PFS-es, this process can be much more flexible
			## once the clustering code is added, but for now, think of them as simply
			## logical separations on your drive, so you can more easily manage single 
			## portions of the OS
			mkdir -pv /mnt/usr
			mount_hammer2 -o local,noatime da0s1d@usr /mnt/usr
			mkdir -pv /mnt/usr/dports
			mount_hammer2 -o local,noatime da0s1d@usr.dports /mnt/usr/dports
			mkdir -pv /mnt/usr/include
			mount_hammer2 -o local,noatime da0s1d@usr.include /mnt/usr/include
			mkdir -pv /mnt/usr/local
			mount_hammer2 -o local,noatime da0s1d@usr.local /mnt/usr/local
			mkdir -pv /mnt/usr/obj
			mount_hammer2 -o local,noatime da0s1d@usr.obj /mnt/usr/obj
			mkdir -pv /mnt/usr/share
			mount_hammer2 -o local,noatime da0s1d@usr.share /mnt/usr/share
			mkdir -pv /mnt/usr/src
			mount_hammer2 -o local,noatime da0s1d@usr.src /mnt/usr/src
			mkdir -pv /mnt/usr/local/include
			mount_hammer2 -o local,noatime da0s1d@usr.local.include /mnt/usr/local/include
			mkdir -pv /mnt/usr/local/share
			mount_hammer2 -o local,noatime da0s1d@usr.local.share /mnt/usr/local/share
			mkdir -pv /mnt/usr/local/var
			mount_hammer2 -o local,noatime da0s1d@usr.local.var /mnt/usr/local/var
			## /dev is necessary for devfs to work properly
			mkdir -pv /dev

			# NVMe
			mkdir -pv /mnt/usr
			mount_hammer2 -o local,noatime nvme0s1d@usr /mnt/usr
			mkdir -pv /mnt/usr/dports
			mount_hammer2 -o local,noatime nvme0s1d@usr.dports /mnt/usr/dports
			mkdir -pv /mnt/usr/include
			mount_hammer2 -o local,noatime nvme0s1d@usr.include /mnt/usr/include
			mkdir -pv /mnt/usr/local
			mount_hammer2 -o local,noatime nvme0s1d@usr.local /mnt/usr/local
			mkdir -pv /mnt/usr/obj
			mount_hammer2 -o local,noatime nvme0s1d@usr.obj /mnt/usr/obj
			mkdir -pv /mnt/usr/share
			mount_hammer2 -o local,noatime nvme0s1d@usr.share /mnt/usr/share
			mkdir -pv /mnt/usr/src
			mount_hammer2 -o local,noatime nvme0s1d@usr.src /mnt/usr/src
			mkdir -pv /mnt/usr/local/include
			mount_hammer2 -o local,noatime nvme0s1d@usr.local.include /mnt/usr/local/include
			mkdir -pv /mnt/usr/local/share
			mount_hammer2 -o local,noatime nvme0s1d@usr.local.share /mnt/usr/local/share
			mkdir -pv /mnt/usr/local/var
			mount_hammer2 -o local,noatime nvme0s1d@usr.local.var /mnt/usr/local/var
			## /dev is necessary for devfs to work properly
			mkdir -pv /mnt/dev

			## Now we have a decision to make, you can either 
			## clone the live image, or build a new installation from source
			# Source method
			## With this method, you may want to make some changes to /etc/make.conf
			## the defaults are perfectly fine, sane, and result in a pretty fantastic system,
			## however, if you're reading this, you may be like me in that you have a compulsion to
			## stick your ${EDITOR} where it doesn't belong and see if you can't make things better
			## Below is how I generally try to build my DragonFly systems:
				CFLAGS += -march=native -mtune=native -O2 -pipe -fPIC -fpic -fstack-protector-strong
				# While kept the same as CFLAGS, setting CXXFLAGS += ${CFLAGS} can break C++ 
				# software being built, by passing something like `-std=c99` to a C++ build, 
				# which throws errors, causing builds to fail
				CXXFLAGS += -march=native -mtune=native -O2 -pipe -fPIC -fpic -fstack-protector-strong
				LDFLAGS += -z combreloc
				# These are boolean, so just defining them is sufficient
				# but I like to be explicit in my configs so they're easier
				# to understand when I need to come back to them

			cd /usr/src
			make -j `sysctl -n hw.ncpu` buildworld
			make -j `sysctl -n hw.ncpu` installworld DESTDIR=/mnt
			make -j `sysctl -n hw.ncpu` buildkernel
			make -j `sysctl -n hw.ncpu` installkernel DESTDIR=/mnt
			cd etc
			make distribution DESTDIR=/mnt

			# Cloning method
			# alternatively, use: cpdup -dIm ${source} ${destination} 
			# to reduce the output
			cpdup -vvvIm /boot /mnt/boot
			cpdup -vvvIm / /mnt
			cpdup -vvvIm /usr /mnt/usr
			cpdup -vvvIm /usr/include /mnt/usr/include
			cpdup -vvvIm /usr/lib /mnt/usr/lib
			cpdup -vvvIm /usr/local /mnt/usr/local
			cpdup -vvvIm /usr/share /mnt/usr/share
			cpdup -vvvIm /usr/local/include /mnt/usr/local/include
			cpdup -vvvIm /usr/local/lib /mnt/usr/local/lib
			cpdup -vvvIm /usr/local/var /mnt/usr/local/var
			cpdup -vvvIm /var /mnt/var

			## At this point, you should have all the necessary tools to 
			## boot into a new DragonFly BSD installation, 
			## but first, we should really configure some things

			# Generate a baseline fstab
			mount | grep hammer2 | awk '{print $1;}' >> /mnt/etc/fstab

			# Edit that fstab to actually work
				## Of course, change the devices to suit your drive, like 
				## using nvme0s1 to address your NVMe drive
				da0s1a /boot ufs noatime 0 0
				da0s1b none swap sw 0 0
				da0s1d@LOCAL / hammer2 local,noatime 0 1
				da0s1d@usr /usr hammer2 local,noatime 0 0 
				da0s1d@usr.dports /usr/dports hammer2 local,noatime 0 0 
				da0s1d@usr.include /usr/include hammer2 local,noatime 0 0
				da0s1d@usr.lib /usr/lib hammer2 local,noatime 0 0
				da0s1d@usr.local /usr/local hammer2 local,noatime 0 0
				da0s1d@usr.obj /usr/obj hammer2 local,noatime 0 0 
				da0s1d@usr.share /usr/share hammer2 local,noatime 0 0 
				da0s1d@usr.src /usr/src hammer2 local,noatime 0 0 
				da0s1d@usr.local.include /usr/local/include hammer2 local,noatime 0 0 
				da0s1d@usr.local.lib /usr/local/lib hammer2 local,noatime 0 0 
				da0s1d@usr.local.share /usr/local/share hammer2 local,noatime 0 0 
				da0s1d@usr.local.var /usr/local/var hammer2 local,noatime 0 0 
				# The size argument should be relative to both your total RAM and
				# how much data you expect each tmpfs directory to hold. 512MB should 
				# be more than enough for most desktop/workstation use cases, but may not 
				# be enough for a production server
				# Of course, this is not at all necessary, but it can help speed up 
				# certain programs by writing volitile files to RAM instead of writing to
				# disk. If you can't spare the RAM due to other constraints, feel free 
				# to omit these lines.
				dummy /tmp tmpfs size=512m,mode=0777,owner=root,group=wheel 0 0
				dummy /var/run tmpfs size=512m,mode=0777,owner=root,group=wheel 0 0 
				dummy /var/tmp tmpfs size=512m,mode=1777,owner=root,group=wheel 0 0

			# Tell the bootloader where root is 
			# Set some options in sysctl.conf(5)
				# Disable the bell
				# Needed for chromium to work correctly
				# Prevent unprivileged users from seeing all processes & threads
				# Prevent hardlink abuse
				# Take advantage of the ASLR code
				# Randomize your PIDs

			# Get the basics set in rc.conf
				# Set the hostname
				hostname="DragonFly.bsd.loc" # this is the FQDN of the host
				# Enable sshd
				# Enable dbus
				# Enable udevd
				# Ensure the mouse is usable
				# Disable sendmail
This should leave you with a mostly functional system, though you'll need to configure your network settings as well, setting the DNS servers in resolv.conf(5) and potentially using wpa_supplicant to connect to a wifi network. The exact methodology of which will depend on your wireless chipset, so check the documentation to see what you need for your hardware to work best for you.